Definitions
Canonical terminology meanings used across PVERSE. If wording conflicts elsewhere, this page wins.
Overview
PVERSE is a system where code, documentation, and recorded state must align. This page provides a single authoritative reference for the meaning of terms used across protocol, infrastructure, participation, security, and game systems.
The goal is to prevent semantic drift across documents and implementations, define boundaries between lanes, and preserve forward-only meaning. Definitions may expand over time, but they must not silently contradict historical usage.
Scope
This page defines terms that affect system interpretation and implementation across PVERSE.
- protocol and ledger semantics such as finality, confirmations, records, and transitions
- participation semantics such as Genesis, Founders, vesting, allocation, and eligibility
- infrastructure semantics such as watchers, settlers, RPC providers, and rate limits
- security semantics such as signers, passkeys, authentication, authorization, and recovery
Core Model
A term should have one canonical meaning across the docs. Meaning is stable, numbers live in SSOT, and enforcement lives in code and recorded outcomes. This page resolves conflicts in wording, not by improvisation, but by explicit semantic ownership.
- single meaning: a term has one authoritative definition
- non-retroactive interpretation: past records keep the meaning active when they were produced
- expandable definitions: new detail may be added without contradicting older meaning
- lane boundaries matter: terms implying guarantees or market rules must align with their owning lane
Operational Behavior
In practical use, this page should resolve ambiguity across production logs, docs, UI copy, and internal implementation language. If wording conflicts appear elsewhere, the correct fix is to align the other surface to this page or to add an explicit clarified definition here.
When a term’s practical meaning must evolve, PVERSE follows a forward-only definition policy. Introduce a clarified or versioned definition and preserve the old meaning as historically valid rather than rewriting the past.
Constraints
- this page defines meaning, not numeric constants; exact values remain in SSOT
- this page does not define narrative lore terms, UI microcopy, or temporary marketing language
- implementation examples may help, but definitions should remain implementation-agnostic
- if a term belongs primarily to Whitepaper, Foundation, Security, or Infrastructure, it must remain consistent with that lane’s canonical policy pages
Integrity Considerations
Definitions are part of system integrity. If terms drift in meaning, readers and operators stop interpreting the same records the same way. This page protects against that drift by fixing canonical meaning while allowing forward-only clarification.
- definitions keep semantics aligned across docs, SSOT, and code
- historical records remain interpretable under the meaning active when they were created
- ambiguity should be resolved by clarification, not by reinterpreting older usage
Protocol Definitions
Ledger
The canonical record of finalized system state. Ledger entries are produced only after required conditions are met, such as on-chain confirmations and internal validity checks, and are treated as forward-only records.
Finality
The point at which an event is treated as irreversible within PVERSE rules. Finality is defined by the system’s confirmation policy and any additional safety constraints such as reorg tolerance, provider agreement thresholds, or internal settlement checks.
Confirmation
A measure of chain depth beyond the inclusion block for a transaction or event. Confirmation counts are used to help reach finality and mitigate reorg risk.
Commit
A recorded payment intent created by the system. A commit binds an intended deposit, asset and amount, to a derived deposit address and an immutable pricing snapshot, and defines an expiry window and acceptable detection criteria.
Pricing Snapshot
The immutable price reference stored at commit creation time. It is used for deterministic conversion, accounting, and audit consistency even if external prices change later.
Event
A detectable occurrence, on-chain or internal, that may affect state. Events are not automatically ledger entries; they must pass validation and finality criteria.
State Transition
A controlled movement between defined system statuses, such as CREATED → PENDING → CONFIRMING → CONFIRMED. Transitions must be deterministic, validated, and logged.
Participation Definitions
Genesis
The early participation phase governed by fixed allocation and policy rules. Genesis semantics include eligibility boundaries, locked multipliers if applicable, and explicit market activation constraints.
Founders
A foundational allocation category. Founders allocations are typically subject to vesting and operational policy constraints designed to align long-term incentives.
Allocation
A system-recognized assignment of token rights governed by explicit issuance and release rules. Allocation is not synonymous with immediate transferability.
Vesting
A time-based release mechanism that controls when allocated balances become available under system rules. Vesting schedules are defined by policy and recorded forward-only.
Eligibility
A rule-defined condition for participation or receipt of a defined outcome. Eligibility is decided by explicit policy, not by subjective interpretation.
Infrastructure Definitions
Deposit Address
A deterministically derived address used to identify deposits for a specific commit or participant flow. It is designed for unambiguous detection and accounting.
HD Derivation
Deterministic key and address generation using hierarchical derivation. HD derivation enables scalable deposit address creation without storing private keys per address.
Watcher
A component that scans chain data sources, such as RPC providers, logs, or block traces, and produces observed deposit events. A watcher does not finalize ledger entries by itself.
Settler
A component that applies confirmation and finality rules and turns observed events into finalized ledger records. Settlers are responsible for deterministic state transitions.
RPC Provider
A blockchain data access endpoint or service used to query blocks, transactions, receipts, logs, and related chain state. Providers may impose rate limits and vary in reliability.
Rate Limit
A defined limit on request volume per unit time imposed by infrastructure. Rate limits are treated as reliability constraints that must be mitigated via backoff, caching, or redundancy.
Redundancy
A deliberate design strategy that uses multiple independent components, providers, paths, or systems to reduce single points of failure and raise confidence in observed state.
Security Definitions
Signer
A key-holding component capable of producing valid cryptographic signatures. A signer may be software-based, device-bound, or hardware-backed.
Key Management
Operational and technical practices for protecting keys and controlling signing authority. Key management includes storage, rotation strategy, access boundaries, and incident response.
Passkey
A device-bound authentication credential, typically based on public-key cryptography, used to authenticate users without passwords. Passkeys reduce phishing risk and improve UX.
Authentication
The process of proving identity to the system. Authentication is distinct from authorization.
Authorization
The process of granting permissions based on policy after authentication. Authorization determines what actions an authenticated actor can perform.
Recovery
A controlled process that restores account access after loss of a primary authenticator or device. Recovery must not compromise the system’s security guarantees or enable silent takeover.
Threat Model
A documented set of attacker capabilities, assumptions, and targeted assets. A threat model defines which risks are mitigated, which are accepted, and what monitoring exists.
Game System Definitions
SSOT (Single Source of Truth)
The canonical configuration source for numeric values and deterministic parameters used by systems, such as drop distributions, probabilities, prices, and thresholds. SSOT values are authoritative and must not be overridden by ad-hoc logic.
Discovery
The eligibility stage of the game loop that determines what can appear before mining occurs. Discovery defines what may appear, not what the player receives.
Mining
The action stage that produces realized outcomes using tools and player state. Mining determines what you get from the eligible set produced by Discovery.
Refining
A transformation step that converts ore into refined materials under defined success and output rules. Refining outputs and probabilities are SSOT-controlled.
Forging
A higher-tier transformation step with success probability and loss-handling rules. Forging is risk-bearing and must follow deterministic SSOT distributions.
Definition Format Standard
Each definition should follow a stable documentation rule set so that meaning remains consistent across pages, UI labels, and implementation language.
- implementation-agnostic: define meaning, not one specific code path
- non-UI language: avoid relying on button text or surface labels
- deterministic wording: avoid vague phrases unless explicitly scoped
- boundary-aware: if a term implies guarantees or market rules, it must align with the owning lane
Relationships to Other Pages
Definitions vs Glossary
- Glossary: reader-friendly explanations that may include examples and narrative tone
- Definitions: canonical meaning, rule-oriented wording, and conflict resolution authority
Definitions vs SSOT
- SSOT: numeric configuration and deterministic parameters
- Definitions: vocabulary and semantic boundaries used to interpret those parameters
Definitions vs Whitepaper
- Whitepaper: protocol guarantees, policies, and system model
- Definitions: vocabulary used by the Whitepaper and the rest of the docs to resolve wording conflicts
Future Expansion
This page may expand over time as PVERSE formalizes more lane-specific terminology, richer glossary bridges, and more explicit versioned definitions for terms whose operational interpretation grows in precision. Even as it grows, it should remain the canonical semantic authority page for shared system language.
Summary
- Definitions is the canonical meaning source for shared PVERSE terminology.
- Definitions keep interpretation aligned across docs, SSOT, code, and recorded state.
- Meaning is forward-only: it may be clarified, but not silently rewritten against history.
- Numeric values belong in SSOT; this page defines semantic boundaries, not constants.