Token Allocation
How total supply is partitioned into purpose-based buckets, with strict separation between allocation, vesting, unlock, circulation, and tradability.
Overview
Allocation defines how total supply is partitioned into purpose-specific buckets. Each bucket exists to serve a clear system role across participation, liquidity operations, reserves, continuity, or operational execution inside the PVERSE economy.
Allocation is an assignment layer. It is not a promise of immediate release, not a promise of market access, and not a price guarantee. Release mechanics and timing are defined separately by vesting, unlock, circulation policy, and market activation rules.
Scope
Token Allocation defines the purpose-based partitioning model for total supply inside the Token section.
- allocation bucket meaning and role boundaries
- clear separation between allocation, vesting, unlock, circulation, and tradability
- forward-only accounting interpretation for allocation records
- reporting and disclosure boundaries across docs, status, and SSOT
Core Model
The core model is that every token in total supply belongs to a purpose-defined allocation bucket before any question of release or tradability is evaluated. Allocation answers where supply belongs; later policy layers answer when it becomes accessible and whether it becomes tradable.
- allocation is purpose-based, not market-state based
- control surfaces are separated across participation, liquidity, treasury, and operations
- historical allocation records follow forward-only accounting interpretation
- public disclosure prioritizes correctness, source clarity, and stable labeling over speculation
Allocation Principles
- Purpose-based buckets: every token in supply has a role-defined destination.
- Separation of control surfaces: participation, liquidity, treasury, and operations are managed independently.
- Forward-only accounting: allocation records are appended rather than silently rewritten.
- Predictable release policy: bucket release follows predefined mechanisms such as vesting, lockup, or market activation.
- Safety-first disclosure: public reporting distinguishes assigned, unlocked, circulating, and tradable states.
Allocation Buckets
The buckets below describe the canonical partitioning model. This page focuses on meaning, control, and release boundaries rather than publishing full live numeric values.
Founders Allocation
Purpose: recognizes earliest supporters and the highest-risk bootstrap layer of trust.
Control surface: policy-governed founder issuance and vesting rules.
Release boundary: released according to a defined vesting schedule and not assumed freely tradable by default.
Reporting: allocation and unlock are disclosed separately to avoid confusion with circulating or tradable supply.
Genesis Allocation
Purpose: supports controlled early participation under explicit phase rules and eligibility constraints.
Control surface: participation administration, ledger attribution, and phase policy.
Release boundary: may include lockup, vesting, and market-activation constraints. Allocation itself does not imply free transferability.
Reporting: issuance is tied to participation records and should be distinguished from market-state visibility.
Liquidity Allocation
Purpose: supports controlled market activation and liquidity depth formation.
Control surface: liquidity operations policy, activation gates, and lock handling.
Release boundary: this bucket exists for liquidity provisioning and related market operations, not as a discretionary reward surface.
Reporting: liquidity actions belong on status surfaces and market-state reporting, not inside participation accounting.
Treasury / Reserves Allocation
Purpose: supports long-term sustainability, resilience, and incident response.
Control surface: treasury policy, release caps, and reserve-handling procedures.
Release boundary: reserve assignment does not imply circulating exposure by default. Release follows defined policy boundaries.
Reporting: shown as reserve state with purpose-labeled forward-only changes.
Operations Allocation
Purpose: covers platform operations that should not be modeled as participation rewards, including infrastructure, maintenance, and security-linked execution surfaces.
Control surface: operational policy with explicit separation from participation issuance.
Release boundary: bounded by operational requirements and safety constraints rather than open reward logic.
Reporting: disclosed as operational usage, not as user-facing reward issuance.
Allocation vs Supply vs Vesting
These terms are frequently confused. PVERSE keeps them deliberately separate to protect clarity and prevent misleading interpretation.
| Concept | Meaning | What it is not |
|---|---|---|
| Total Supply | The total token amount defined by the token system. | Not circulating by default. |
| Allocation | Assignment of supply into purpose-specific buckets. | Not an unlock and not a release promise. |
| Vesting | Time-based release rules for a specific allocation bucket. | Not necessarily tradability on release. |
| Unlock | When value becomes claimable or accessible under policy. | Not an exchange listing guarantee. |
| Circulating View | The supply view intended to represent what is actually active or reachable in the current market phase. | Not identical to total allocated value. |
| Tradability | Whether transfers or trading are enabled under market policy. | Not implied by allocation or vesting alone. |
Allocation Lifecycle
A useful way to read the token system is as a staged pipeline. Allocation defines destination first; later policy layers define accessibility and transferability.
- Total supply is defined.
- Allocation bucket assigns purpose.
- Record creation occurs under forward-only accounting rules.
- Vesting or lockup controls timing and accessibility boundaries.
- Unlock moves value into a claimable or active state under policy.
- Circulating view reflects what is actually accessible in the current phase.
- Tradability depends on market activation and transfer enablement policy.
Reporting Policy
Allocation is reported through clearly labeled surfaces to prevent misinterpretation. Documentation explains structure and intent, while status and SSOT surfaces reflect current effective values and operational state.
- Docs: explain bucket purpose, boundaries, and definitions.
- Status: reports current system state such as market phase, trading policy, liquidity state, and supply views.
- SSOT: numeric parameters and enforceable thresholds belong to the single source of truth.
Non-Guarantees
- Allocation does not guarantee liquidity depth, price stability, or market performance.
- Allocation does not guarantee exchange listing or third-party integration.
- Allocation does not imply immediate transfers or open trading access.
- Allocation does not override vesting, lockup, or manual market activation policy.
Integrity Considerations
Allocation integrity depends on separating meaning, configuration, and enforcement. Documentation defines bucket roles and conceptual boundaries. SSOT controls numeric parameters and release rules. Code enforces ledger recording, vesting logic, and current market-state behavior.
- allocation truth must remain attributable to authoritative records rather than UI summaries alone
- circulation and tradability views should remain clearly separated from raw assigned value
- historical allocation interpretation remains auditable through forward-only publication and status surfaces
Future Expansion
As PVERSE evolves, allocation reporting may connect to richer supply dashboards, release-state visualizations, and more granular status disclosure. The conceptual model should remain stable: allocation is the purpose-based assignment layer, not the market-access layer itself.
Summary
- Token allocation defines how total supply is partitioned into purpose-specific buckets.
- Allocation is separate from vesting, unlock, circulation, and tradability.
- Each bucket exists to serve a distinct control surface such as participation, liquidity, treasury, or operations.
- All allocation and release interpretation follows forward-only accounting and reporting rules.