Security & Finality

Overview

Security in PVERSE is not a collection of “best practices.” It is a protocol stance: authority is explicit, truth is reconstructable, and history is forward-only. The system is designed so that outcomes remain explainable even under partial outages, interface failures, or repeated processing attempts.

The goal is not cosmetic resilience. The goal is to ensure that canonical outcomes remain attributable to verifiable evidence, bound to explicit ruleset versions, and reconstructable even when non-authoritative surfaces degrade or disagree.

Scope

This page defines system-wide guarantees only: truth hierarchy, finality, non-retroactive history, failure boundaries, replay safety, and valuation evidence requirements.

• Authority and truth hierarchy across chain state, records, and interfaces.
• Non-retroactive history and correction handling.
• Finality model and explicit failure boundaries.
• Formal validation, deterministic USD valuation evidence, and audit-state-machine guarantees.

Core Model

Security & finality are modeled as a controlled transition system. Interfaces may display state, but they do not define it. Canonical outcomes exist only when verifiable anchors satisfy finality rules and controlled execution writes append-only records under the active ruleset.

• Authority-bound: finalized chain anchors and append-only records are authoritative; UI is informational.
• Forward-only: corrections are represented as new events rather than silent rewrites.
• Finality-bound: authoritative outcomes require finalized evidence plus controlled transition recording.
• Replay-safe: retries and repeated evidence must not produce duplicate credit or contradictory outcomes.

Operational Behavior

In normal operation, chain evidence is first observed, then validated under chain-specific finality rules, and only then used to derive canonical transitions. Read models, dashboards, and external indexers may lag or fail independently without changing truth, because canonical state is anchored to finalized evidence and append-only writes rather than UI time or cache state.

When failures occur, the system may enter degraded or recovery modes, but those modes do not authorize silent mutation of history. Corrections remain forward-only: a later event may supersede, offset, or qualify a prior record, but it does not erase the prior record from the audit trail.

Constraints

• UI, cached views, and third-party indexers are informational only and cannot define authoritative outcomes.
• If finality is not satisfied, evidence may be observed but must not be treated as canonical.
• If USD valuation is used, it must be reconstructable from recorded oracle evidence; silent fallback is disallowed.
• Retroactive rewrite is disallowed; corrections must be represented as new append-only events.

Integrity Considerations

Security only remains meaningful if disputes can be resolved from anchors rather than narrative. If the system cannot reconstruct who observed what, when finality was achieved, which ruleset version applied, and how the resulting transition was recorded, the security model has failed.

• Truth clarity: authoritative state is chain- and record-based, not interface-based.
• History clarity: non-retroactive correction preserves auditability under failure and recovery.
• Formal clarity: the audit view M = (S, E, V, δ, I) exists to keep disputes resolvable from evidence rather than soft interpretation.

Future Expansion

As PVERSE evolves, infrastructure, settlement paths, and read surfaces may expand, but they should remain subordinate to the same truth hierarchy, finality definitions, replay safety, and append-only guarantees introduced here.

Summary

• Security & finality are protocol guarantees grounded in explicit authority, verifiability, and forward-only history.
• Finality is record-based: authoritative outcomes depend on finalized chain anchors and append-only system transitions, not UI time.
• Truth sources are hierarchical: verifiable logs and controlled execution are authoritative; UI is informational.
• If USD valuation is used, it must be reconstructable from recorded oracle/feed/round evidence under deterministic rules.

Authority & Truth Hierarchy

PVERSE enforces a strict separation between informational surfaces and authoritative sources. Interfaces may display state, but they do not define it. Canonical outcomes are produced only by rule-defined validation and append-only transitions derived from verifiable anchors.

• Authoritative: finalized chain state, receipts, block anchors, and append-only protocol records.
• Non-authoritative: UI, cached views, third-party indexers, client session state, and estimates.

Non-Retroactive Principle

PVERSE is non-retroactive: past records are preserved as recorded history. If corrections are required, they are represented as new events that preserve the audit trail. Changes apply to future behavior only.

Finality Model

Finality defines when an outcome is considered irreversible and authoritative. In PVERSE, finality is anchored to verifiable records rather than UI timestamps.

• Chain finality: an on-chain event is finalized under the chain’s finalized state, or chain-specific finality rule.
• System finality: a transition is final when recorded as an append-only event derived from finalized chain truth and rule-defined validation.
• UI is not final: displays may lag, drift, or fail without changing canonical outcomes.

Failure Boundaries

The system defines what may degrade safely and what must remain invariant. Partial outages must not compromise keys, atomicity, replay safety, or audit integrity.

May Degrade Safely

• UI delays and stale read models.
• Indexer and search lag, and temporary read-only limitations.
• Non-critical service restarts without state rewriting.

Must Not Fail

• Key boundaries: signing keys and sensitive credentials remain protected and policy-controlled.
• State atomicity: no double settlement, no duplicate assignment, no inconsistent commits.
• Replay protection: retries are idempotent; duplicate evidence cannot create additional credit.
• Audit integrity: history remains preserved and reconstructable from recorded anchors.

USD Valuation Evidence Clause

Certain system decisions may reference USD-denominated thresholds, such as tiering, gating, reporting, policy limits, compliance, or dispute resolution. If USD valuation is used, it MUST be derived from ruleset-defined oracle sources and preserved with sufficient evidence to allow independent reconstruction. The system SHALL store the oracle inputs used at computation time, not merely the computed result.

Required Evidence Fields (Minimum)

Each USD valuation record MUST include, at minimum:

