Infrastructure

Overview

PVERSE infrastructure is not “a server setup.” It is an execution discipline: a constrained system of components designed so that no single component can independently create, sign, and settle value. Infrastructure executes protocol rules; it must never redefine them.

The purpose of this layer is to preserve truth hierarchy, risk partitioning, replay safety, and operational auditability even when individual services degrade, restart, or recover. If the protocol cannot explain how value moved across execution boundaries, the infrastructure model has failed.

Scope

This section defines infrastructure-layer behavior only: execution separation, payment processing semantics, wallet role partitioning, deposit attribution and settlement, and reliability boundaries.

• Authority and truth boundaries between canonical records and informational surfaces.
• Operational separation of signing, payment processing, and read/UI layers.
• Wallet architecture, deposit processing, and finality-aware settlement.
• Formal validation, replay protection, and audit-state-machine guarantees.

Core Model

Infrastructure is modeled as a controlled execution system. Components may cooperate, but they do so under explicit boundaries, append-only records, and deterministic transitions rather than through hidden privileged shortcuts.

• Separation-bound: no single component should independently create, sign, and settle value.
• Evidence-bound: canonical transitions must be attributable to verifiable anchors and ruleset bindings.
• Finality-bound: settlement must follow finalized chain evidence, not UI observations.
• Replay-safe: retries and duplicate evidence must not create duplicate credit or settlement.

Operational Behavior

In normal operation, user-facing services normalize requests and record commitments, but they do not sign or finalize value movement. Watchers ingest chain evidence, finality-aware settlement logic validates whether an observation is canonical, and controlled writers append settlement records under idempotent rules. Signing surfaces remain isolated behind policy-controlled boundaries, and wallet movement is partitioned by role.

Read models, dashboards, and projections may lag or degrade without affecting canonical truth. Operational truth remains the product of finalized chain anchors, append-only protocol records, and deterministic transitions executed under the active ruleset version.

Constraints

• UI displays, cached views, and third-party indexers are informational only and cannot define settlement truth.
• Payment infrastructure may record and route commitments, but must not silently inherit signing authority.
• If operational USD valuation is used, it must be reconstructable from recorded oracle evidence; silent fallback is disallowed.
• Corrections must be represented as new append-only events rather than retroactive edits.

Integrity Considerations

Infrastructure is trustworthy only when an auditor can reconstruct how intent became commitment, how commitment became observed evidence, how evidence crossed finality, and how settlement was written. This is why key boundaries, deterministic derivation, idempotency, and append-only history are treated as part of infrastructure truth, not implementation trivia.

• Truth clarity: finalized chain anchors and append-only protocol records are authoritative; UI is informational.
• Boundary clarity: signer, payment, and read surfaces remain intentionally separated.
• History clarity: incident recovery and correction must preserve auditability through new events, never silent rewrites.

Future Expansion

As infrastructure evolves, vendors, deployment patterns, and reliability tooling may change, but they should remain subordinate to the same execution-separation model, finality discipline, valuation evidence rules, and audit-state-machine guarantees defined here.

Summary

• Infrastructure is an execution discipline, not merely a deployment topology.
• Signing, payment processing, and UI/read surfaces are intentionally separated.
• Settlement depends on finalized evidence, deterministic validation, and idempotent append-only writers.
• If USD valuation is used operationally, it must remain reconstructable from recorded oracle evidence.

Authority & Truth Boundaries

Infrastructure is governed by strict authority separation. UI and dashboards may display state, but they do not define truth. Canonical outcomes are produced only by controlled transitions executed against verifiable evidence.

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

Execution Separation

PVERSE is designed with explicit boundaries across signing, payment processing, and user-facing services. Separation reduces blast radius, prevents single-point compromise, and sustains forward-only auditability.

• Signer boundary: signing keys and signing execution are isolated from application logic and internet-exposed services.
• Payment boundary: payment state transitions are recorded as append-only events and validated under replay-safe rules.
• UI boundary: interfaces are informational and may degrade without compromising canonical records.

Payment Infrastructure

Payment flows are handled by a dedicated payment engine responsible for creating commitments, deriving deposit addresses, and recording settlement transitions. The payment engine is intentionally designed to operate without direct signing capability.

