PVERSE
Foundation

Participation Flow

How participation moves through the system: deposit detection, verification, allocation record creation, vesting linkage, and status tracking under forward-only rules.

Published: March 23, 2026
Updated: March 23, 2026
Section: Foundation
Forward-only processing
Participation handling is forward-only. Changes apply to future outcomes only, while historical participation records remain auditable and are not rewritten retroactively.

Overview

Participation Flow defines how participation events are processed in PVERSE. It describes the operational pipeline that links participation categories such as Genesis and Founders to verifiable evidence, allocation record creation, and vesting governance.

This page is not a deposit how-to guide. It is a system reference describing verification boundaries, authoritative transitions, and forward-only processing behavior across the participation lifecycle.

Scope

The participation model is intended to explain how intake, verification, record creation, and ongoing state visibility work together inside a deterministic system.

  • deposit intake through supported participation routes
  • verification boundaries for eligibility and integrity
  • allocation record creation after successful validation
  • linkage into vesting and operational status visibility

Core Model

The core model treats participation as a staged process. Evidence enters the system, passes policy and integrity checks, becomes an allocation record if valid, and then remains visible through auditable status and vesting-linked tracking.

  • participation begins with deposit evidence entering the system
  • verification determines whether evidence is eligible
  • allocation records are created only after validation succeeds
  • vesting and status tracking operate on authoritative records

Operational Behavior

Participation moves through a deterministic path: deposit detected, verification completed, allocation record created, vesting schedule linked, and operational state exposed through status tracking.

Each stage has its own boundary. Failures, invalid conditions, or out-of-policy events are recorded as outcomes rather than causing silent rewrites or retroactive mutation of past records.

Constraints

  • supported assets, networks, categories, and windows define eligibility
  • verification requires confirmation and finality boundaries to be satisfied
  • duplicate and replay conditions must be prevented at the integrity layer
  • historical participation outcomes are not retroactively rewritten

Integrity Considerations

Participation handling is also an integrity system. It must distinguish valid evidence from unsupported, duplicate, insufficient, or non-finalized events while preserving an auditable operational history.

  • duplicate or replay evidence must not create multiple authoritative records
  • non-finalized or out-of-window events must be blocked by policy boundaries
  • corrections should be represented as new forward events, not retroactive edits

Future Expansion

As PVERSE expands, participation flow may connect to broader treasury visibility, deeper allocation governance, additional intake systems, extended vesting operations, and more formal reporting across public and internal status layers.

Summary

  • Participation Flow defines the operational path from deposit evidence to authoritative record creation.
  • Verification is the boundary that determines eligibility, integrity, and finality.
  • Allocation and vesting operate on validated records rather than raw events alone.
  • The entire model follows forward-only rules and preserves historical auditability.