CenturionValidator Program

Validator Seat Model

External operators bring keys. Foundation funds principal.

Each seat maps to one validator and one WithdrawalVault. The default public path is BYO-BLS: operators control validator signing while the Foundation validates onboarding artifacts and funds deposit principal.

What Seat Holders Get

Approved external operators receive:

Foundation-funded principal

The Foundation funds the 32 CTN validator principal after your seat is approved and onboarding data is validated.

Per-seat WithdrawalVault

A dedicated vault contract governs beneficiary claims during operation and principal-first accounting during exit settlement.

Operator-owned signing control

You generate and hold the validator BLS keypair. The Foundation does not generate, store, export, retain, or regenerate external operator private key material.

Console entry point

A stable operator access path that routes to the published console for seat status and vault operations when console access is available.

Review and Response Targets

Operational expectations before and after seat assignment.

These targets define how applications are triaged and how active-seat incidents are handled.

Intake Mode

Rolling cohort intake

Applications are reviewed continuously and seats are assigned in reliability-scored cohorts.

Initial Review Target

5 business days

Program team target to acknowledge application completeness and eligibility fit.

Technical Follow-up Target

7 business days

Program team target to complete follow-up questions, infra checks, and seat recommendation.

Critical Incident Acknowledgment

15 minutes

Target acknowledgment window for active-seat incidents that may threaten validator continuity.

Incident Update Cadence

60 minutes

Target update frequency during unresolved active-seat incidents until stability is restored.

Planned Upgrade Notice

72 hours

Target notice window for required client upgrades except emergency network-security events.

Rewards Estimator

Model your potential seat returns.

Adjust uptime to see how operator reliability shifts expected rewards. These numbers are illustrative, not guaranteed.

99.0%
90%100%
1.52 CTN / yearEst. Annual Yield
4.8%Effective APY
LowDowntime Penalty Risk

Estimates use a 4.8% base issuance rate. Actual rewards depend on protocol conditions, attestation inclusion delay, sync committee participation, and proposal luck. Not a guarantee.

Who Can Apply

Open to individuals and entities that can run reliable validator infrastructure.

No token purchase is required. You must demonstrate operational reliability and secure key management.

What Centurion Evaluates
Infrastructure reliability

Hosting provider, redundancy, monitoring setup

Key management discipline

Ability to generate and protect BLS signing material securely

Client diversity

Which execution and consensus clients you run — diversity strengthens the network

Responsiveness

Ability to respond quickly to incidents, upgrades, and exit events

Hardware or hosted infra capable of running execution + consensus + validator clients, 24/7

Technical competence to maintain uptime, apply updates, and respond to incidents

A Centurion-compatible EVM wallet for beneficiary designation and vault reward claims

Operational Responsibilities

Run a validator client 24/7 connected to at least one execution node and one consensus node.

Maintain uptime. Missed attestations reduce rewards and prolonged downtime escalates penalties.

Apply client updates when new versions are released, especially before hard forks.

Never run the same validator key on two machines simultaneously — this is a slashable offense.

Cryptographic & Onboarding Responsibilities

Generate validator BLS keypair and deposit data in your own controlled environment.

Submit validator pubkey + deposit data for your assigned seat; do not submit private key material.

Keep validator private keys and keystores under your custody for the full seat lifecycle.

Protect your beneficiary wallet because vault claims pay to that wallet identity.

Treat slashing from validator-key misuse as operator fault domain risk.

Downtime, Slashing, and Exit Outcomes

Brief downtime

Rewards can be missed and protocol penalties can accrue. Repeated or poorly handled outages increase operator risk.

Extended downtime

Prolonged unavailability can trigger inactivity leak conditions and escalate protocol penalties.

Slashing from key misuse

Protocol burns balance and may add correlated penalties. Seat status can be revoked and settlement still applies principal-first.

Voluntary exit request

Operator can request orderly exit. Once consensus-layer exit processing completes and settlement starts, the vault applies principal-first accounting.

Abandonment or non-response

Foundation can revoke the seat and initiate the validator exit-request path through treasury/vault controls when required. Actual exit timing still depends on consensus-layer processing.

Treasury-triggered exit request

Treasury-side exit control comes from vault/EIP-7002 request paths, not shared custody of external operator signing keys. That authority is unilateral for initiation, while actual exit completion still depends on consensus-layer processing. CIP-7002 uses a dynamic fee that can spike during mass-exit events — the seat manager queries the current fee and applies a safety margin.

Post-settlement drain (90-day deadline)

After 90 days in ExitSettlement, the treasury can sweep all remaining vault balance via drainRemainder, including unclaimed beneficiary rewards. This prevents funds from being permanently locked but creates a deadline — claim your rewards within 90 days of settlement finalization.

Vault Claim Mechanics

How reward claims, rate limits, and beneficiary rotation work.

The vault enforces structured claim flows with built-in safeguards for both the operator and the Foundation.

Two-Step Claim Process

Initiate a claim by calling initiateClaimRewards with the desired amount.

Wait through the configured delay (default 24 hours). During this window, the Foundation can detect anomalies and propose settlement, which cancels the pending claim.

Finalize the claim by calling finalizeClaimRewards after the delay expires. The transfer completes and the rewards counter is incremented.

Cancel at any time before finalization. Cancellation does not consume rate-limit allowance.

Per-Period Rate Limit

Each vault enforces a maximum claimable amount per 30-day period. This bounds damage from a compromised beneficiary key: even if the claim delay expires unnoticed, an attacker can extract at most the per-period cap. The rate limit is checked at initiation (early feedback) and enforced at finalization (authoritative).

Beneficiary Rotation

Need to change your reward wallet? Beneficiary rotation uses cooperative consent: the current beneficiary proposes a new address, then after a 7-day delay the treasury approves. Neither party can unilaterally change the beneficiary. Pending claims under the old beneficiary are cancelled on rotation. No vault redeployment needed.

Principal protection guard: when vault balance reaches or exceeds 32 CTN during the Running phase, beneficiary reward claims are blocked. Operator rewards are deferred until exit settlement, when principal-first accounting determines the final distribution.

Role Distinction

Public seat flow: external BYO-BLS.

This site describes the external operator model. Foundation-managed operations, if used internally, are separate and not part of the public seat flow.

External Operator Path (Default)

Operator generates and keeps validator BLS keys.

Operator submits pubkey + deposit data for validation.

Foundation validates onboarding data, then allowlists and funds deposit principal.

Treasury-side exit-request authority is vault/EIP-7002 based, not key-custody based, and actual exit timing still follows consensus-layer rules.

Any Foundation-managed operations follow separate internal processes and are not presented on this site as the default public participation path.