On this page
A Solana validator operates with three distinct keypairs: the identity account (operator identity, signs blocks and gossip), the vote account (the on-chain account that submits votes), and the withdraw authority (the highest-privilege key, controlling commission changes, identity rotation, and vote-account withdrawals). Confusing these three is the most common error in third-party validator content, and the distinction matters for staker security evaluation because the withdraw authority is the real custody risk that on-chain data alone cannot reveal.
The three-keypair model is enforced by the Solana runtime; a validator cannot operate without all three, and they have distinct addresses on-chain.
The identity account
The identity account is the validator's primary operator keypair. It signs blocks the validator produces as leader and signs gossip messages that propagate the validator's status across the network. The identity account's pubkey is what appears in validator listings as the validator's "address" in most explorer contexts.
The identity keypair lives on the running validator node — it must be hot, because every block production and gossip message requires its signature in real time. Operators rotate this key periodically, and the runtime supports identity rotation via a transaction signed by the withdraw authority (see below).
The identity account's SOL balance funds vote transactions (until Alpenglow deploys; afterward, it funds the per-epoch VAT). Stakers do not delegate to the identity account directly — delegation is to the vote account.
The vote account
The vote account is the on-chain account that submits the validator's votes to the consensus protocol. It has a pubkey distinct from the identity account; the two are linked by the vote account's node_pubkey field, which references the identity.
Stakers delegate to the vote account, not the identity account. When a stake account is delegated, it points at a vote account pubkey, and the staking rewards flow through that vote account based on the votes it submits and the commission it sets.
The vote account's balance is consumed by per-slot vote transaction fees under the current consensus model (~1.1 SOL/day per Helius validator economics primer); the operator tops it up from the identity account's balance. Under Alpenglow, the per-slot fees are replaced by the 1.6 SOL/epoch VAT, fully burned.
The vote account's commission rate is the percentage of staking rewards the validator retains before distributing the remainder to stakers. Commission changes take effect at epoch boundaries.
The withdraw authority
The withdraw authority is the keypair authorized to perform privileged actions on the vote account. It is the highest-privilege key in the validator setup and the one stakers should evaluate most carefully — even though on-chain data does not reveal its custody discipline.
The withdraw authority can:
- Drain the vote account's SOL balance to any address.
- Change the vote account's commission, including raising it to 100% effective at the next epoch.
- Rotate the validator identity — replacing the identity keypair the vote account is bound to, including with a malicious or attacker-controlled key.
- Replace the withdraw authority itself, transferring privileged control.
An attacker with the withdraw authority can therefore strip rewards (commission to 100%), drain vote-account balance, or hand the validator to a different operator. The runtime enforces no waiting period on commission increases beyond the epoch boundary.
Why this matters for staker evaluation
On-chain data shows the vote account address, the linked identity, and the current withdraw authority pubkey. It does not show where the withdraw authority keypair is stored. A validator with the withdraw authority on a hot wallet on the same machine as the running node has a materially larger compromise surface than one with the authority on a hardware wallet stored offline in a separate location, but both validators look identical in getVoteAccounts RPC output.
This is the real custody signal stakers cannot observe directly. Indirect signals include:
- Operator transparency — does the operator publish their key-management approach (multisig, hardware wallet, separate operational and custody teams)?
- Operator track record — has the operator been operating without commission spikes or identity rotation since the vote account was created?
- Withdraw authority distinct from identity — on-chain, the withdraw authority pubkey should be a different key from the identity, indicating at least basic key separation. Identical pubkeys signal poor key hygiene.
The wiki surfaces the withdraw authority pubkey on every validator profile so stakers can verify the distinct-key check independently.
Naming traps to avoid
- "Validator address" is ambiguous — could mean the identity pubkey or the vote account pubkey. Always specify which.
- "Vote pubkey" and "vote account address" are equivalent — both refer to the vote account's on-chain address.
- "Withdrawer" is sometimes used informally for the withdraw authority; the on-chain field name is
authorized_withdrawer. Both refer to the same concept. - "Stake account" is a fourth account type, separate from these three — it belongs to the staker, not the validator, and points to a vote account via delegation.
Sources
- Solana RPC:
getVoteAccounts— vote account schema including identity and withdraw authority - Solana Cookbook: validator keys — validator key separation reference
- Anza validator operator documentation — current validator setup and key management guidance
- Solana stake program documentation — delegation to vote accounts
Account model cited: Solana runtime, epoch 971, 2026-05-15. The three-account model is protocol-level and stable; specific keys per validator update only when the operator initiates a rotation.