Skip to content

Economic Observation Flow

flowchart LR
    O[Oracle observation input] --> U[updateRiskObservationFinalModel]
    U --> R[Risk classification]
    R --> D[Dust state refresh]
    D --> C[Current claim mode and claim state]
    C --> S[Optional consensus smoothing]
    S --> L[Ledger and exposure updates]

Important Behaviors

  • same-epoch replay is detected and ignored
  • same-epoch conflict can force quarantine behavior
  • stale or unsafe observations disable reward enabling
  • smoothing advances and recoup are tracked in dedicated debt/exposure fields
  • pending claims are canceled when transitions invalidate prior claim assumptions

Source Inputs

updateRiskObservationFinalModel accepts observation fields and authoritative delta data. Source ids and source groups are part of replay protection for economic accounting. Receipt paths use separate source handling, so backend systems must not reuse ids across distinct economic facts.

Operator Implications

If an observation is stale, conflicting, or unsupported by finalized data, do not post receipts or enable claims that depend on it. If a same-epoch conflict appears, preserve both hashes and escalate to backend/oracle engineering before attempting remediation.

Evidence To Archive

Finalized epoch proof, raw source payload, source id, source group id, accepted transaction, emitted risk/conflict events, and post-state claimability.

Source-Grounded Operating Model

Purpose

This page exists to explain how offchain observations become onchain risk, dust, reserve, and claim state. Treat it as an operating model, not as proof that any deployed address is already correct. Deployed-state evidence is still Evidence required unless archived separately.

Actors

oracle/backend engineer, risk reviewer, controller owner, receipt operator, governance signer, auditor.

Contracts Involved

CenturionEconomicController, CenturionClaimGatekeeper, accounting libraries, and per-validator vaults.

Step-By-Step Flow

  1. backend produces finalized validator balance/effective-balance evidence.
  2. operator submits a risk observation with source and epoch metadata.
  3. controller derives risk, dust, reserve health, and claim state.
  4. receipt events are recorded and classified against safe epochs.
  5. claimable reward and uncovered deficit buckets are recalculated.
  6. unsafe or conflicting observations cancel or block claim paths.

Failure Modes

  • stale observation.
  • same-epoch conflict.
  • receipt before safe epoch.
  • reserve coverage below floor.
  • slashing or exit flags forcing unsafe state.

Fail-Closed Behavior

The handbook treats missing, stale, mismatched, or contradictory evidence as a stop condition. Onchain paths generally revert, cancel pending claims, or leave queued operations unexecuted rather than accepting a weaker proof. Operators should preserve the revert reason or event trail before retrying.

Operator Implications

  • Do not substitute Upgrade governance evidence for Deposit permissioning evidence.
  • Do not substitute Deposit permissioning evidence for Custody/readiness evidence.
  • Do not substitute Custody/readiness evidence for Economic/claim safety evidence.
  • Archive the source snapshot, transaction hashes, event logs, and reviewer approvals that correspond to the specific operation.

Source References

updateRiskObservationFinalModel, recordVaultReceiptFinalModel, deriveRiskState, deriveClaimState, runningUncoveredPrincipalDeficitWei.