Skip to content
CenturionValidator program
Security

Security boundaries are explicit by design.

External operators hold validator signing keys. Foundation systems validate and fund seats. Vault contracts define settlement separately from off-chain policy.
Actor matrix

Four control planes. One holder each.

Control planeHeld byDetail
Validator signing key
Operator
BLS keypair generated and stored entirely in the operator's environment.
Principal funding
Foundation
Foundation allowlists and submits the 32 CTN deposit only after seat approval, enrollment-token issuance, and deposit-data validation.
Reward claims
Foundation
Operators request claims in the staker console; program executor transactions are submitted on-chain under vault delay and rate-limit rules.
Exit request path
Foundation
Where enabled by the deployed seat configuration, treasury/vault/CIP-7002 paths can initiate; consensus-layer rules still govern completion timing.
Chapter 01

Key custody

Validator BLS keys are generated and stored entirely in the operator's environment.

  1. Keys generated and stored locally.

    Operator
    You generate the validator BLS keypair offline. Private keys, keystores, and mnemonics never leave your environment.

  2. Never receives private material.

    Foundation
    The Foundation validates submitted deposit data without taking custody of validator private keys.

  3. Disjoint authentication domains.

    Network
    Consensus duties use BLS. Treasury and vault duties use ECDSA.
Chapter 02

Funding & allowlisting

The Foundation funds the 32 CTN principal only after approval and validation of the submitted onboarding data and enrollment token.

  1. Validates deposit data.

    Foundation
    Submitted public key and deposit data are checked against the seat's vault withdrawal credentials.

  2. One-use allowlist gate.

    Network
    The public model requires a pubkey-allowlist gate that is consumed exactly once by the deployed deposit path.

  3. Factory-enforced parameters.

    Vault
    The public model expects the deployed vault factory/configuration to fix the 32 CTN principal target and PrincipalFirst shortfall policy.
Chapter 03

Exit control & fault domains

Exit authority is designed to be key-separated; exact initiators depend on the deployed seat configuration.

  1. Voluntary exit via BLS.

    Operator
    You retain the ability to submit a BLS-signed voluntary exit.

  2. Force-exit via CIP-7002.

    Foundation
    Where enabled, the treasury can initiate a validator exit through the CIP-7002 system contract without possessing your signing key.

  3. Operator fault domain.

    Operator
    Uptime, client operations, and slashing from key misuse are in the operator fault domain.
Chapter 04

Rewards, settlement & claims

Rewards and exit proceeds flow through the dedicated WithdrawalVault assigned to the deployed seat.

  1. Three-state settlement flow.

    Vault
    Running -> SettlementProposed -> ExitSettlement, with deployed-version delay and cancellation rules before finalization.

  2. Claim delay and rate limit.

    Vault
    Running-phase claims use initiate and finalize with a configurable delay window.

  3. Principal-first on exit.

    Vault
    In ExitSettlement the public model recovers inflows up to 32 CTN for the Foundation before allocating excess to the beneficiary.
Deep dive

Proofs, risks, and alternatives.

The public model, intended invariants, residual risks, and other custody models considered. Verify deployed contracts and program rules before treating any item as authoritative for a specific seat.
Ready to operate

Run a seat under an explicit, versioned security model.

Keep your signing key. The Foundation handles funding, allowlisting, and vault-side settlement under the deployed seat configuration.
Apply nowSee the lifecycle