Skip to content

What is a Validator?

Docs-site note (2026-06-25): This is a general, neutral primer on what a Solana validator does; it describes canonical Solana protocol behavior, with a short "where Vexor fits" note at the end.

A validator is a computer running validator software that participates in the Solana network. Collectively, validators are the network: they receive transactions, execute them, agree on the result, take turns producing new blocks, and serve the data back out to applications and users. There is no separate "server" — the validators run the chain.

This page explains what a validator does and the handful of concepts you need before reading the rest of these docs. It is deliberately generic Solana education; nothing here is Vexor-specific until the closing section.

The validator's job

A Solana validator has a few distinct responsibilities, running continuously and in parallel:

Responsibility What it means
Ingest Receive incoming transactions and the block fragments ("shreds") that other validators broadcast.
Replay Re-execute every block's transactions to compute the resulting account state — independently, not on trust.
Maintain state Keep the full set of accounts (balances, programs, program data) up to date and in memory/on disk.
Reach consensus Vote on which chain of blocks is canonical, so the whole network agrees on one history.
Produce blocks When it is this validator's turn (it is the leader), package transactions into new blocks and broadcast them.
Serve data Answer queries (over RPC) about blocks, transactions, and account state for wallets, explorers, and apps.

The deep idea is independent verification. A validator never trusts another node's claim about what a block did — it re-executes the block itself and checks that it arrives at the same answer. Consensus is what happens when thousands of validators independently reach the same answer and vote for it.

Key concepts

Slots, blocks, and shreds

Time on Solana is divided into slots — fixed ~400-millisecond windows, each assigned to one leader. In each slot, the leader may produce one block (a batch of transactions plus the proof-of-history record that orders them). Slots are numbered sequentially and only ever go up.

A block is too big to send as one packet, so the leader splits it into shreds — small (~1.2 KB) network packets. Shreds are the unit that actually travels across the network; receiving validators collect the shreds for a slot and reassemble the block. Erasure coding adds redundant "coding" shreds so a block can be reconstructed even if some data shreds are lost in transit.

The bank hash — a fingerprint of state

After a validator replays a block, it computes a bank hash: a single hash that fingerprints the complete state of the chain at that slot. It folds together the parent slot's hash, the proof-of-history result, a count of the signatures processed, and a hash of all the accounts.

The bank hash is the heart of consensus. If two validators replay the same block and get the same bank hash, they agree exactly — down to the byte — on what that block did. If their bank hashes differ, they have diverged, and one of them computed something wrong. A correct validator's bank hash must match the rest of the network at every single slot.

Voting and consensus (TowerBFT)

Validators express agreement by voting for slots they have replayed and accept as canonical. Solana's fork-choice and finality rules are known as TowerBFT: each vote commits the validator to a slot for a period of time (a "lockout") that doubles with each consecutive vote, making it progressively more costly to abandon a chain it has voted for. Votes are themselves transactions, weighted by the validator's stake (the amount of SOL delegated to it).

Because the leader's block can arrive late or a network can briefly split, validators sometimes see competing forks — alternative chains from the same parent. Fork choice picks the fork with the most accumulated stake-weighted votes; once enough stake has voted and locked in, a slot becomes rooted (finalized) and will never be reverted.

Leader rotation

Validators take turns producing blocks. A leader schedule, computed in advance for each ~2-day epoch, assigns each upcoming slot to a validator, with higher-stake validators getting proportionally more slots. When a validator's slot comes up it becomes the leader, produces a block, and broadcasts it; the rest of the time it is replaying and voting on other leaders' blocks. If a leader fails to produce (or its block doesn't propagate), that slot is skipped.

Snapshots

The full account state is large and grows over time. Rather than replay the entire history from genesis, a new validator boots from a snapshot — a compressed copy of the account state at a recent slot, downloaded from peers. The validator verifies the snapshot, loads the accounts, and then catches up by replaying only the slots since that snapshot. Validators periodically produce both full snapshots and smaller incremental snapshots.

Gossip, Turbine, and Repair

Validators have to find each other and move data efficiently. Three protocols do most of this work:

  • Gossip — a peer-to-peer protocol where validators continuously share small signed messages about who is on the network, their addresses, and their latest votes. It is how nodes discover the cluster and learn each other's state.
  • Turbine — Solana's block-propagation protocol. Instead of the leader sending the whole block to everyone, shreds are relayed through a stake-weighted tree, so each node forwards to a few others. This is what lets a block reach thousands of validators quickly.
  • Repair — when a validator is missing shreds (it joined late, or packets were dropped), it asks peers for the specific missing pieces and fills the gaps.

How it all fits together

A validator runs as a pipeline. Shreds arrive (via Turbine, with Repair filling gaps), get reassembled into blocks, and are replayed to update account state and compute each slot's bank hash. The validator votes on the slots it accepts, following TowerBFT's fork-choice and lockout rules, while gossip keeps it in sync with the rest of the cluster. When the leader schedule says it is this node's turn, the validator produces a block and broadcasts it. Throughout, it can serve RPC so applications can read the chain. New nodes bootstrap from a snapshot and catch up from there.

Every honest validator runs this same loop and — for the network to stay healthy — must reach the same bank hash at every slot. That single requirement, byte-for-byte agreement, is the bar every validator implementation is held to.

Where Vexor fits

Vexor is a validator in exactly the sense described above: it ingests shreds, replays blocks, maintains account state, votes via TowerBFT, produces blocks when it is leader, and serves RPC. What makes it notable is how it is built — it is an independent, clean-room implementation written in Zig that reproduces the canonical bank hash byte-for-byte, rather than a fork of the reference client.

To go deeper: