Validator Lifecycle State Machine¶

stateDiagram-v2
    [*] --> Candidate
    Candidate --> VaultProvisioned: deployVault
    VaultProvisioned --> Deposited: deposit accepted
    Deposited --> Running: observations healthy
    Running --> Warning: degraded balance/effective balance
    Running --> Recovery: reduced effective balance
    Running --> StopLoss: slashed/ejection/critical balance
    Warning --> Running: healthy observation
    Recovery --> Running: recovered observation
    StopLoss --> ExitRequested: requestValidatorExit
    Running --> ExitRequested: planned exit
    ExitRequested --> ExitAccepted: recordExitAccepted
    ExitAccepted --> SettlementProposed
    SettlementProposed --> Settled: finalizeSettlement
    Settled --> [*]

Data Sources¶

Validator state is driven by factory deployment records, deposit events, consensus observations, risk updates, exit-request state, receipt accounting, and settlement records.

Risk Transitions¶

CenturionClaimGatekeeper.deriveRiskState and controller update paths classify observations into healthy, dust, warning, recovery, stop-loss, exiting, or quarantine states. Slashing, ejection risk, unsafe balances, or inconsistent credentials should move the validator out of reward-enabled operation.

Failure/Hold States¶

Observation quarantine, stale observations, conflicting same-epoch observations, and stop-loss are hold states for claims. Operators should treat them as requiring evidence before re-enabling normal payout behavior.

Contract References¶

CenturionVaultFactory.deployVault
DepositContractCTN.deposit
CenturionEconomicController.updateRiskObservationFinalModel
requestValidatorExitDynamic
requestValidatorExitWithManualFee
recordExitAccepted
proposeSettlementWithGuard
finalizeSettlement

Expanded State Model¶

State List¶

Planned.
VaultDeployed.
Deposited.
Active.
ExitRequested.
ExitAccepted.
Settling.
Settled.
Slashed.

Transition Table¶

From	To	Transition trigger	Actor or data source	Fail-closed behavior
`Planned`	`VaultDeployed`	Source event/function evidence	Operator or controller data source	Fail closed if evidence missing
`VaultDeployed`	`Deposited`	Source event/function evidence	Operator or controller data source	Fail closed if evidence missing
`Deposited`	`Active`	Source event/function evidence	Operator or controller data source	Fail closed if evidence missing
`Active`	`ExitRequested`	Source event/function evidence	Operator or controller data source	Fail closed if evidence missing
`ExitRequested`	`ExitAccepted`	Source event/function evidence	Operator or controller data source	Fail closed if evidence missing
`ExitAccepted`	`Settling`	Source event/function evidence	Operator or controller data source	Fail closed if evidence missing
`Settling`	`Settled`	Source event/function evidence	Operator or controller data source	Fail closed if evidence missing
`Any live state`	`Slashed`	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 validator 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.