Direct answers on BYO-BLS seats and security boundaries.

No. The Foundation funds the 32 CTN seat principal after approval. You provide validator operations.

You do. External operators generate validator BLS keypairs in their own secure environment.

No, not in the external operator flow. The Foundation validates onboarding artifacts and funds deposits without taking custody of your validator private material.

Yes. The treasury/vault/EIP-7002 path can initiate the validator's exit request without custody of your validator private key. Consensus-layer eligibility rules, queueing, and protocol timing still determine when that exit completes.

Running-phase claims use a two-step process: (1) the beneficiary calls initiateClaimRewards to start a claim, (2) after a configurable delay (default 24 hours), the beneficiary calls finalizeClaimRewards to complete the transfer. The delay creates a reaction window — if the Foundation detects anomalous behavior during the delay, it can propose settlement, which automatically cancels the pending claim. The beneficiary can also cancel a pending claim at any time before finalization.

No. The Foundation funds the 32 CTN seat principal after approval. You provide validator operations.

Individuals and organizations with reliable validator operations can apply. Approved operators can run multiple seats, each with its own validator and vault.

A machine running a Centurion-compatible execution client, consensus client, and validator client. Recommended: 8+ CPU cores, 32GB RAM, 2TB NVMe SSD, stable internet. Cloud hosting (AWS, GCP, Hetzner, etc.) or dedicated hardware both work.

The public seat program uses the external BYO-BLS model. Operators keep validator signing control while the Foundation validates onboarding data, allowlists deposits, and funds principal.

You do. External operators generate validator BLS keypairs in their own secure environment.

No. You never submit validator private keys or keystore files to the Foundation.

No, not in the external operator flow. The Foundation validates onboarding artifacts and funds deposits without taking custody of your validator private material.

You submit validator public key data plus deposit data for the assigned seat. The Foundation validates those inputs against vault withdrawal credentials and allowlist policy before funding.

Downtime reduces rewards and can lead to protocol penalties. Short outages are usually less severe than prolonged unavailability, but operators remain responsible for uptime and incident response.

Extended downtime can trigger inactivity leak penalties and program action. The Foundation can revoke the seat and initiate the validator exit-request path through vault/treasury controls to wind down the seat, subject to consensus-layer processing.

Yes. The treasury/vault/EIP-7002 path can initiate the validator's exit request without custody of your validator private key. Consensus-layer eligibility rules, queueing, and protocol timing still determine when that exit completes.

Slashing from validator-key misuse is in the operator fault domain. Balance is burned by protocol rules, seat status may be revoked, and settlement still follows principal-first economics.

Validator duties are controlled by your BLS signing key. Reward claims are controlled by your vault beneficiary wallet. They are separate control planes.

Yes. Stop the validator on the old host fully before starting it on the new host. Never run the same validator key in two places at once.

Rewards and exit proceeds are governed through the WithdrawalVault model. Once validator exit has been processed and the full balance is available for settlement, the vault applies principal-first accounting: the Foundation recovers available inflows up to 32 CTN, and only any remaining excess is allocated to the beneficiary wallet.

If total recoverable inflows are below 32 CTN because of penalties or slashing, the Foundation recovers what is available and operator-side rewards can be zero.

Running-phase claims use a two-step process: (1) the beneficiary calls initiateClaimRewards to start a claim, (2) after a configurable delay (default 24 hours), the beneficiary calls finalizeClaimRewards to complete the transfer. The delay creates a reaction window — if the Foundation detects anomalous behavior during the delay, it can propose settlement, which automatically cancels the pending claim. The beneficiary can also cancel a pending claim at any time before finalization.

Each vault enforces a maximum claimable amount per 30-day period. This bounds the damage from a compromised beneficiary key independently of watcher liveness: even if the claim delay expires unnoticed, an attacker can extract at most the per-period cap rather than the entire vault balance. The rate limit is checked at both initiation (for early feedback) and finalization (the authoritative enforcement point). Setting the cap to the maximum value effectively disables rate limiting.

When the vault balance reaches or exceeds the 32 CTN principal target during the Running phase, beneficiary reward claims are blocked. The vault treats the balance as containing principal that must be preserved for treasury recovery. Operator rewards are deferred until exit settlement, when the vault applies principal-first accounting: the Foundation recovers up to 32 CTN, and any excess is allocated to the beneficiary.

Yes, through cooperative beneficiary rotation. The current beneficiary proposes a new address, and after a 7-day delay the treasury approves the rotation. Neither party can unilaterally change the beneficiary. Any pending claims under the old beneficiary are cancelled when rotation completes. This enables wallet recovery without redeploying the vault.

Settlement uses a three-state flow: Running → SettlementProposed → ExitSettlement. The treasury calls proposeSettlement to enter SettlementProposed, which pauses beneficiary claims and cancels any pending claim. After a 1-hour delay, the treasury can call finalizeSettlement to enter ExitSettlement (irreversible). During the SettlementProposed phase, the treasury can cancel and return to Running — this protects against false-positive settlement triggers before the transition becomes permanent.

After 90 days in ExitSettlement, the treasury can call drainRemainder to sweep the entire remaining vault balance to the treasury address. This includes any unclaimed beneficiary rewards. The mechanism prevents funds from being permanently locked in a vault, but it creates a deadline: beneficiaries should claim their rewards within 90 days of settlement finalization. The drain increments the treasury's principal counter, preserving the conservation invariant.

After a validator exits and its balance is swept to the vault, a watcher evaluates a five-gate predicate: (1) the consensus layer reports the validator's withdrawal is done, (2) the vault address exists, (3) vault on-chain state is readable, (4) the vault is still in Running phase, and (5) the vault balance is at or above 32 CTN. When all five conditions hold, the watcher automatically proposes settlement and, after the 1-hour delay, finalizes it. Slashed validators require manual review because their exit balance may be below the principal target.

During the first operational year, settlement timing is treasury-discretionary by policy. This means the Foundation can propose and finalize settlement based on governance decisions rather than requiring on-chain proof that a validator has exited. This intentional design allows rapid intervention against malicious operator behavior during the bootstrap period. Beneficiaries should be aware that settlement timing and principal/reward classification are governance-controlled decisions during this window.