• Commit creation: each payment intent is represented as a structured append-only record.
• Derivation: deposit addresses are derived deterministically, for example by xpub-based derivation under a ruleset version.
• Settlement: settlement is decided by verifiable chain state and recorded transitions, not by UI confirmation.

Wallet Architecture (Role Separation)

Wallet roles are separated into operational layers to limit exposure during automated operations and to keep sensitive keys away from internet-exposed components.

• Deposit wallets: receive participant deposits; used for attribution, routing, and evidence anchoring.
• Warm wallets: intermediate operational buffers that reduce hot-wallet exposure and contain automated flow radius.
• Hot wallets: limited-scope signing surface for controlled execution under strict policy.
• Gas wallets: operational gas funding to support automation without coupling directly to asset custody.

Deposit Processing (Finality-Aware)

Deposit watchers monitor on-chain activity and validate incoming transactions against recorded commitments. Settlement decisions are derived from finalized chain state and recorded transitions rather than client-side events.

• Verification: match deposits to commitments using verifiable inputs such as tx hash, logs, amounts, and token identity.
• Finality-aware: settlement uses reorg-safe policy; “seen” is not “final.”
• Replay safety: duplicate events and partial failures must not cause double settlement through idempotent processing.

Reliability Boundaries

Infrastructure is designed to degrade independently. Partial outages must not compromise key safety, allocation integrity, vesting integrity, or settlement correctness. Read surfaces may lag; write surfaces must remain safe.

May Degrade Safely

• UI delays, stale read models, search/index lag, and non-critical service restarts.
• Temporary read-only limitations in dashboards.
• Regional outages that do not affect authoritative anchors.

Must Not Fail

• Key boundaries: signing environments remain isolated and policy-controlled.
• Atomicity of recorded transitions: settlement writes are append-only and internally consistent.
• Replay protection: retries must be idempotent and must not create additional credit.
• Audit integrity: evidence anchors remain reconstructable through receipts, blocks, and parameter bindings.

USD Valuation Evidence Clause

Certain infrastructure surfaces may require USD-denominated thresholds such as tiering, gating, reporting, policy-defined limits, compliance, or dispute resolution. If USD valuation is used anywhere in operational decisions, 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)

• 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: same anchor evidence plus 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, infrastructure is specified as an explicit transition system rather than a UI-driven process. This formal view anchors operational narrative to verification primitives.

Formal Model

Infrastructure 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

• S₀: DESIGNED — boundaries defined; no execution surfaces are authoritative until controlled components are online.
• S₁: KEYBOUNDARY_READY — signing environments provisioned; policies and access controls enforced.
• S₂: PAYMENT_ENGINE_ACTIVE — commitment recording and deterministic derivation are active, without direct signing.
• S₃: WATCHERS_ACTIVE — evidence ingestion is active under finalized-chain policy.
• S₄: SETTLEMENT_ACTIVE — settlement transitions recorded append-only; idempotent writers enforce replay safety.
• S₅: DEGRADED_READONLY — read surfaces degraded; write surfaces remain safe or are intentionally paused.
• S₆: INCIDENT_RECOVERY — controlled recovery mode; corrections are appended as new events, never edits.

E — Events

• E₁: POLICY_SET — operational policy recorded, including finality thresholds, allowlists, and params_version.
• E₂: SIGNER_BOUNDARY_ATTESTED — signing-boundary attestation recorded.
• E₃: COMMIT_CREATED — payment intent recorded with normalized request and deterministic identifiers.
• E₄: DEPOSIT_ADDRESS_DERIVED — derivation record appended with xpub path or method.
• E₅: DEPOSIT_OBSERVED — chain evidence observed with preliminary attribution.
• E₆: DEPOSIT_FINALIZED — finality threshold met; anchor block and receipt recorded.
• E₇: SETTLEMENT_RECORDED — settlement transition appended with evidence refs.
• E₈: SWEEP_EXECUTED — operational movement recorded across wallet-role boundaries.
• E₉: USD_VALUATION_RECORDED — USD valuation recorded with oracle, feed, and round evidence.
• E₁₀: CORRECTION_EVENT — corrections represented as new events rather than edits.

V — Validation Predicates

