Deposit Lifecycle State Machine¶

stateDiagram-v2
    [*] --> VaultProvisioned
    VaultProvisioned --> BaselineReady: factory/controller/governor coherent
    BaselineReady --> IntentActive: allowlistAdmin adds intent
    IntentActive --> Submitted: authorized depositor calls deposit
    Submitted --> Rejected: format, custody, readiness, intent, or root failure
    Submitted --> Activated: phase1ValidatorActivated set
    Activated --> IntentConsumed: allowedDeposits cleared and consumedIntents set
    IntentConsumed --> MerkleUpdated: DepositEvent + depositCount increment
    MerkleUpdated --> [*]
    Rejected --> IntentActive: retry after remediation if intent still valid

States¶

State	Meaning	Source references
`VaultProvisioned`	Factory deployed a vault and initialized controller seat.	`CenturionVaultFactory.deployVault`, `CenturionEconomicController.initializeSeat`
`BaselineReady`	Deposit baseline addresses and metadata are coherent.	`DepositContractCTN.initialize`, `_configureBaseline`
`IntentActive`	`allowedDeposits[intentHash]` is true.	`addAllowedDepositFor`, `allowedDeposits`
`Submitted`	`deposit(...)` transaction entered validation.	`DepositContractCTN.deposit`
`Activated`	Pubkey hash is latched for Phase 1.	`phase1ValidatorActivated`
`IntentConsumed`	Intent can no longer be reused.	`allowedDeposits`, `consumedIntents`
`MerkleUpdated`	Deposit event emitted and root state updated.	`DepositEvent`, `depositCount`, `branch`
`Rejected`	Revert preserved pre-state.	All deposit errors

Allowed Callers And Data Sources¶

allowlistAdmin controls intent creation and removal.
Authorized depositor submits the deposit.
Factory, controller, vault, beacon, router, and governor are data sources during custody validation.

Failure/Hold States¶

Deposits hold fail-closed on missing intent, consumed intent, unsafe readiness, stale reserve proof, open bootstrap router, policy assertion failure, wrong beacon authority, wrong withdrawal credentials, duplicate activation, or bad deposit-data root.

Operator Implications¶

Never fix a failed deposit by relaxing assumptions. Identify the failed control plane and produce evidence before retrying.

Expanded State Model¶

State List¶

VaultPending.
BaselineReady.
IntentActive.
DepositSubmitted.
Activated.
IntentConsumed.
Rejected.

Transition Table¶

From	To	Transition trigger	Actor or data source	Fail-closed behavior
`VaultPending`	`BaselineReady`	Source event/function evidence	Operator or controller data source	Fail closed if evidence missing
`BaselineReady`	`IntentActive`	Source event/function evidence	Operator or controller data source	Fail closed if evidence missing
`IntentActive`	`DepositSubmitted`	Source event/function evidence	Operator or controller data source	Fail closed if evidence missing
`DepositSubmitted`	`Activated`	Source event/function evidence	Operator or controller data source	Fail closed if evidence missing
`Activated`	`IntentConsumed`	Source event/function evidence	Operator or controller data source	Fail closed if evidence missing
`Any state`	`Rejected`	Source event/function evidence	Operator or controller data source	Fail closed if evidence missing

Contract And Function References¶

Use the generated Solidity inventory to reconcile each transition with the current contract functions and events before relying on the state machine for production. For deposit transitions, source-grounded references must include the relevant controller, deposit, governor, gatekeeper, factory, or vault function named by the page.

Operational Impact¶

Every transition changes what an operator is allowed to do next. A transition into a blocked, cancelled, slashed, unsafe, or final state must stop routine automation until an independent reviewer confirms the next runbook.

Incident Implications¶

Unexpected transitions are incident evidence. Archive block number, transaction hash, decoded events, current state reads, and offchain source data. If the transition cannot be traced to a known runbook or approved automation, escalate before retrying dependent actions.