Solana validators: identity, vote, stake, and what running one actually requires
A Solana validator is three accounts (identity, vote, stake) and a beefy server. Here's the on-chain shape, the hardware requirements, and the economics.
A Solana validator is three things stacked together:
- An identity keypair — the hot key that signs blocks and votes
- A vote account — the on-chain entity stake delegates to
- A server running Agave / Jito-Solana / Frankendancer / Firedancer
Plus a withdraw authority (typically cold-stored) and zero or more stake accounts pointed at the vote account by delegators. That's the whole on-chain footprint.
The three accounts
Identity account. A normal System-program-owned account. Holds SOL the validator uses to pay vote transaction fees (~1.1 SOL/day at the current rate). Sits on the validator machine because it needs to sign every block and vote in real time.
Vote account. Owned by the Vote program (Vote111111111111111111111111111111111111111). Stores the validator's identity pubkey, voter authority, withdraw authority, commission %, and the running vote tower. See the Vote Program reference for the full schema.
Stake accounts. Delegators' accounts, owned by the Stake program. Each one delegated to a single vote account. The validator doesn't own these — delegators do — but the validator's effective stake is the sum of all stake accounts pointed at its vote account.
What a validator actually does
Continuously, every slot (~400ms):
Ingest transactions → receive via TPU (Transaction Processing Unit)
ports over QUIC, signed by users
Validate + execute → decode, check signatures, run instructions,
apply state changes against the bank
Produce blocks → when leader: assemble valid txs into the next
slot's block, broadcast via Turbine
Vote → sign a TowerSync transaction every slot it
accepts, paying ~5000 lamports per vote (free
ingress path, no priority fee competition)
Forward → when not leader: forward received txs to the
upcoming leader's TPUThe validator earns:
- Inflation rewards — protocol-issued SOL per epoch, distributed proportional to vote credits
- Priority fees — half goes to the leader, the rest is burned (currently; SIMD-0123 era adjustments)
- Jito tips — if running Jito-Solana, the MEV bundle tips collected during leader slots
After commission, the rest of these flow to delegators via the Stake program's rewards distribution at each epoch boundary.
Hardware requirements
Solana's validator requirements are unforgiving. The minimum spec keeps creeping up as the network scales.
Component Practical 2026 minimum
─────────────────────────────────────────────────
CPU 16+ physical cores @ 3+ GHz
(AMD EPYC 7443P, Intel Xeon Gold)
RAM 256 GB DDR4 ECC (512 GB recommended)
Disk (accounts) 2 TB NVMe SSD (Samsung 980 Pro / Micron 7450 / Intel D7-P5520)
Disk (ledger) 2 TB NVMe SSD (separate physical drive)
Network 1 Gbps symmetric, low-latency peering
(a colo near a major Solana exchange/RPC peering point)
Cost $400-1000/month for a leased server hitting these specs
or $15-30k upfront for owned hardware in coloDisk IO matters most. The accounts DB is a write-heavy workload — slow SSDs cause validator delinquency. Consumer-grade NVMe burns out within months.
The economics
Vote tx cost: ~1.1 SOL/day (~33 SOL/month) paid from identity
balance, irrespective of stake
Inflation reward share: proportional to (commission_adjusted_credits / total_credits)
Credits earned per successful vote on a slot
Priority fee share: 50% to leader, 50% burned (current schedule)
Only earned during the validator's leader slots
Jito MEV share: ~95% of received tips distributed pro-rata to stake
(varies; Jito Labs takes a cut, validator keeps a share)
Break-even stake: roughly 50,000 SOL delegated at 5% commission to
cover vote costs + server costs from rewards.
Below that, you're subsidizing the network.Most validators below the break-even line either run for ideological reasons (decentralisation, ecosystem contribution), on Foundation Delegation Program subsidies, or as part of a broader RPC/MEV business where the validator role complements other revenue.
The client software
Five validator clients exist in 2026, three in production. See the Firedancer & validator client landscape article for the full comparison. Practical 2026 default: Jito-Solana for the MEV revenue, with a planned migration to full Firedancer once your ops team is comfortable.
Setup, abbreviated
# Install Agave (or Jito-Solana / Frankendancer / Firedancer)
sh -c "$(curl -sSfL https://release.anza.xyz/stable/install)"
# Generate identity, vote, and withdrawer keys
solana-keygen new --outfile ~/identity.json
solana-keygen new --outfile ~/vote.json
solana-keygen new --outfile ~/withdrawer.json
# Create the on-chain vote account
solana create-vote-account \
~/vote.json ~/identity.json ~/withdrawer.json \
--commission 5
# Start the validator (the actual command is much longer in production)
agave-validator \
--identity ~/identity.json \
--vote-account ~/vote.json \
--rpc-port 8899 \
--dynamic-port-range 8000-8020 \
--entrypoint mainnet-beta.solana.com:8001 \
--known-validator <known-id-1> --known-validator <known-id-2> \
--only-known-rpc \
--ledger /mnt/ledger \
--accounts /mnt/accounts \
--log /var/log/agave.logWhat can go wrong (and frequently does)
- Delinquency. Validator stops voting for any reason → drops out of the leader schedule, no rewards, stake flows away to other validators.
- Disk failure. Hot NVMe burns out. Always run with redundant drives or a hot-swap rebuild plan.
- Network partition. Validator's view of the chain diverges from the majority → ends up voting on the wrong fork, loses credits.
- Software upgrade lag. Stuck on an outdated client during a network upgrade → forks off, stops voting. Validator ops teams maintain an upgrade-ready monitoring posture.