Genesis

Overview

Genesis defines the initial allocation regime of PVERSE as a verification contract, not a UI process. It specifies how participation is interpreted, how entitlement is recorded, and how post-activation vesting is executed without discretionary edits. Every outcome must be attributable to verifiable evidence, bound to an explicit ruleset, and preserved as append-only records.

Genesis is an allocation lane, not a market promise. Allocation, vesting, claimability, and tradability are intentionally separated so the protocol can preserve deterministic accounting even when trading is delayed, staged, or temporarily constrained.

Scope

This page defines Genesis allocation, valuation evidence, market-activation anchoring, vesting, and audit formalism.

• Genesis entitlement as a 1.3× policy structure.
• Base issuance versus vesting-bound bonus separation.
• Market activation (T₀) as the vesting anchor.
• Forward-only, deterministic, audit-reconstructable protocol behavior.

Core Model

Genesis is modeled as a controlled issuance and vesting system. Participation evidence is normalized, valuation evidence is recorded where policy requires USD-denominated checks, entitlement is written once under the active ruleset, and the vesting-bound portion is released only after market activation.

• Allocation-bound: Genesis entitlement is declared as 1.3×.
• Separation-bound: 1.0× is recorded as base issuance, while 0.3× is strictly vesting-bound.
• Anchor-bound: vesting references finalized market activation (T₀), not UI time.
• Forward-only: issuance, vesting, and corrections are append-only records, never silent rewrites.

Operational Behavior

In normal operation, Genesis first observes and normalizes participation evidence. If a ruleset-defined threshold requires USD-denominated evaluation, the protocol computes it using reconstructable oracle evidence and records the inputs needed for replay. Once validation succeeds, Genesis writes an entitlement record containing the 1.0× base issuance and the declared 0.3× vesting stream.

Vesting remains inactive until market activation is finalized on-chain. Once the trading enable event defines T₀, the Genesis vesting stream begins on the first Thursday after T₀ and distributes the additional 0.3× weekly on a linear basis over three months. This vesting stream is fixed in scope and cannot be silently expanded by UI behavior or off-ledger interpretation.

Constraints

• Genesis is independent from Founders and does not rewrite Founders records or schedules.
• UI displays, cached views, and client estimates are informational only and cannot define allocation truth.
• If required valuation evidence is unavailable under the ruleset, issuance must be rejected or deferred; silent fallback is disallowed.
• This page defines no vesting tranche beyond the fixed 0.3× weekly stream.

Integrity Considerations

Genesis only remains trustworthy if an auditor can reproduce entitlement and vesting from recorded evidence, anchor events, and the effective ruleset version. That is why truth hierarchy, idempotency, deterministic valuation, and append-only records are treated as part of the Genesis model itself.

• Truth clarity: verifiable chain evidence and append-only protocol records are authoritative; UI is informational.
• Replay clarity: reprocessing the same evidence must not create duplicate credit or double vesting.
• History clarity: corrections are represented as new events rather than retroactive edits.

Future Expansion

Future documents may deepen claim mechanics, distribution surfaces, or reporting views, but they should remain subordinate to the same authority boundaries, valuation evidence discipline, T₀ anchoring, and fixed vesting invariants defined here.

Summary

• Genesis defines the initial allocation regime as an auditable transition system, not a UI flow.
• Entitlement is declared as 1.3×: 1.0× issuance plus a fixed 0.3× vesting stream.
• USD valuation, when used, must be reconstructable using recorded oracle evidence under the active ruleset.
• Vesting is a forward-only weekly stream starting on the first Thursday after T₀ and completing over three months.

Authority & Truth Boundaries

Genesis is governed by authority separation: the UI may display progress, but it does not define truth. Allocation and vesting are derived from authoritative sources and executed through controlled transitions.

• Authoritative: chain evidence such as transactions, receipts, finalized blocks, and append-only protocol records.
• Non-authoritative: UI displays, cached views, client session state, and estimates.

Definition

Genesis is the initial allocation category for PVERSE participation. It is independent from Founders and is not rewritten by Founders rules. Genesis records are represented as auditable issuance and vesting events under append-only history.

• Category: Genesis participants.
• Separation: independent from Founders allocation.
• Records: append-only issuance and vesting events.

Allocation Model

Genesis entitlement is expressed as a deterministic allocation under explicit supply boundaries and ruleset binding. Genesis participants receive a 1.3× entitlement factor: a base 1.0× issuance and an additional 0.3× portion that is strictly vesting-bound.

Key terms

• Base issuance (1.0×): the primary Genesis entitlement recorded at issuance time.
• Genesis multiplier (1.3×): total declared entitlement factor under Genesis.
• Vesting-bound portion (0.3×): additional entitlement executed only via vesting ticks.
• Ruleset binding: each record binds to a parameter version effective at issuance time.

