CenturionValidator Program

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, fund principal, and enforce seat economics through vault contracts.

Lifecycle

From application to active validator.

A simple process with clear handoffs between you, Foundation, and the network.

  1. Phase 1

    Apply

    01

    Apply

    You~10 min

    Submit your operator profile and infrastructure plan.

    Share operator background, hardware plan, and validator operations experience through the application channel.
    02

    Review & eligibility

    Foundation1–2 business days

    We review reliability, policy fit, and client diversity.

    Centurion reviews infrastructure reliability, client diversity, and policy fit before assigning a seat.
  2. Phase 2

    Set up

    03

    Generate validator keys

    YouOffline

    Create your BLS keypair locally. Private keys stay with you.

    You generate and keep the validator BLS signing keypair in your own environment. The Foundation does not receive, store, or regenerate private key material at any point.
    04

    Submit validator data

    You~5 min

    Upload your public key and deposit data for your assigned seat.

    Submit the validator public key and deposit data prepared for your seat's vault-bound withdrawal credentials. Never send the keystore file or mnemonic.
  3. Phase 3

    Validate & fund

    05

    Validate & allowlist

    FoundationOperational

    Submitted data is checked against seat policy and credentials.

    The Foundation validates deposit data against seat assignment, withdrawal credentials, and allowlist policy before permitting the deposit to proceed.
    06

    Foundation funds deposit

    FoundationTreasury-dependent

    The 32 CTN deposit is submitted for your seat.

    After validation, the Foundation submits the 32 CTN deposit transaction. The one-use allowlist entry is consumed as the deposit lands.
  4. Phase 4

    Go live

    07

    Validator goes live

    NetworkActivation queue

    Once the deposit clears and the queue completes, your validator becomes active.

    After deposit inclusion and activation-queue processing, your validator becomes active and begins attesting and proposing under your operational control.
    08

    Rewards, claims & exit

    VaultOngoing

    Rewards and exit flows are managed through WithdrawalVault.

    Rewards and exit proceeds are governed by your WithdrawalVault. Claims follow vault policy, and the treasury can initiate an exit request through the vault/EIP-7002 path when needed — consensus-layer rules still govern final exit timing.

Economic Flow

How responsibility and value move through the external model.

1

Operator Generates Keys

The external operator generates and stores the validator BLS keypair and builds deposit data locally.

2

Operator Submits Data

The operator submits validator pubkey plus deposit data for the assigned seat.

3

Foundation Validates

The Foundation enforces three strict equality checks: (a) public key matches the seat record, (b) withdrawal credentials match the vault address, and (c) deposit amount matches the principal target. The allowlist gate provides a second defense layer — incorrect withdrawal credentials would direct the deposit outside the vault, bypassing principal-first settlement entirely.

4

Foundation Funds Deposit

After validation, the Foundation funds the 32 CTN deposit transaction for that validator seat.

5

Validator Operates

After deposit inclusion, the validator becomes visible to consensus-layer activation processing, waits through the activation queue, and then becomes active under operator signing control.

6

Vault Claims and Exit

Rewards and exit proceeds are governed by the WithdrawalVault. Claims follow vault policy, and the treasury can initiate an exit request through the vault/EIP-7002 path when needed, with final exit timing still governed by consensus-layer rules.

State Machine

Program workflow, on-chain funding, and consensus outcomes are distinct stages.

Application review and onboarding validation are off-chain program states. Allowlisting and deposit funding are on-chain treasury actions. Activation is a consensus-layer result after deposit inclusion and activation-queue processing.

Applied→Eligible

Off-Chain Program Review

Trigger

Program review approves operator and seat assignment

Recorded Effect

Seat is approved for onboarding and assigned for operator submission.

Eligible→Data Submitted

Off-Chain Onboarding

Trigger

Operator provides pubkey + deposit data

Recorded Effect

Operator artifacts are recorded for review against the assigned seat.

Data Submitted→Validated

Off-Chain Validation

Trigger

Foundation verifies withdrawal credentials and deposit payload

Recorded Effect

Submission is approved for on-chain allowlisting and treasury funding.

Validated→Allowlisted

On-Chain Contract State

Trigger

Foundation enables one-use deposit permission

Recorded Effect

A one-use allowlist entry is written to the deposit contract.

Allowlisted→Deposited

On-Chain Treasury Action

Trigger

Foundation funds 32 CTN

Recorded Effect

The Foundation deposit transaction consumes the allowlist entry and makes the validator eligible for consensus-layer activation processing.

Deposited→Active

Consensus-Layer Outcome

Trigger

Activation queue completes

Recorded Effect

After consensus-layer activation processing completes, the validator reaches active duties under operator signing control.

Vault Mechanics

Three phases govern how your vault pays out.

Each vault is a standalone smart contract with two economic roles (operator beneficiary and Foundation treasury) and a three-state settlement flow with a cancellation window before settlement becomes irreversible.

Phase 0Running
→
Phase 1SettlementProposed
→
Phase 2ExitSettlement
0
Running

Validator is active under operator signing control

Normal operations. Operator signs with BLS keys; beneficiary claims rewards through the vault subject to delay and rate-limit safeguards.

1
SettlementProposed

Cancellable intermediate phase before settlement becomes irreversible

Treasury has proposed settlement. Beneficiary claims are paused. A cancellation window protects against false-positive triggers before the transition becomes permanent.

2
ExitSettlement

Irreversible principal-first payout logic

Settlement is final. Both parties make instant claims. Treasury recovers principal first; any excess goes to the beneficiary.

Auto-Settlement

How settlement triggers automatically after validator exit.

A five-gate predicate evaluated by the consensus-layer watcher determines when a validator has exited and its balance has landed in the vault.

1

Withdrawal done

The consensus layer reports the validator's withdrawal is complete.

2

Vault exists

The vault address is recorded in the seat record.

3

State readable

The vault's on-chain state can be read by the watcher.

4

Running phase

The vault is still in Running phase (prevents re-triggering on already-settled vaults).

5

Balance at target

The vault balance is at or above 32 CTN — a strong signal that the full exit balance has landed, since partial reward sweeps are much smaller.

When all five gates hold, the watcher automatically proposes settlement and, after the 1-hour delay, finalizes it. The two-phase design is crash-safe: if the watcher crashes between proposal and finalization, it retries on the next scan cycle.

Slashed validators require manual review because their exit balance may be below the principal target, weakening auto-settlement signal quality. This is acceptable because slashing events already demand Foundation intervention.

Typical Timing

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

Vault Accounting

WithdrawalVault accounting follows fixed claim and exit-settlement rules.

This site distinguishes vault-side claim and settlement mechanics from off-chain program review and treasury operations.