Vesting

Overview

Vesting defines the schedule layer that determines how allocation records release over time in PVERSE. It applies after participation has already been recorded and after authoritative allocation records have been created through the appropriate participation flow.

This page explains vesting as a system behavior rather than a promotional promise. It clarifies how Genesis and Founders allocations move through time-based release constraints, how live status relates to release behavior, and how historical records remain auditable under forward-only rules.

Scope

This page defines how vesting is interpreted and administered inside the Foundation layer of PVERSE.

• vesting schedules for Genesis and Founders participation categories
• release timing behavior, intervals, duration, and related constraints
• the relationship between vesting, allocation records, and live status visibility
• forward-only handling for future schedule changes and release events

Core Model

The core model treats vesting as a schedule layer applied to authoritative allocation records. Participation and allocation creation happen upstream; vesting then governs how those records become released over time without retroactively mutating the historical basis from which they came.

• allocation records exist before vesting is applied
• vesting determines release timing rather than record creation
• release outcomes are produced as auditable forward events
• status reflects the live operational state of release behavior

Operational Behavior

In operational terms, vesting begins after a valid allocation record exists. From that point forward, schedule rules govern when balances become released, what constraints apply at each interval, and how those outcomes appear in the broader live status and reporting layer.

If a correction or schedule change is ever required, it must be expressed as a new forward administrative or code-enforced outcome. Prior release history, participation history, and allocation history remain auditable rather than being silently rewritten.

Constraints

• numeric vesting parameters belong to SSOT and enforced code paths, not free-text docs alone
• vesting cannot retroactively rewrite historical allocation or prior release records
• Genesis and Founders schedule behavior must remain interpretable from authoritative records
• future policy or parameter changes apply prospectively to release behavior only

Integrity Considerations

Vesting is also an integrity boundary. It ensures release timing is derived from authoritative records, keeps numeric parameters centralized in SSOT, and preserves a stable audit trail as release events accumulate over time.

• release events should remain inspectable as part of the system record
• SSOT should own schedule numbers, durations, intervals, and caps
• corrections must appear as forward outcomes rather than hidden retroactive rewrites

Future Expansion

As PVERSE expands, vesting may connect to deeper reporting layers, richer participant-facing release visibility, more explicit treasury-linked references, and broader operational tooling that surfaces release state across Foundation and later platform systems.

Summary

• Vesting defines when allocation records release over time in PVERSE.
• It applies after participation and allocation creation, not in place of them.
• Numeric parameters belong to SSOT, while docs define meaning and constraints.
• All release behavior is handled under forward-only rules that preserve auditability.