Deposit Flow¶

flowchart TD
    A[Authorized depositor calls deposit] --> B[Validate pubkey, credentials, signature, value]
    B --> C[_enforcePhase1CustodyBaseline]
    C --> C1[Factory metadata and vault mapping]
    C --> C2[Governor policy assertions]
    C --> C3[Beacon authority and vault runtime]
    C --> C4[Controller depositReadiness]
    C4 --> D{Readiness safe?}
    D -->|no| R1[revert fail closed]
    D -->|yes| E[Latch phase1ValidatorActivated]
    E --> F[Hash pubkey + credentials + amount + caller + allowlistEpoch]
    F --> G{allowedDeposits hash active?}
    G -->|no| R2[revert DepositIntentNotAllowlisted]
    G -->|yes| H[Clear allowedDeposits and set consumedIntents]
    H --> I[Validate deposit_data_root]
    I --> J[Emit DepositEvent]
    J --> K[Increment depositCount and update merkle branch]

Operational Meaning¶

The deposit path is intentionally fail-closed. Permissioning happens after custody/readiness checks in the current source, but both must pass before the merkle tree changes. Operators should treat a reverted deposit as useful evidence: it identifies which control plane has drifted.

Current Guardrails¶

• No runtime permissionless toggle exists in the current refactor.
• No ownerOnlyDepositorEnabled gate exists in the current refactor.
• No phase1CustodyChecksEnabled gate exists in the current refactor; custody validation is always on.
• No baselineVaultFactoryFrozen or freezeBaselineVaultFactory step exists in the current refactor.
• Phase-1 amount must be exactly 32_000_000_000 gwei.
• Withdrawal credentials must be canonical execution credentials that resolve to the factory-registered vault.
• Intent hashes bind pubkey, credentials, amount, caller, and allowlistEpoch.
• Consumed intents are one-way replay protection.

Evidence To Capture¶

Capture the allowlist event, current allowlistEpoch, factory vault mapping, controller readiness tuple, governor assertion outputs, deposit transaction, DepositIntentConsumedFor, DepositEvent, and post-deposit depositCount.

Source-Grounded Operating Model¶

Purpose¶

This page exists to separate deposit permissioning from custody/readiness and governance assertions in the exact order enforced by the current source. 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¶

allowlist admin, authorized depositor, vault factory operator, controller/oracle operator, governor monitor, incident reviewer.

Contracts Involved¶

DepositContractCTN, CenturionVaultFactory, CenturionEconomicController, CenturionUpgradeGovernor, CenturionClaimGatekeeper, vault beacon, and vault proxy.

Step-By-Step Flow¶

1. format and value checks reject malformed calldata and non-gwei values.
2. custody/readiness checks prove the route before the intent is consumed.
3. the validator pubkey is latched for one Phase-1 activation.
4. the current allowlistEpoch intent hash is checked for the exact caller.
5. allowedDeposits is cleared and consumedIntents is set.
6. deposit root validation, event emission, deposit count increment, and merkle insertion happen last.

Failure Modes¶

• missing intent.
• wrong authorized depositor.
• stale epoch after admin transfer.
• noncanonical withdrawal credentials.
• policy registry mismatch.
• readiness proof stale or unsafe.

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.deposit, _depositIntentHash, _enforcePhase1CustodyBaseline, _enforceUpgradeRegistryBaseline, _enforceDepositReadinessBaseline.