The operator
Sung-ho runs a two-person validator in a small Seoul data center. His setup is modest: one block-producing node, a remote voter, and a second copy of the ledger on standby. After a colleague lost a testnet node to a leaked keypair, Sung-ho decided to audit his own key hierarchy before mainnet stake arrived.
The symptom
Everything was running, but the keys were wrong. His identity keypair, used to gossip with the network and sign votes, was also the withdrawal authority on his stake account. That meant the same private key that proved his validator's identity could move his delegated SOL. The two jobs had nothing to do with each other, yet they shared one secret.
The investigation
Sung-ho opened the accounts model note and traced the difference. A vote account is owned by the vote program. A stake account is owned by the stake program. They can be linked by delegation without sharing authority. The withdrawal authority on a stake account should be an offline, hardware-backed key that never touches the validator machine. The vote account's authorized voter should be a warm key that can be rotated quickly if the node is compromised.
The fix
- Create a new stake account with a seed-phrase withdrawal authority stored on an air-gapped device.
- Delegate that stake to the existing vote account.
- Move the vote account's authorized voter to a separate keypair that lives only on the voting node.
- Remove the old keypair from any role that touches funds.
The outcome
Sung-ho's attack surface shrank dramatically. A compromised voting node could no longer drain stake; an attacker could only make the validator vote incorrectly, which would be detected quickly through commission changes and downtime. The stake remained safe behind a key that had never been online.
The lesson centers on matching key authority to the job. When a key has two unrelated powers, a failure in one becomes a breach of the other. Separating them turns a catastrophic key leak into a recoverable node incident.
Back to spotlights