How it works
From BYO-BLS onboarding to vault settlement.
The external operator path keeps validator signing keys with you while Foundation systems validate onboarding data submitted under an enrollment token, fund principal after approval, and enforce seat economics through the deployed vault version.
Lifecycle
From application to active validator.
A process with explicit handoffs between you, the Foundation, and the network.
- Phase 1
Apply
- Phase 2
Set up
- Phase 3
Validate & fund
- Phase 4
Activation
Economic flow
The seat lifecycle separates custody, funding, and settlement.
Operator generates and stores the validator BLS keypair and builds deposit data locally.
Approved operator receives a short-lived signed enrollment token scoped to the assigned seat.
Operator submits the enrollment token alongside the validator pubkey and deposit data for the assigned seat.
Foundation verifies the enrollment token, then validates pubkey, withdrawal credentials, and principal target against seat policy.
Foundation funds the 32 CTN deposit transaction after validation, conditional on final program approval.
Validator waits through consensus-layer activation processing, then becomes active under operator signing control.
Rewards, claims, and exit proceeds are governed by the WithdrawalVault.
State machine
Every transition has a clear trigger.
Applied
Eligible
Token issued
Data submitted
Validated
Allowlisted
Deposited
Active
Applied -> Eligible
Program review approves operator and seat assignment.
Eligible -> Token issued
Operator receives a short-lived signed enrollment token scoped to the assigned seat.
Token issued -> Data submitted
Operator submits the enrollment token, validator pubkey, and deposit data through the console.
Data submitted -> Validated
Foundation verifies the enrollment token, withdrawal credentials, and deposit payload.
Validated -> Allowlisted
One-use deposit permission is written on-chain.
Allowlisted -> Deposited
Foundation funds 32 CTN after final validation and consumes the allowlist entry.
Deposited -> Active
Consensus-layer activation processing completes.
Vault phases
Running claims and exit settlement use separate rules.
Phase 0
Running
Validator is active under operator signing controlNormal operations. Claims are submitted through the console and executed on-chain under vault delay and rate-limit safeguards.
Two-step flow: initiate, wait through the configured delay, then finalize payout.
Phase 1
SettlementProposed
Cancellable intermediate phase before settlement becomes irreversibleTreasury has proposed settlement. Beneficiary claims are paused while a cancellation window protects against false positives.
Treasury calls proposeSettlement with a front-running guard.
Phase 2
ExitSettlement
Irreversible principal-first payout logicSettlement is final. Treasury recovers principal first; any excess goes to the beneficiary.
Both beneficiary and treasury can make instant claims in this phase.
Auto-settlement
Watchers can move exited validators into principal-first settlement when seat conditions are satisfied.
The intended path can be automated, but slashed or underfunded exits can require manual review.
Gate 1
Validator exit detected and funds swept to the vault.
The vault watcher confirms the consensus-layer exit and sweeps the validator balance into the WithdrawalVault.
Gate 2
Fresh validator data proves safety conditions.
A recent beacon-chain proof must confirm the validator is fully exited and the swept balance matches expectations.
Gate 3
Running-phase claims are paused when protection checks fail.
If any guard fails, running-phase reward claims for the affected seat are paused until manual review clears them.
Gate 4
Settlement is proposed with front-running guards.
The settlement transaction is proposed with deadline and slippage guards so the principal-first split cannot be racing.
Gate 5
Finalization waits through the configured delay window.
Once proposed, settlement only finalizes after the configured delay window so watchers can flag anomalies.
Timing
Some phases are operational; activation is protocol-governed.
Application -> Eligibility
Review dependent
Key generation + data submission
Operator dependent
Validation -> Allowlist
Operationally variable
Allowlisted -> Deposited
Treasury funding dependent
Deposited -> Active
Variable consensus-layer activation queue
Reward claim processing
Vault-policy delay
Execution stays with the operator; capital-protection rules stay in the deployed vault version.
BLS signing remains operator-controlled.
Deposit funding is Foundation-controlled.
Reward and exit accounting is vault-controlled.
Consensus-layer queue timing remains network-controlled.
Consensus-layer timing can vary by queue depth.
Next step