Supply Boundary (Hard Constraint)

Genesis allocation is bounded by an explicit cap relative to total supply. Once the Genesis boundary is reached, Genesis issuance is complete. Any change that would exceed the boundary is out of scope and must be rejected by validation predicates.

USD Valuation Evidence Clause

Genesis may require USD-denominated valuation when computing participation totals, tier evaluation, or rule-defined thresholds. Any USD valuation used by Genesis must be derived from ruleset-defined oracle sources and preserved with sufficient evidence to allow independent reconstruction. The system must store the oracle inputs used at the time of computation, not merely the computed result.

Required evidence fields (minimum)

Each USD valuation record should include, at minimum:

• oracle_kind such as Chainlink AggregatorV3Interface or system oracle adapter
• oracle_contract and feed_id for the selected oracle surface
• round_id and answered_in_round where applicable
• answer and decimals for the recorded price value
• oracle_updated_at and oracle_block_number where applicable
• valuation_timestamp based on the chain-derived timestamp being priced
• valuation_method and params_version as the active ruleset binding
• evidence_refs such as tx hash, receipt id, or block hash for the valued anchor

Selection & determinism rules

• Deterministic selection: given the same evidence and the same ruleset version, the selected oracle round must be identical.
• Time anchoring: valuation is computed for the chain-derived timestamp, not UI time.
• Replay safety: reprocessing must yield the same USD value and must not create additional credit.
• Failure mode: if oracle evidence is unavailable under the ruleset, issuance must be rejected or deferred; silent fallback is disallowed.

Market Activation Anchor

Genesis vesting is anchored to market activation. Market activation is defined as the on-chain execution of the trading enable event, such as enableTrading(), that transitions the system into a tradable state.

Vesting Structure

Genesis vesting is a forward-only stream for the additional 0.3× portion. Vesting is distributed weekly on a linear basis over three (3) months, evaluated under a single protocol-defined time basis such as UTC to avoid ambiguity.

Vesting start date

Genesis vesting begins on the first Thursday following market activation (T₀). This separates market activation from vesting initiation and aligns distribution to a predictable weekly cadence.

Vesting duration

The 0.3× vesting amount vests linearly over three (3) months, distributed as weekly pro-rata ticks.

Weekly cadence

• Anchor event: market activation (T₀)
• Vesting start: first Thursday after T₀ under a protocol-defined time basis
• Distribution: weekly pro-rata distribution over 3 months
• Forward-only: vesting ticks are append-only events; corrections are new events, never edits

State Machine Formalism (Audit View)

For auditing and dispute resolution, Genesis is specified as an explicit transition system rather than a UI-driven process. This formal view does not replace the narrative above—it anchors it to a verification contract.

Formal model

The Genesis protocol is defined as a transition system M = (S, E, V, δ, I) where S are states, E are events, V are validation predicates, δ is the controlled transition function, and I are invariants that must always hold.

S — States

States describe protocol meaning, not UI appearance.

• S₀: PRE_MARKET_LOCKED — Genesis entitlement exists as records; market surfaces may be restricted.
• S₁: ENTITLEMENT_RECORDED — Base issuance recorded; vesting-bound portion declared; records written.
• S₂: MARKET_ACTIVATED (T₀) — Trading enable event observed and finalized on-chain; anchor defined.
• S₃: GENESIS_VESTING_ACTIVE — Weekly vesting ticks enabled from the first Thursday after T₀ for the 0.3× stream.
• S₄: GENESIS_VESTING_COMPLETE — The 0.3× vesting stream fully vested per schedule; no further vesting ticks.

E — Events

Events are append-only records. They carry evidence, bind to a parameter version, and remain safe under retries.

• E₁: GENESIS_PARTICIPATION_OBSERVED — Participation evidence identified and normalized.
• E₂: GENESIS_USD_VALUED — USD valuation computed and recorded with oracle evidence.
• E₃: GENESIS_ENTITLEMENT_ISSUED — Base issuance (1.0×) recorded and vesting-bound 0.3× declared.
• E₄: MARKET_ACTIVATION_OBSERVED — On-chain trading enable event finalized; defines T₀.
• E₅: VESTING_EPOCH_OPENED — First Thursday after T₀; vesting schedule becomes active.
• E₆: VESTING_TICK — Weekly pro-rata distribution for the 0.3× vesting stream.
• E₇: VESTING_COMPLETE — Final tick applied; vesting closed for Genesis.
• E₈: CORRECTION_EVENT — Corrections are recorded as new events, never edits.

V — Validation Predicates

