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.

  • 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 after validation.

  • Reward claims

    Vault

    Beneficiary wallet claims rewards under vault rules and delay safeguards.

  • Exit request path

    Network

    Treasury/vault/EIP-7002 path can initiate; consensus layer governs completion.

Chapter 01

Key custody

Validator BLS keys are generated and stored entirely in the operator's environment. Onboarding only moves the public key and deposit data.

  1. Keys generated and stored locally.

    Operator

    You generate the validator BLS keypair offline. Private keys, keystores, and mnemonics never leave your environment. Submission to the Foundation is limited to the public key and deposit data for your assigned seat.

  2. Never receives private material.

    Foundation

    The Foundation validates the submitted deposit data against seat-specific withdrawal credentials and allowlist policy. It does not take custody of, regenerate, or derive validator private keys.

  3. Disjoint authentication domains.

    Network

    Consensus duties (attest, propose, voluntary exit) are authenticated by BLS. Treasury duties (allowlist, deposit, settle, force-exit) are authenticated by ECDSA. No consensus operation accepts ECDSA; no vault function accepts BLS.

Chapter 02

Funding & allowlisting

The Foundation funds the 32 CTN principal only after validating submitted data against one-use, pubkey-bound allowlist intents.

  1. Validates deposit data.

    Foundation

    Submitted public key and deposit data are checked against the seat's vault withdrawal credentials, principal target, and allowlist policy before any on-chain action.

  2. One-use allowlist gate.

    Network

    DepositContractCTN enforces a pubkey-allowlist gate. Each intent hash (keccak256 of pubkey, withdrawal credentials, amount, depositor, and ownership epoch) is consumed exactly once and cannot be re-allowlisted.

  3. Factory-enforced parameters.

    Vault

    VaultFactory hardcodes the 32 CTN principal target and shortfall policy (PrincipalFirst). A second registry enforces one vault per validator public key hash, eliminating misconfiguration at deployment.

Chapter 03

Exit control & fault domains

Either party can initiate an exit; neither needs the other's key. Fault responsibility is explicit and non-overlapping.

  1. Voluntary exit via BLS.

    Operator

    You retain the ability to submit a BLS-signed voluntary exit at any time. The exit balance is swept to your vault and handled under vault settlement rules.

  2. Force-exit via CIP-7002.

    Foundation

    The treasury can initiate a validator exit through the CIP-7002 system contract without possessing your signing key. Consensus-layer queueing and timing still govern when the exit completes.

  3. Operator fault domain.

    Operator

    Uptime, client operations, and slashing from key misuse are in the operator fault domain. Since the Foundation never holds your BLS key, any slashable message is unambiguously attributable to you.

Chapter 04

Rewards, settlement & claims

Rewards and exit proceeds flow through a dedicated WithdrawalVault under principal-first accounting, with claim delays and rate limits bounding damage from key compromise.

  1. Three-state settlement flow.

    Vault

    Running → SettlementProposed → ExitSettlement. A 1-hour delay between proposal and finalization plus an explicit cancellation path protect against false-positive settlement triggers before the transition becomes permanent.

  2. Claim delay and rate limit.

    Vault

    Running-phase claims use initiate + finalize with a 24-hour delay by default. A per-30-day rate limit caps extraction from a compromised beneficiary key regardless of watcher liveness.

  3. Principal-first on exit.

    Vault

    In ExitSettlement the Foundation recovers inflows up to 32 CTN; any excess is allocated to the beneficiary. A 90-day drain deadline prevents funds from being permanently locked.

Deep dive

Proofs, risks, and alternatives.

The contracts, invariants, residual risks, and the other custody models we considered. Open any panel for details.

On-chain architecture

Three contracts enforce the security model.

TreasuryRouter

A forwarding proxy that decouples treasury identity from the operational signing key. The activeSigner can be rotated via a time-locked two-step process (7-day delay) without redeploying vaults.

VaultFactory

Deploys vaults with enforced parameters: 32 CTN principal target and PrincipalFirst shortfall policy are hardcoded. A registry enforces one vault per validator public key hash.

DepositContractCTN

Two independently toggleable gates: a pubkey-allowlist gate (one-use intent hashes bound to pubkey, withdrawal credentials, amount, depositor, and ownership epoch) and an owner-only depositor gate.

Formal properties

Proven invariants and structural guarantees.

Conservation of funds

No vault operation creates or destroys value. Total lifetime inflows always equal current balance plus cumulative rewards claimed plus cumulative principal claimed.