• V₁: Boundary integrity — payment engine cannot sign, signer cannot create commitments, UI cannot settle.
• V₂: Ruleset binding — each event must bind to an effective params_version.
• V₃: Deterministic derivation — same inputs plus same params_version produce the same derived address and path.
• V₄: Finality policy — settlement requires finalized chain anchors and remains reorg-safe.
• V₅: Attribution validity — deposit evidence must match commitment identity under chain, asset, and amount policy.
• V₆: Idempotency — duplicate evidence must not create duplicate credit or settlement.
• V₇: Least privilege — operational transfers require policy allowlists and constrained scopes.
• V₈: Oracle admissibility — if USD valuation is used, oracle_kind and feed_id must match the allowlist.
• V₉: Oracle round validity — round_id must be retrievable and timestamps must satisfy selection windows.
• V₁₀: Append-only enforcement — corrections must be new events; retroactive rewrite is disallowed.

δ — 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₁, policy_payload, vX.Y) -> (S₀, POLICY_SET)
- δ(S₁, E₃, commit_request, vX.Y) -> (S₂, COMMIT_CREATED)
- δ(S₂, E₄, derivation_inputs, vX.Y) -> (S₂, DEPOSIT_ADDRESS_DERIVED)
- δ(S₃, E₆, finalized_receipt, vX.Y) -> (S₄, DEPOSIT_FINALIZED)
- δ(S₄, E₇, settlement_write, vX.Y) -> (S₄, SETTLEMENT_RECORDED)
- δ(S₄, E₉, oracle_round_evidence, vX.Y) -> (S₄, USD_VALUATION_RECORDED)
- δ(S₅, E₁₀, correction_evidence, vX.Y) -> (S₆, CORRECTION_EVENT)

I — Invariants

• I₁: Execution separation — no single component can independently create, sign, and settle value.
• I₂: Signing isolation — signing environments remain isolated and access is policy-controlled.
• I₃: Append-only history — operational truth is evented; corrections are new events.
• I₄: Deterministic outcomes — same evidence and same params_version yield identical results.
• I₅: Idempotency — reprocessing must not create duplicate credit or settlement.
• I₆: Finality discipline — settlement relies on finalized chain state, not UI time.
• I₇: Least privilege — wallet roles remain separated and operational scopes are minimized.
• I₈: Truth hierarchy — verifiable anchors and controlled transitions are authoritative; UI is informational.
• I₉: Evidence reconstructability — if USD valuation is used, results must be reproducible from recorded oracle evidence.

Audit Anchors & Evidence

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

• Policy anchors: POLICY_SET records, params_version, and effective dates.
• Key-boundary anchors: signer-boundary attestations and access-control proofs where applicable.
• Commit anchors: COMMIT_CREATED records and deterministic identifiers.
• Deposit anchors: DEPOSIT_OBSERVED and DEPOSIT_FINALIZED evidence, including tx hash, receipt, and block references.
• Settlement anchors: SETTLEMENT_RECORDED append-only transitions and idempotency keys.
• USD valuation anchors: oracle, feed, and round evidence recorded per the valuation clause.
• Correction handling: corrective adjustments are represented as CORRECTION_EVENT records, never rewrites.

Protocol-Level Block Diagram

Client / UI (informational)
  |  - dashboards, cached views
  |  - user intent (non-binding)
  v
API Boundary (request normalization)
  |  - schema checks / rate limits
  v
Protocol Ruleset (Infrastructure)
  |  - execution separation (no create+sign+settle in one place)
  |  - deterministic derivation (xpub/path) + params_version binding
  |  - finality-aware settlement + idempotency
  |  - wallet role separation (deposit/warm/hot/gas)
  |  - USD valuation evidence requirements (if used)
  |  - S/E/V/δ/I: auditable transition system
  v
δ Controlled Execution (Infrastructure)
  |  - watchers/indexers (evidence ingestion)
  |  - settlement/finality logic (reorg-safe policy)
  |  - idempotent writers (append-only events)
  |        |
  |        +--> Chain Logs (verifiable truth)
  |        |      - finalized blocks, receipts, events
  |        |
  |        +--> System Records (audit trail)
  |               - COMMIT_CREATED / DEPOSIT_ADDRESS_DERIVED
  |               - DEPOSIT_OBSERVED / DEPOSIT_FINALIZED
  |               - SETTLEMENT_RECORDED / SWEEP_EXECUTED
  |               - USD_VALUATION_RECORDED (if used)
  |               - CORRECTION_EVENT
  v
Read Models (informational)
  - search index, projections, UI caches