Vesting & Unlocks

Overview

The PVERSE token lifecycle treats entitlement maturity as a distinct process from transferability and market activation. Allocation records establish who has a grant. Vesting schedules determine how that grant matures over time. Unlock and claim rules determine when matured portions may actually be realized.

This separation is intentional. It prevents confusion between economic entitlement and market availability, and it allows the protocol to maintain predictable vesting behavior even when operational trading controls remain OFF. The result is a more auditable and policy-stable token layer.

Scope

This page explains how allocation records move through vesting, unlock, and claim states, and how those states relate to but remain distinct from transferability.

• Grant lifecycle from recorded allocation to claimed amounts.
• Definitions for vested, unvested, claimable, and claimed states.
• Multiple-stream behavior such as principal and bonus vesting.
• Forward-only accounting and separation from market activation policy.

Core Model

Every grant can be understood as moving through a controlled sequence of states. What exists as an entitlement, what has matured, what is claimable, and what is actually transferred to the user are treated as different layers of state rather than a single blurred balance.

• Allocation record: an append-only grant that establishes entitlement for a wallet or participant lane.
• Vesting state: the grant matures according to its defined schedule, such as linear release, cliff plus linear, or multiple independent streams.
• Unlock / claimability: matured portions become claimable only under the applicable unlock and claim rules.
• Tradability separation: claimed or vested balances are not automatically tradable; market activation is controlled elsewhere.

Operational Behavior

In practice, the lifecycle starts when a grant is recorded. As time passes, some portion becomes vested under the schedule attached to that grant. Depending on lane policy, the vested amount may become immediately claimable or may remain under a further unlock condition before the user can claim it. Claim execution can be manual, batched, or potentially automated in later phases.

Some allocations may contain multiple streams, such as principal plus bonus. In those cases, each stream should be tracked independently with its own vested and claimable state, while the interface may still present combined totals for convenience. If a claim fails because of network conditions or operational constraints, the claimable balance remains claimable and can be retried without rewriting prior history.

Constraints

• No assumption that vesting implies transferability or open-market trading.
• No assumption that claimability eliminates minimum thresholds, batching rules, or operational constraints.
• No retroactive rewriting of entitlement history; corrections must be represented by forward-only entries.
• No reading of vesting schedules as price signals, market guarantees, or trading forecasts.

Integrity Considerations

Vesting systems are only trustworthy when users can clearly distinguish entitlement maturity from market availability. The protocol therefore keeps vesting math, claim mechanics, and tradability policy in separate lanes so that each state has a stable meaning.

• State clarity: vested, claimable, claimed, and tradable are not interchangeable terms and should remain distinct in both UI and policy.
• Multiple-stream transparency: principal and bonus lanes should be trackable independently, even when surfaced as a combined total.
• Forward-only reconciliation: adjustments and corrections should be made through compensating entries and later snapshots, preserving auditability.

Future Expansion

As the ecosystem matures, the vesting surface may expand to include richer dashboards, scheduled batch claims, milestone-linked release logic, or clearer per-stream analytics. Any such expansion should preserve the same core discipline: explicit state definitions, separate control surfaces for claimability and tradability, and forward-only records that keep entitlement history traceable.

Summary

• PVERSE separates allocation, vesting, unlock, claim, and tradability into distinct states.
• Vesting can continue and claimable balances can accumulate even while trading remains disabled.
• Multiple streams such as principal and bonus should be tracked independently but may be shown in combined views.
• The accounting model remains forward-only, preserving traceability through additive records and compensating entries.