Skip to content
Validator seat model

External operators bring keys. Foundation funds principal.

Each approved seat maps to one validator and one WithdrawalVault. The default public path is BYO-BLS: operators control validator signing while the Foundation validates the enrollment token, validator pubkey, and deposit data before funding the seat principal.
What seat holders get

Approved external operators receive

Foundation-funded principal
The Foundation funds the 32 CTN validator principal only after your seat is approved, an enrollment token is issued, and onboarding data is validated.
Per-seat WithdrawalVault
A dedicated vault contract governs running-phase protections, claim execution policy, and settlement accounting for the deployed seat version.
Operator-owned signing control
You generate and hold the validator BLS keypair. The Foundation does not receive external operator private key material.
Console entry point
A stable operator access path routes to the published console for seat status and vault operations when 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: Target: ~5 business days
Program team target to acknowledge application completeness and eligibility fit. Not a guaranteed turnaround.
Technical follow-up target: Target: ~7 business days
Program team target to complete follow-up questions, infra checks, and seat recommendation. Not a guaranteed turnaround.
Critical incident acknowledgment: Target: ~15 minutes
Target acknowledgment window for active-seat incidents that may threaten validator continuity. Best-effort; not a contractual SLA.
Incident update cadence: Target: ~60 minutes
Target update frequency during unresolved active-seat incidents until stability is restored. Best-effort; not a contractual SLA.
Planned upgrade notice: Target: ~72 hours
Target notice window for required client upgrades except emergency network-security events.
Rewards estimator

Illustrate reward sensitivity, not guaranteed returns.

Adjust uptime to see how operator reliability shifts expected rewards. These numbers are illustrative, not guaranteed.
Uptime99.0%
90%100%
1.52 CTN / yearEst. annual yield
4.8%Effective APY
Low
Downtime penalty risk
Estimates use a configurable 4.8% illustrative base issuance rate. Actual rewards depend on protocol conditions, attestation inclusion delay, sync committee participation, proposal luck, penalties, and seat-specific program rules. Not a guarantee or offer.
Who can apply

Open to individuals and entities that can run reliable validator infrastructure

No principal purchase is required. You must demonstrate operational reliability and secure key management.
Infrastructure reliability
Hosting provider, redundancy, and 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, and validator clients 24/7.
Technical competence to maintain uptime, apply updates, and respond to incidents.
A Centurion-compatible EVM wallet for beneficiary designation and reward payouts.
Operator responsibilities

What each seat holder commits to maintaining

Operational

Infrastructure

Run a validator client 24/7 connected to execution and consensus nodes.
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.
Keys & onboarding

Custody

Generate validator BLS keypair and deposit data in your own environment.
Submit validator pubkey plus deposit data for your assigned seat.
Keep validator private keys and keystores under your custody for the full lifecycle.
Protect your beneficiary wallet because reward payouts are directed to that wallet identity.
Downtime, slashing, exit outcomes

What happens when things go wrong

Brief downtime
Rewards can be missed and protocol penalties can accrue.
Extended downtime
Prolonged unavailability can trigger inactivity leak conditions and escalate protocol penalties.
Slashing from key misuse
Protocol burns balance. Seat status can be revoked and settlement still applies principal-first.
Voluntary exit request
Operator can request orderly exit. Once exit processing completes, the vault applies principal-first accounting.
Treasury-triggered exit request
Treasury-side exit control comes from vault/CIP-7002 request paths where enabled, not shared custody of signing keys.
Post-settlement drain
After 90 days in ExitSettlement, treasury can sweep remaining vault balance, including unclaimed beneficiary rewards.
Vault claim mechanics

How reward claims and rate limits work

The vault enforces structured claim flows with built-in safeguards for both the operator and the Foundation.
1
Submit a claim request in the staker console.
2
Wait through the configured delay window.
3
Submit claim again after the ready time to finalize payout.
4
Track operation status, timestamps, and transaction hashes from Claim Activity.
Per-period rate limit
Each vault enforces a maximum claimable amount per 30-day period.
Fixed beneficiary
The beneficiary address is set at seat initialization. On-chain rotation is not supported in the current contract; post-deployment changes are governance-coordinated through the Foundation.
Principal protection guard
Running-phase claims remain enabled only while protection checks are passing.
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.
Operator generates and keeps validator BLS keys.
Operator submits pubkey plus deposit data for validation.
Foundation validates onboarding data, then allowlists and funds deposit principal.
Treasury-side exit-request authority is vault/CIP-7002 based where enabled by the deployed seat version, not key-custody based.
Ready to apply

Bring your infrastructure plan and keep your signing key.

The program team reviews operator reliability, client diversity, and key-management discipline before assigning seats.