01
These are the minimums for a single seat. Operators running multiple seats should scale RAM and storage accordingly.Prerequisites
CPU
4+ cores; modern x86-64 or ARM64 processor.
RAM
16 GB minimum; 32 GB recommended for multi-seat setups.
Storage
500 GB NVMe SSD with high IOPS.
Network
Stable connection with at least 10 Mbps and low latency.
OS
Ubuntu 22.04 LTS or Debian 12 recommended.
Hosting
Bare metal, AWS, GCP, Hetzner, OVH, and other providers work.
02
Run one execution client, one consensus client, and a validator client. Prefer the minority client on each layer where possible.Client setup
Execution client
30303 TCP/UDP for peer discovery and block propagation.
Consensus client
9000 TCP/UDP for beacon peers and attestation gossip.
Validator client
No inbound port required; connects outbound to the local consensus client.
03
Client source & builds
go-centurion (Execution)
Go 1.23+ - https://github.com/centurion-protocol/go-centurion
rustcen (Execution)
Rust (stable) - https://github.com/centurion-protocol/rustcen
centauri (Consensus)
Rust (stable) - https://github.com/centurion-protocol/centauri
rockstar (Consensus)
Node.js + pnpm - https://github.com/centurion-protocol/rockstar
04
External operators generate BLS keypairs in their own controlled environment. Clone and build centurion-deposit-cli.BLS key generation
Work on an air-gapped machine or one that will never go online again after key generation.
Clone centurion-deposit-cli and verify the release tag before running it.
Run: centurion-deposit-cli new-mnemonic --num_validators 1 --chain centurion
Write down your mnemonic on paper. Do not store it digitally.
Submit only deposit_data-*.json during onboarding. Never send the keystore.
Move the keystore to your validator host via encrypted SSH transfer.
05
After seat approval, submit your validator pubkey and deposit data for the assigned seat. The Foundation validates those inputs before funding.Onboarding submission
Wait for your seat assignment notification, assigned vault withdrawal credentials, and your short-lived signed enrollment token.
Submit the enrollment token alongside your validator public key and deposit_data-*.json through the console or onboarding channel before the token expires.
Do not submit private key material at any point. The enrollment token is a scoped admission credential, not a key.
Foundation verifies the enrollment token and validates your submission against the seat vault credentials and allowlist policy.
You are notified when validation is complete and deposit funding has been submitted or scheduled for the assigned seat.
If your enrollment token expires before submission, request a fresh token — never re-use or share an old one.
06
After the deposit, your validator enters the activation queue. Activation timing is variable and depends on current network queue depth.Going live
Foundation funds the 32 CTN deposit transaction after final validation and approval.
Deposit included in an execution block.
Consensus client queues activation.
Validator waits through activation queue.
Validator reaches active status and begins attesting.
GET /eth/v1/beacon/states/head/validators/{pubkey}
07
Most validator clients expose Prometheus metrics natively. Wire them to your alerting stack.Monitoring
Missed attestations > 5%
Page; check validator connectivity to the consensus client.
Peer count < 10
Page; check firewall rules for ports 30303 and 9000.
Disk usage > 80%
Warn; prune chain data or add storage.
Any client process restart
Warn; check logs for recurring failure.
Validator inactive for > 2 epochs
Page; confirm validator client is running and key is loaded.
08
Troubleshooting
Validator client is not connected to the consensus client — check the beacon API endpoint in your validator client config.
Keystore is not loaded — confirm the keystore path and password are correct in your validator client.
Consensus client is still syncing — check sync status via the beacon API before expecting attestations.
09
The program targets 72-hour advance notice for non-emergency upgrades. Emergency security events may require faster turnaround.Upgrades
Watch email and Announcements. Planned upgrades target 72 hours of notice.
Stop the validator client cleanly before upgrading.
Upgrade execution and/or consensus client binaries as directed.
Restart execution first, then consensus, then validator.
Confirm the validator is attesting again before marking the upgrade complete.
Never skip an upgrade past its target epoch.
10
Migrating a validator to new hardware is safe when done in strict sequence. The only risk is running the same keystore in two places at once.Hardware migration
Provision and fully sync the new host before touching the old host.
Stop the validator client on the old host and confirm it stopped.
Copy the keystore via scp with SSH key authentication.
Start the validator client on the new host and confirm it is attesting.
Never run the same keystore on two machines simultaneously.
11
Program-specific terms, cryptographic primitives, protocol mechanisms, and validator operations concepts referenced throughout this site.Glossary
Seat
An approved validator position in Centurion. One seat maps to one validator and one WithdrawalVault once onboarding and deployment complete.
Enrollment token
Short-lived, signed admission credential scoped to one assigned seat. Authorizes a single onboarding attempt and lets the console verify operator, seat, chain, scope, and nonce before accepting validator data. It is not a BLS key, reward claim, funding guarantee, or long-lived credential — expired tokens require reissue.
Beneficiary
Wallet identity authorized to receive operator-side vault proceeds.
Treasury
Foundation-controlled address set that funds deposits and executes treasury-side settlement actions.
WithdrawalVault
Per-seat smart contract governing beneficiary claims and exit-settlement accounting.
Principal-first
Exit rule where Foundation principal settles before any operator excess is distributed.
Deposit data
Validator onboarding payload generated using centurion-deposit-cli.
BLS12-381
Signature scheme used on the consensus layer for validator duties.
ECDSA
Execution-layer signature scheme used for wallet and vault transactions.
CIP-7002
Execution-layer mechanism allowing withdrawal credentials to request validator exit without a BLS signature.
Slashing
Protocol punishment for provably malicious validator behavior.
DVT
Distributed validator technology using threshold cryptography.