Solana Validator Switch

Solana Validator Switch (SVS) is a reference implementation for reducing downtime when moving a validator workload between prepared hosts. It is relevant when a validator needs a planned maintenance path or a tested failover procedure. It does not remove the operational and custody decisions that make a validator switch safe.

The implementation is available in proviroll/solana-validator-switch.

When to consider a switch

Use a switch workflow when a voting validator must move to a prepared standby host because of planned maintenance, host degradation, or a failure that cannot be recovered within the agreed downtime budget. It is not a replacement for backups, snapshots, capacity planning, or a normal graceful restart.

The most important distinction is between an RPC failover and a voting-validator failover. An RPC node can normally be replaced behind a traffic layer. A voting validator has a single active identity and vote path, so two hosts must never be allowed to operate as the same validator at the same time.

Preconditions

Before relying on SVS in production, define and test all of the following:

• A primary and standby host with compatible Agave versions, CPU, memory, storage performance, and network reachability.
• Clear custody of the validator identity, vote-authority, and any remote signer material. The standby must receive only the authority it needs.
• A fence that prevents the previous active validator from continuing to vote after the replacement starts.
• A documented ledger and snapshot strategy so the standby can recover within the intended time.
• Monitoring that distinguishes node reachability from vote activity, slot lag, delinquency, and leader-schedule impact.
• A rollback path that is safe if the standby does not become healthy.

Do not store the required key material in the repository, an image, or a general-purpose Ansible inventory. Provide it at run time through the approved secret-management path and keep file access limited to the validator service account.

Operational flow

1. Confirm the current validator is healthy enough to produce a reliable handoff, or declare the incident and use the failure procedure.
2. Verify the standby's client version, expected genesis hash, trusted peers, ledger state, disk headroom, and slot lag.
3. Choose a maintenance window that avoids the validator's upcoming leader slots where possible.
4. Fence and stop the active validator before enabling the replacement. Record the stop time and last observed vote/slot.
5. Start the standby and verify identity, cluster join, slot progression, vote-account state, and logs before declaring it active.
6. Watch the validator through its next expected activity period. Keep the former primary fenced until the change is accepted or explicitly rolled back.

Validation signals

Success is not a running process alone. At minimum, confirm that the replacement returns the expected genesis hash, follows the cluster without material slot lag, appears in solana validators, and resumes the expected voting behavior. Track these signals in the same dashboard and alerts used for ordinary validator operations.

For preparation and recovery details, see Snapshots and restore, Key hierarchy, and Upgrades and maintenance.

Scope

SVS is a useful implementation reference, not a universal safety guarantee. Review its current README, release state, assumptions, and license before adopting it. Test any switch design on a non-production cluster first, including a failed handoff and a rollback.