Key Hierarchy
Separate Solana validator authorities by responsibility and keep high-risk keys out of routine operations.
Solana validator operation uses several distinct signing authorities: a network identity, vote authorization, stake control, and withdrawal control. Validator operations are safer when each authority has one job and the most powerful keys are not placed on the validator host.
| Key or authority | Responsibility | Recommended location |
|---|---|---|
| Validator identity | Identifies the validator to the network and signs validator activity | Validator host or a protected signing integration, with restricted access |
| Vote-account authorized voter | Authorizes voting | Separate from the identity key where the operating model permits; protect as an active signing key |
| Vote-account withdraw authority | Controls withdrawal from the vote account | Offline or hardware-backed custody; never required for routine validator operation |
| Stake authority | Delegates, deactivates, or changes stake | Offline or hardware-backed custody; never store it on a routine validator host |
| Faucet authority | Distributes development tokens | Separate service/account with rate limits; never reuse validator identity |
Rules worth enforcing
- Do not use one keypair for identity, voting, withdrawal, and stake authority.
- Keep withdrawal and stake authority material out of containers, Pods, and standard host configuration.
- Give automation access only to keys it must use.
- Document who can rotate each authority and how recovery works before an incident.
- Audit file permissions and mounts on every validator host.
A common Kubernetes anti-pattern
Do not mount withdraw, stake, and faucet keys together in a validator or follower Pod merely because a bootstrap script can use them. A routine validator or faucet workload must not be able to read keys that belong in a stronger custody boundary.
Split Secret access by workload, mount only the authority required by that workload, and perform stake or withdrawal operations from an approval-controlled custody environment. This is both safer and easier to audit than relying on a broad validator-key Secret.
Bootstrap and follower distinction
For a private cluster, the bootstrap process needs identity, vote, stake, and faucet material to define genesis. A follower needs its own identity and any authority required for its role, plus trusted public information about the bootstrap node. Do not distribute bootstrap private material merely because a follower needs to join the cluster. In particular, do not use a bootstrap convenience script as justification to place a withdraw authority in every follower Pod.
Rotation and incident response
Document these four paths before a launch:
- Rotation of the validator identity and the service restart procedure.
- Change of authorized voter without exposing withdraw authority.
- Stake-authority recovery and delegation changes from the custody environment.
- Emergency withdrawal authority recovery, including the required approvals.
The upstream validator setup explicitly warns that the authorized withdrawer must never live on the remote validator machine. Follow that principle for every authority that can move funds or permanently change control of an account.