PVERSE
Reference

Status (Snapshot)

Operational snapshot of canonical system state at a point in time. This page records what the platform considered true at the snapshot boundary and is interpreted under forward-only rules.

Published: February 17, 2026
Updated: March 24, 2026
Section: Reference
Snapshot header
This page records a point-in-time operational view. It does not redefine policies, balances, or deployment rules. Where values differ, canonical definitions and SSOT interpretation take precedence.
Snapshot time (UTC)
Not set
Snapshot time (KST)
Not set
Snapshot ID
snapshot_not_set
Source set
SSOT + API + Chain

Integrity: Forward-only. If any values conflict, canonical Definitions and SSOT rules take precedence.

Related: Definitions · Security Model · Reliability Limits

System mode

This section answers the first operational question: is the system active, and what gates are currently enforced?

Item Value Source Updated
Market phase Not set (PRE-MARKET / GENESIS / SEASON1 / SEASON2-LISTING / LIVE) SSOT Not set
Trading enabled Not set (enableTrading) SSOT / Contract Not set
Manual gates Active (policy-controlled) Docs 2026-02-17
Rate limits Active (infra-controlled) Infra Not set
Rule boundary
This page is a snapshot. It does not redefine policies. It records current effective values and their sources. For canonical rule definitions, use Definitions.

Canonical numbers (SSOT snapshot)

These values are defined by SSOT. If deployment differs from SSOT, the mismatch is treated as an incident and must be resolved forward-only.

Name Value Unit Source Updated
Total token supply Not set PVR SSOT Not set
Token decimals Not set decimals SSOT Not set
Founders base allocation rule 2023 presale contributed USD converted at $0.0000038 per PVR pricing rule SSOT 2026-03-24
Founders vesting bonus rule 0.7% of the received founders allocation, distributed weekly across 6 months vesting rule SSOT 2026-03-24
Genesis bonus 30% multiplier SSOT 2026-02-17
Genesis lock 3 months lock schedule SSOT 2026-02-17
Founders interpretation
Founders allocation is no longer interpreted as a flat bonus multiplier. The canonical policy is: (1) base founders allocation from 2023 presale contributed USD at a fixed reference price of $0.0000038 per PVR, then (2) a separate vesting bonus equal to 0.7% of the received founders allocation, paid out in weekly portions across six months.

Genesis status

Participation state shown here is the counted state, meaning what the ledger considers true, not what a wallet UI might show temporarily.

Counted vs observed

Observed means the watcher detected an on-chain event. Counted means the event reached finality and has been applied to the ledger with the correct pricing snapshot and rules.

Metric Value Source Updated
Claimed Not available yet Ledger Not set
Unique participants Not available yet Ledger Not set
Counted deposits Not available yet Ledger Not set
Pending (not final) Not available yet Engine Not set

Deposit engine snapshot

The deposit engine determines when a deposit becomes final and eligible for ledger application.

Pipeline

  1. Commit created → deposit address derived and pricing snapshot locked.
  2. Watcher observed → on-chain event detected through native scan or ERC-20 transfer logs.
  3. Settler confirming → confirmation counting by chain and asset policy.
  4. Ledger applied → final credit applied according to the locked pricing snapshot and current rules.

Health

Component Status Notes Updated
Watcher Not set Scan cursor and ingestion Not set
Settler Not set Finality counting and ledger apply Not set
Database Not set Pool health and latency Not set
Backlog Not set Queue depth for events and commits Not set

Policy snapshot

These rules are enforced to avoid ambiguity and preserve forward-only accounting.

  • Pricing snapshot: locked at commit creation time and never retroactively recalculated.
  • Confirmations: enforced per chain and asset policy.
  • Underpayment handling: not final until policy threshold is met, if partial completion rules are enabled.
  • Overpayment handling: recorded and then resolved by policy through credit, hold, or manual review depending on the lane.
  • Duplicate protection: idempotent event ingestion plus deterministic ledger application.
Operational rule
If a deposit is observed but cannot be applied because of missing price snapshot, unexpected token behavior, or provider inconsistency, it is treated as pending and escalated as an incident rather than guessed.

Chain coverage

This table lists the current network coverage and the data-ingestion approach used by the engine.

Chain Provider Method Reorg tolerance Status
BSC Not set ERC-20: eth_getLogs (Transfer) / Native: block transaction scan Confirmations policy Not set
Ethereum Not set ERC-20: eth_getLogs (Transfer) / Native: block transaction scan Confirmations policy Not set

Reliability limits

These are known operational limits that can affect detection and finality timing. They are disclosed to preserve predictable expectations.

Known limits

  • RPC throttling: public or shared providers may rate-limit during congestion.
  • getLogs constraints: large ranges may be rejected, so ingestion must chunk ranges.
  • Indexing delay: providers may lag head blocks during load.
  • Nonstandard tokens: some assets may not emit standard Transfer events.

Mitigations

  • Cursor checkpoints and replay-safe ingestion.
  • Backoff and provider fallback.
  • Deterministic finality gating, where counted is never assumed from observed alone.
  • Forward-only reconciliation through additive correction rather than silent rewrites.

See: Reliability Limits

Security posture (summary)

This is a summary snapshot. The canonical design and threat model live in the security model documentation.

Area Posture Source Updated
Auth Passkeys (planned or optional) plus restricted admin boundary Docs 2026-02-17
Secrets Not set (documented policy required) Infra Not set
Recovery Not set (documented recovery flow required) Docs Not set
Change control Forward-only changes recorded in changelog Docs 2026-02-17

See: Security Model · Account Recovery · Auth (Passkeys)

Observability snapshot

Operational visibility surfaces used to debug incidents, measure latency, and validate finality.

Logs

  • Structured logs: recommended with JSON and stable keys.
  • Correlation ID: required for commit → event → settlement traceability.
  • Redaction: secrets, private keys, and sensitive PII must never enter logs.

Metrics

  • Request rate and error rate
  • Commit creation rate
  • Watcher ingestion lag
  • Settlement finality latency (p50/p95)
  • Queue depth for events and jobs

Alerts

  • Provider error spike
  • Cursor stall
  • Finality lag beyond threshold
  • Ledger apply failures

See: Observability · Operations Runbooks

What changed since last snapshot

Keep this section short and operational. Each item should link to a changelog entry.

  • 2026-03-24: Founders vesting policy updated. Weekly vesting is now defined as a bonus equal to 0.7% of the received founders allocation distributed across 6 months.

Appendix

Precedence and conflict resolution

  • Definitions and SSOT are canonical for meaning and rules.
  • Chain data becomes authoritative only after finality and successful ledger application.
  • UI is descriptive, never authoritative.

Snapshot sources

  • SSOT: canonical configuration and rule definitions.
  • API: operational build and engine metrics, if exposed.
  • Chain: current head blocks and deposit event evidence.
  • Manual: explicitly disclosed overrides, which must be logged in the changelog.
Publishing guidance
Publish snapshots with stable timestamps. Do not edit historical snapshots. If a value was wrong, publish a new snapshot and document the correction in the changelog.