Arithmetic

Counter isolation

The rewards counter is incremented only by beneficiary-authenticated calls; the principal counter only by treasury-authenticated calls. No function increments both.

Arithmetic

Claim ordering independence

In ExitSettlement with no shortfall, final distribution is identical regardless of claim order between beneficiary and treasury.

Arithmetic

Disjoint authority sets

Operator capabilities use BLS; treasury capabilities use ECDSA. The two authentication domains are structurally disjoint.

Structural

Unambiguous slashing attribution

Since the Foundation never possesses the operator's BLS private key, any slashable message signed by that key can only have come from the key holder.

Structural

Force-exit sufficiency

CIP-7002 provides the Foundation with sufficient authority to unilaterally initiate a validator exit without possessing the operator's signing key.

Structural

Testing: 250/250 Foundry tests pass covering settlement sequencing, rate limiting, claim mechanics, conservation invariants, reentrancy, access control, CIP-7002 exit construction, and adversarial economics. Certora formal verification passes for vault economics, access, router, and factory specs.

Custody model comparison

Why BYO-BLS over four alternative models.

ModelNo BLS custodyUnilateral exitAuth splitAttributionDB risk
BYO-BLS (Centurion)Low
Foundation generates keysHigh
Shared custodyHigh
Distributed validator (DVT)partialpartialpartialpartialMedium
Direct withdrawal credentialsLow
  • BYO-BLS (Centurion)

    Operator is sole custodian. Exit via CIP-7002 (no BLS key needed).

  • Foundation generates keys

    Both parties hold key copies. Slashing attribution is impossible.

  • Shared custody

    Formalizes the attribution problem rather than solving it.

  • Distributed validator (DVT)

    Foundation holds key shares, not the full key. Exit requires threshold cooperation.

  • Direct withdrawal credentials

    Clean key separation but sacrifices capital protection entirely.

Residual risks

Nine known risks and how each is bounded.

  • R1

    Phase-blind fund classification

    During Running phase, the vault cannot distinguish protocol rewards from arbitrary transfers. Once balance reaches 32 CTN, Running-phase claims are blocked.

  • R2

    Deployment-time EOA check

    The constructor's code-size check on the beneficiary does not prevent future code deployment via CREATE2 or EIP-7702. Mitigated by the reentrancy guard.

  • R3

    Treasury key compromise

    All vaults share one treasury address (the TreasuryRouter). Signer rotation is available via a 7-day time-locked process. Production uses HSM custody.

  • R4

    Watcher downtime window

    If watchers are offline when a validator exits, auto-settlement does not fire. Principal protection still blocks Running claims at or above 32 CTN.

  • R5

    CIP-7002 availability dependency

    Force-exit depends on the CIP-7002 system contract being deployed and functional on the target chain.

  • R6

    Claim delay front-running

    An adversary with a compromised beneficiary key could initiate and finalize in the first block after delay. Mitigated by rate limit, settlement front-run guard, and private mempool.

  • R7

    CIP-7002 dynamic fee spike

    Under congestion, CIP-7002 fees can spike. The seat manager queries the current fee and includes a safety margin.

  • R8

    Vault deployment front-running

    Vaults deploy via CREATE (unpredictable address), with post-deployment verification reading back seven on-chain properties.

  • R9

    Uncoordinated operator voluntary exit

    If the operator exits without coordination and watchers are down, principal protection still blocks Running claims at or above 32 CTN.

Multi-fault composition

How the system degrades under combined failures.

  • Operator misconduct + watcher failure

    Slashed validator's exit balance may land in a Running-phase vault without triggering auto-settlement. At or above 32 CTN, principal protection blocks Running claims.

  • Treasury key + beneficiary key compromise

    Arithmetic invariants still hold, but all funds can be drained by compromised keys acting within authorized roles. Rate limiting and the 7-day rotation delay bound exposure.

  • Deposit data manipulation + operator misconduct

    Requires two independent failures in distinct enforcement layers (application-layer validation and the allowlist gate).

  • Premature voluntary exit + watcher failure

    Exit balance lands in a Running-phase vault. At or above 32 CTN, principal protection blocks Running claims. Below, rate limit and claim delay bound extraction.

Verify independently

Program rules, review, explorer, and contacts.

Ready to operate

Run a seat under an explicit security model.

Keep your signing key. Let the Foundation handle funding, allowlisting, and vault-side settlement.

Apply Now
See the lifecycle