Season
Foundation Seasons define participation phases, activation milestones, state transitions, and forward-only operational boundaries across Genesis and later phases.
Overview
A Foundation Season defines a participation phase and operational timeline in PVERSE. It governs how participation surfaces such as Genesis and Founders are administered, how activation milestones are interpreted, and how later operational states are introduced.
Seasons are forward-only. Updates affect future outcomes only, while past participation records, allocation histories, and state transitions remain auditable as part of the system record.
Scope
This page defines how Foundation seasons constrain participation timing, activation ordering, and operational interpretation across the platform.
- participation windows for Genesis, Founders, and later entry surfaces
- season states and transition boundaries
- activation milestones and how live operational state is interpreted
- forward-only rules that preserve auditability across season changes
Core Model
The season model treats each Foundation phase as an explicit operational state with defined boundaries, not as a vague narrative phase. Entry, closure, finalization, and later activation each have distinct meaning inside the system.
- seasons are represented as explicit states with operational meaning
- participation and activation boundaries are distinct from each other
- season transitions depend on recorded operational milestones
- past season outcomes remain auditable after future changes occur
Operational Behavior
A Foundation Season may move through states such as announced, active, closed, finalizing, and finalized. These states determine whether participation is open, whether in-flight verification may continue, and whether records have moved into an archival or vesting-governed phase.
Live state should be interpreted through current operational status rather than roadmap intent alone. Roadmap explains planned ordering, while Status reflects the authoritative present state of the system.
Constraints
- season boundaries must be tied to explicit, recorded operational changes
- participation windows cannot remain ambiguous once status is published
- historical records are not rewritten when later season states are introduced
- future mechanics must remain compatible with prior auditable season history
Integrity Considerations
Season handling is also an integrity layer. It prevents ambiguity about whether participation is open, whether transitions have actually occurred, and whether later phases are being interpreted using authoritative state rather than informal assumptions.
- status must reflect real operational state, not promotional framing
- transitions should be represented as new recorded states, not silent rewrites
- past season outcomes must remain inspectable after future updates
Future Expansion
As PVERSE expands, Foundation Seasons may govern additional participation surfaces, broader activation phases, new market-state transitions, treasury-linked operations, and other explicit milestone-driven system behaviors.
Summary
- Foundation Seasons define participation phases and activation ordering in PVERSE.
- Season boundaries are explicit operational states, not informal labels.
- Transitions are forward-only and preserve auditable history.
- Roadmap expresses intent, while Status reflects live authoritative state.