Skip to content

System Map

High-Level Component Map

flowchart LR
    G[CenturionUpgradeGovernor]
    P1[DepositContractCTN Proxy]
    P2[CenturionEconomicController Proxy]
    P3[CenturionVaultFactory Proxy]
    P4[CenturionClaimGatekeeper Proxy]
    B[CenturionUpgradeableBeacon]
    V[CenturionBeaconProxy Vaults]
    O[Oracle and Backend Inputs]
    R[Receipt Events]

    G -->|assertTransparentProxyPolicy| P1
    G -->|assertTransparentProxyPolicy| P2
    G -->|assertTransparentProxyPolicy| P3
    G -->|assertTransparentProxyPolicy| P4
    G -->|assertBeaconPolicy| B

    P3 -->|deployVault| V
    V -->|controller-only operations| P2
    P1 -->|phase-1 baseline checks| P3
    P1 -->|readiness and risk checks| P2
    P2 -->|claim authorization| P4

    O --> P2
    R --> P2

Authority Layers

  • Governance authority: approves implementations, registers targets, executes upgrades, can final-freeze beacons.
  • Deposit authority: controls allowlist and baseline configuration in DepositContractCTN.
  • Controller authority: controls risk updates, receipt accounting, reserve coverage, settlement sequencing.
  • Beneficiary authority: can initiate/finalize rewards within claim-state constraints.
  • Executor authority: temporary scoped sponsor permissions controlled by controller through gatekeeper grants.

Design Intent

  • Critical state transitions fail closed when evidence is stale, conflicting, or out of policy.
  • Claimability is ledger-driven, not raw-balance-driven.
  • Upgradeability is a first-class property; safety depends on governance discipline and monitoring.

Source-Grounded Operating Model

Purpose

This page exists to show the whole Phase-1 control surface before readers dive into individual flows. 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

governance signers, admission operators, controller/oracle operators, factory operators, beneficiaries, executors, auditors.

Contracts Involved

CenturionUpgradeGovernor, DepositContractCTN, CenturionVaultFactory, CenturionEconomicController, CenturionClaimGatekeeper, CenturionWithdrawalVault, transparent proxies, and the vault beacon.

Step-By-Step Flow

  1. governance registers and approves policy-compatible implementations.
  2. factory and controller bind a coherent vault deployment surface.
  3. allowlist administration admits only exact deposit intents.
  4. deposit custody checks confirm vault, beacon, controller, registry, router, and readiness state.
  5. controller observations and receipts drive claim and settlement state.
  6. gatekeeper enforces claim authorization and period/executor caps.

Failure Modes

  • unregistered implementation or beacon.
  • stale readiness or reserve proof.
  • wrong vault metadata.
  • mis-scoped admission intent.
  • oracle or receipt contradiction.

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

DepositContractCTN._enforcePhase1CustodyBaseline, CenturionUpgradeGovernor.assertTransparentProxyPolicy, CenturionVaultFactory.deployVault, CenturionEconomicController.depositReadiness, CenturionClaimGatekeeper.authorizeAndCheckClaim.