System Architecture

Purpose

This page defines the architecture of PVERSE as an auditable protocol rather than a simple UI surface. It is written as a verification target: responsibilities, boundaries, and authoritative truth sources are defined so that outcomes remain explainable under retries, partial failures, and controlled evolution.

The system is designed so canonical outcomes never depend on narrative, interface rendering, or mutable operator intent. Authority comes from validated evidence, append-only records, and controlled transition rules.

Audit Model

PVERSE is specified as the state-machine formalism M = (S, E, V, δ, I). The system is not defined by cached views, temporary UI state, or informal expectations. It is defined by validated events, controlled transitions, and non-negotiable invariants.

I — Invariants (Non-Negotiable)

Invariants define what must hold across all versions and operating conditions. Any change that violates the invariants below is outside the architecture contract.

I1 — Truth Hierarchy

UI is informational. Canonical truth is derived from authoritative anchors and append-only records produced by controlled execution.

• Authoritative: finalized chain anchors, accepted events, append-only ledger and entitlement records.
• Non-authoritative: UI, caches, client session state, estimates, projections, and convenience displays.

I2 — Append-Only History

Past canonical records are never rewritten. Corrections are represented as new events that reference prior anchors.

• Deletion and mutation are not permitted for canonical records.
• Corrections must be forward-only and preserve historical explainability.

I3 — Idempotency & Replay Safety

Reprocessing the same evidence must not produce duplicate credit, duplicate writes, or inconsistent derived state.

• Duplicate events are no-ops under idempotency keys.
• Partial failures must not create double application or divergent truth.

I4 — Monotonic Finality

Finality moves forward. Any reorg-sensitive or exceptional handling must be explicitly recorded rather than silently edited.

I5 — Forward-Only Updates

Ruleset changes apply to future outcomes only. Past outcomes remain bound to the ruleset version that produced them.

S — Derived State Views (Non-Authority)

S denotes derived views reconstructed from the event stream and append-only records. State is a projection: useful, reproducible, and explainable, but not authoritative by itself unless anchored.

E — Event Model (Append-Only)

E is the canonical evidence stream. Events are the only allowable inputs that can produce or change derived state. Every outcome-affecting action must correspond to an append-only event with verifiable anchors.

Event Families

• E_OBSERVED — Evidence observed from tx, log, or receipt anchors.
• E_CONFIRMED — Confirmation threshold reached under chain-aware rules.
• E_PRICE_SNAPSHOT — USD valuation snapshot when USD affects outcomes.
• E_ENTITLEMENT_RECORDED — Allocation or eligibility recorded under a ruleset version.
• E_LEDGER_APPLIED — Idempotent append-only ledger application.
• E_CORRECTION — Forward-only correction referencing prior anchors.

{
  "event_uid": "unique under idempotency key (deterministic or content-addressed)",
  "event_type": "E_OBSERVED | E_CONFIRMED | E_PRICE_SNAPSHOT | E_ENTITLEMENT_RECORDED | E_LEDGER_APPLIED | E_CORRECTION",
  "subject": "account_id / wallet / allocation_id / asset_id",
  "chain": { "chain_type": "EVM|TRON|...", "chain_id": "..." },
  "ruleset_version": "vX.Y",
  "observed_at_utc": "YYYY-MM-DDTHH:MM:SSZ",
  "anchors": { "tx_hash": "...", "log_index": "...", "block_number": "...", "block_hash": "...", "finality": "..." },
  "inputs": { "evidence": "...", "params": {}, "refs": ["..."] },
  "validation": { "passed": true, "checks": ["..."] },
  "effects": { "state_delta": "...", "records_written": ["..."] }
}

V — Validation Predicates (Acceptance Gates)

V defines the acceptance gate for events. If validation fails, the event must not influence derived state. Validation exists for deterministic replay, consistency, and audit reconstruction.

Base Evidence Requirements

USD Valuation Evidence Clause

If USD valuation influences eligibility, tier selection, allocation, vesting, or any canonical outcome, then USD becomes an audit input and must be reconstructable from oracle evidence under deterministic rules.

δ — Controlled Transition Function

δ defines controlled execution: δ(S, E) → S′. No transition is permitted without a validated event, and the system must remain explainable under retries, partial failures, restarts, and replay.

Transition Pipeline

observe   : accept evidence into E only after V passes
confirm   : apply chain-aware confirmation gates
valuate   : if USD affects outcomes, require E_PRICE_SNAPSHOT with full oracle evidence
entitle   : record entitlement/allocation as append-only output bound to ruleset_version
apply     : apply to ledger idempotently
correct   : represent corrections as new events referencing prior anchors

Layer Mapping

Layers act as operational boundaries. Each layer either constrains transitions, executes them, or renders them. No layer may silently override another.

Truth Sources

The architecture distinguishes authoritative sources from informational surfaces so truth does not shift accidentally during outages, retries, cache drift, or rendering errors.

Versioning & Forward-Only Policy

PVERSE evolves through forward-only updates. Parameter changes may be required to improve balance, mitigate abuse, or address technical constraints. Such changes apply to future outcomes only and do not rewrite history.

Failure Boundaries

The architecture defines what may degrade safely and what must not fail. Non-critical degradation is permitted. Integrity-critical boundaries must remain intact.

May Degrade Safely

• UI delays, stale read models, and non-critical cache issues.
• Indexing lag and temporary read-only limitations.
• Non-critical service restarts that do not rewrite state.

Must Not Fail

• Key boundaries: signing keys and sensitive credentials remain protected.
• State atomicity: no double allocation, no duplicate entitlement application, no divergent commit state.
• Audit integrity: history remains preserved and explainable via recorded events and anchors.

Summary

• PVERSE architecture is specified as M = (S, E, V, δ, I) for audit-grade explainability.
• I defines truth hierarchy, append-only history, idempotency, monotonic finality, and forward-only evolution.
• S represents derived views that are useful but not authoritative by themselves.
• E is the append-only evidence stream backing all outcome-affecting actions.
• V gates acceptance and requires oracle/feed/round evidence when USD affects outcomes.
• δ is controlled execution: no transition without validated events, replay safety, and reconstruction integrity.