• V₁: Evidence validity — correct chain, correct asset, correct address, valid participation window.
• V₂: Supply boundary — issuance must not exceed the Genesis cap.
• V₃: Oracle admissibility — oracle and feed identity must match the ruleset allowlist where valuation is used.
• V₄: Oracle round validity — round identifiers and timestamps must satisfy deterministic selection rules.
• V₅: USD derivation — USD value must be reconstructable from recorded oracle evidence and method.
• V₆: Ruleset binding — each event must bind to a parameter version effective at execution time.
• V₇: Anchor validity — T₀ must be derived from finalized on-chain execution evidence.
• V₈: Vesting schedule — vesting begins only on the first Thursday after T₀ and proceeds weekly for 3 months.
• V₉: Replay protection — duplicate evidence produces no additional credit.

δ — Transition Function (Controlled Execution)

The transition function δ is executed by controlled infrastructure such as watchers, settlement logic, and idempotent writers. It converts evidence and validated intent into durable, auditable records.

δ(S, E, evidence, params_version) -> (S', records_written)

Examples:
- δ(S₀, E₁, participation_evidence, vX.Y) -> S₀ + GENESIS_PARTICIPATION_OBSERVED
- δ(S₀, E₂, oracle_round_evidence, vX.Y) -> S₀ + GENESIS_USD_VALUED
- δ(S₀, E₃, derived_entitlement, vX.Y) -> S₁ + GENESIS_ENTITLEMENT_ISSUED
- δ(S₁, E₄, enableTrading_tx_finalized, vX.Y) -> S₂ + MARKET_ACTIVATION_OBSERVED(T₀)
- δ(S₂, E₅, first_thursday_after(T₀), vX.Y) -> S₃ + VESTING_EPOCH_OPENED
- δ(S₃, E₆, weekly_tick(t), vX.Y) -> S₃ + VESTING_TICK(t)
- δ(S₃, E₇, final_tick, vX.Y) -> S₄ + VESTING_COMPLETE

I — Invariants

• I₁: Append-only history — no retroactive rewrite; corrections are new events.
• I₂: Deterministic outcomes — same evidence and same params_version yield identical outcomes.
• I₃: Idempotency — reprocessing evidence must not create duplicate credit or double vesting.
• I₄: Monotonic finality — finality advances forward; reversals require explicit event handling.
• I₅: Truth hierarchy — verifiable logs and controlled transitions are authoritative; UI is informational.
• I₆: Market separation — allocation logic cannot be used to infer market availability.
• I₇: Fixed vesting stream — Genesis vesting is exactly the 0.3× stream; no other tranche is defined.
• I₈: Evidence reconstructability — USD valuation must be reproducible from recorded oracle evidence and ruleset method.

Audit Anchors & Evidence

Genesis truth is derived from authoritative anchors. These anchors are what auditors verify when resolving disputes.

• Participation evidence: contribution or participation evidence attributable to the participant address.
• USD valuation evidence: oracle inputs recorded with oracle kind, feed id, round id, timestamps, decimals, and answer.
• Activation anchor: finalized execution of the trading enable event defines T₀.
• Append-only records: issuance and vesting are represented as events, not mutable edits.
• Ruleset binding: each event binds to an effective SSOT parameter version.

Protocol-Level Block Diagram

Client / UI (informational)
  |  - pages, dashboards, cached views
  |  - user intent (non-binding)
  v
API Boundary (request normalization)
  |  - schema checks / rate limits
  v
Protocol Ruleset (Genesis)
  |  - allocation regime: 1.0× issuance + 0.3× vesting stream
  |  - valuation method: oracle allowlist + round selection rules
  |  - S: states (pre-market -> entitlement -> activated -> vesting)
  |  - V: validation predicates (cap, evidence, oracle, anchor, schedule)
  |  - I: invariants (append-only, idempotent, truth hierarchy)
  v
δ Controlled Execution (Infrastructure)
  |  - watchers/indexers (evidence ingestion)
  |  - oracle evidence capture (feed/round recording)
  |  - settlement/finality logic (T₀ anchoring)
  |  - idempotent writers (append-only events)
  |        |
  |        +--> Chain Logs (verifiable truth)
  |        |      - finalized blocks, receipts, events
  |        |
  |        +--> System Records (audit trail)
  |               - GENESIS_USD_VALUED
  |               - GENESIS_ENTITLEMENT_ISSUED
  |               - MARKET_ACTIVATION_OBSERVED (T₀)
  |               - VESTING_TICK (weekly, 0.3× stream)
  v
Read Models (informational)
  - search index, projections, UI caches

Relationship to Founders

Genesis and Founders are independent allocation categories. Neither category rewrites the records of the other. Schedules remain distinct and append-only.

• Founders vesting: begins first Wednesday after market activation and vests weekly over six months for a fixed 0.7× stream.
• Genesis vesting: begins first Thursday after market activation and vests weekly over three months for the 0.3× stream.
• Separation: records and schedules remain distinct and forward-only.

Disclaimer

This document is a technical specification for protocol behavior and auditability. It does not constitute legal, financial, or investment advice.