• oracle_kind, for example Chainlink AggregatorV3Interface or a system oracle adapter.
• oracle_contract and feed_id.
• round_id and answered_in_round where applicable.
• answer and decimals.
• 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 ruleset binding.
• evidence_refs such as tx hash, receipt id, or block hash for the anchor being valued.

Selection & Determinism Rules

• Deterministic selection: same anchor evidence and same ruleset version must select the same oracle round.
• Time anchoring: valuation is computed for chain-derived time, 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, the operation MUST be rejected or deferred; silent fallback is disallowed.

State Machine Formalism (Audit View)

For auditing and dispute resolution, security & finality are specified as an explicit transition system rather than a UI-driven process. This formal view binds narrative claims to verification primitives.

Formal Model

The system 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₀: NON_AUTHORITATIVE — UI and read models may exist, but no interface defines canonical truth.
• S₁: EVIDENCE_OBSERVED — chain evidence observed, but not yet final under finality policy.
• S₂: CHAIN_FINALIZED — evidence meets chain finality definition; anchors are reorg-safe.
• S₃: SYSTEM_RECORDED — transition recorded append-only with params_version binding.
• S₄: FINAL — outcome is authoritative: finalized anchors, recorded transition, and invariants satisfied.
• S₅: DEGRADED — partial outage; read surfaces may lag; write surfaces remain safe or intentionally paused.
• S₆: INCIDENT_RECOVERY — recovery mode; corrections are appended as new events, never edits.

E — Events

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

• E₁: EVIDENCE_INGESTED — chain log or receipt observed with references.
• E₂: FINALITY_CONFIRMED — evidence meets finalized policy and anchor recorded.
• E₃: TRANSITION_RECORDED — protocol transition appended with params_version binding.
• E₄: READ_MODEL_UPDATED — projections or caches updated for informational surfaces.
• E₅: USD_VALUATION_RECORDED — valuation appended with oracle, feed, and round evidence.
• E₆: CORRECTION_EVENT — corrections appended as new events, bound to anchors.

V — Validation Predicates

Validation predicates gate transitions. If a predicate fails, the transition is rejected or becomes a no-op.

• V₁: Truth hierarchy — UI and read models cannot define canonical outcomes.
• V₂: Chain finality — anchors must meet finalized policy before becoming authoritative.
• V₃: Ruleset binding — each canonical write binds to an effective params_version.
• V₄: Idempotency — duplicate evidence cannot create duplicate credit or contradictory transitions.
• V₅: Non-retroactive enforcement — corrections must be new events; retroactive rewrite is disallowed.
• V₆: USD oracle admissibility — if valuation is used, oracle_kind and feed_id must match allowlists.
• V₇: Oracle round validity — round_id retrievable, and timestamps satisfy selection windows.

δ — Transition Function (Controlled Execution)

The transition function δ is executed by controlled infrastructure. It converts evidence and validated intent into durable, auditable records.

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

Examples:
- δ(S₀, E₁, observed_receipt, vX.Y) -> (S₁, EVIDENCE_INGESTED)
- δ(S₁, E₂, finality_anchor, vX.Y) -> (S₂, FINALITY_CONFIRMED)
- δ(S₂, E₃, transition_payload, vX.Y) -> (S₃, TRANSITION_RECORDED)
- δ(S₃, E₅, oracle_round_evidence, vX.Y) -> (S₃, USD_VALUATION_RECORDED)
- δ(S₅, E₆, correction_evidence, vX.Y) -> (S₆, CORRECTION_EVENT)

I — Invariants

Invariants are non-negotiable constraints. If any change would violate an invariant, it is out of scope.

• I₁: Non-retroactive history — past records are preserved; corrections are new events.
• I₂: Finality is record-based — authoritative outcomes depend on finalized anchors and recorded transitions.
• I₃: Truth separation — UI and third-party views are non-authoritative.
• I₄: Deterministic outcomes — same evidence and same params_version yield identical outcomes.
• I₅: Idempotency — reprocessing cannot create duplicate credit or contradictory transitions.
• I₆: Failure isolation — partial outages must not compromise keys, atomicity, or audit integrity.
• I₇: Evidence reconstructability — if USD valuation is used, results are reproducible from recorded oracle evidence.

Audit Anchors & Evidence

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

• Finality anchors: finalized blocks, receipts, and chain-specific finality proofs.
• System truth anchors: append-only event records bound to params_version.
• USD valuation anchors: oracle, feed, and round evidence recorded per the valuation clause, if used.
• Correction handling: corrective adjustments are appended as CORRECTION_EVENT records, never rewrites.

Protocol-Level Block Diagram

Client / UI (informational)
  |  - dashboards, cached views, third-party UIs
  v
API Boundary (normalization)
  |  - schema checks / rate limits
  v
Protocol Ruleset (Security & Finality)
  |  - truth hierarchy (UI is non-authoritative)
  |  - non-retroactive enforcement (forward-only)
  |  - finality definitions (chain + system)
  |  - USD valuation evidence requirements (if used)
  |  - S/E/V/δ/I: auditable transition system
  v
δ Controlled Execution (Infrastructure)
  |  - evidence ingestion + finality policy
  |  - idempotent writers (append-only events)
  |        |
  |        +--> Chain Logs (verifiable truth)
  |        |      - finalized blocks, receipts, events
  |        |
  |        +--> System Records (audit trail)
  |               - FINALITY_CONFIRMED
  |               - TRANSITION_RECORDED
  |               - USD_VALUATION_RECORDED (if used)
  |               - CORRECTION_EVENT
  v
Read Models (informational)
  - projections, search index, UI caches