Operator Documentation
Technical runbook for external validator seat operators.
Everything you need to set up, secure, monitor, and maintain a Centurion validator seat — from hardware selection through BLS key generation, onboarding submission, and ongoing operations.
Prerequisites
Hardware and infrastructure minimums.
These are the minimums for a single seat. Operators running multiple seats should scale RAM and storage accordingly.
Client Setup
Three clients. One validator.
Centurion is an EVM-compatible proof-of-stake chain that ships its own client software. Run one execution client (go-centurion or rustcen), one consensus client (rockstar or centauri), and a validator client. Prefer the minority client on each layer where possible — diversity strengthens the network.
Client Source & Builds
Centurion ships its own EL and CL client software.
Clone the repos below and build from source. Each repository's README documents the full toolchain requirements, supported platforms, and release notes. Use one EL and one CL; prefer the minority client on each layer.
Always build from a tagged release on a trusted host. Verify the commit hash matches the published release notes before putting a binary on an active validator host.
BLS Key Generation
Generate your validator keys offline.
External operators generate BLS keypairs in their own controlled environment. The Foundation does not generate, receive, store, or regenerate your validator private key material at any point.
Never run the same keystore on two machines at the same time. Double-signing is a slashable offense. The protocol burns balance and there is no recovery path. When in doubt, wait.
Onboarding Submission
What you submit, and what you never send.
After seat approval, you submit your validator pubkey and deposit data for the assigned seat. The Foundation validates those inputs before funding.
Wait for your seat assignment notification from the program team. It will include your assigned vault withdrawal credentials.
Submit your validator public key and the deposit_data-*.json file through the operator console or the onboarding contact channel.
Do not submit your BLS private key, keystore file, or mnemonic at any point during this process.
The Foundation validates your submission against the seat vault withdrawal credentials and the deposit allowlist policy.
You will be notified when validation is complete and the deposit is funded. No action is required on your part during this step.
What to submit
Validator public key data + deposit_data-*.json
What never to send
BLS private key · keystore JSON file · mnemonic phrase
Going Live
After the deposit, your validator enters the activation queue.
Deposit inclusion and consensus-layer activation queue processing are separate events. Activation timing is variable and depends on current network queue depth.
Monitoring
Alert on the things that matter.
Most validator clients expose Prometheus metrics natively. Wire them to your alerting stack and page on conditions that threaten continuity.
Troubleshooting
Common issues and how to resolve them.
Start with these checks when something looks off. They cover the most frequent operator incidents during activation and steady-state running.
Upgrade Procedure
Apply upgrades before the target epoch.
The program team targets 72-hour advance notice for non-emergency upgrades. Emergency security events may require faster turnaround. Missing an upgrade past its target epoch can cause your validator to follow a minority fork.
Watch your email and the Announcements page. The program team targets 72 hours of notice for planned upgrades; emergency security events may require faster turnaround.
Stop your validator client cleanly before upgrading any client. Do not kill -9 it unless the process is stuck.
Upgrade the execution and/or consensus client binary as directed in the upgrade notice.
Restart the clients in order: execution client first, then consensus client, then validator client.
Confirm your validator is attesting again before marking the upgrade complete. Check your monitoring dashboard or query the beacon API.
Never skip an upgrade past its target epoch. Running a client that diverges from the canonical chain after a hard fork means your validator will attest to a minority fork and face penalties.
Hardware Migration
Stop fully before starting anywhere else.
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.
Provision and fully sync the new host before touching the old host. Do not rush this step.
Stop the validator client on the old host. Confirm it has stopped — check the process list and the client logs.
Copy your keystore file from the old host to the new host using scp with SSH key authentication. Do not use cloud storage or email.
Start the validator client on the new host and confirm it is attesting before decommissioning the old host.
Running the same keystore on two machines simultaneously is a slashable offense. If you are uncertain whether the old validator is truly stopped, wait before starting the new one.
Glossary
Terms, protocols, and primitives.
Program-specific terms, cryptographic primitives, protocol mechanisms, and validator operations concepts referenced throughout this site.