Skip to content
Solana · First Principles

Stake-Weighted Voting

The previous page, Stake and the Leader Schedule, showed how staked SOL decides who gets to write — the leader for each slot is drawn from a stake-weighted schedule. But producing a block is only half of consensus. The other half is everyone else agreeing that the block is real: that it exists, that it’s valid, and that it belongs on the one canonical chain every node must converge on. That agreement is expressed by voting.

This page is about the vote itself: what a validator actually does when it “votes for a block,” why those votes are weighted by stake instead of counted per machine, and what the magic number two-thirds means. Getting this right is a load-bearing part of the book’s throughline — a single global state machine at hardware speed only holds together if thousands of mutually-distrusting validators can cheaply agree on which blocks are final, and can’t be tricked into finalizing two conflicting ones.

A vote is a transaction

Section titled “A vote is a transaction”

Start with the surprising, concrete fact that shapes everything else on this page: on Solana a vote is a transaction. When a validator decides a leader’s block is valid, it doesn’t send a lightweight UDP “yes” packet off to the side. It builds and signs a real transaction — a vote transaction — addressed to its on-chain vote account, and lands it on the ledger like any other transaction.

That vote account is a small piece of on-chain state the validator owns. The vote transaction updates it: “as of slot N, I, this validator, have voted for the block at this slot with this bank hash.” The update is durable, public, and signed, so anyone replaying the ledger can see exactly who voted for what and when — no separate gossip channel to trust, no “take my word for it.”

   leader produces block at slot N
          │
          ▼
   each validator replays the block, checks it's valid
          │
          ▼
   validator signs a VOTE TRANSACTION for slot N  ──►  lands on the ledger
          │                                             (updates its vote account)
          ▼
   other validators read those votes off the chain and tally the stake behind slot N

Why put votes on-chain at all? Because it makes consensus auditable from the data alone, exactly like Proof of History makes ordering auditable from the data alone (see Consensus overview). There is no privileged “vote server” whose word you have to trust; the record of who voted for which fork is the ledger. Every validator can independently reconstruct the tally and reach the same conclusion, which is precisely the property a decentralized state machine needs.

But putting votes on-chain has a price, and that price becomes a design pressure we’ll return to at the end of this page.

Votes are weighted by stake, not counted per node

Section titled “Votes are weighted by stake, not counted per node”

Here is the design decision at the heart of the page. When you tally votes to decide whether a block has “enough” support, you do not count validators — you sum their staked SOL. A validator with a million SOL delegated to it and a validator with a thousand SOL each cast one vote transaction, but the first vote carries a thousand times the weight in the tally.

Why weight by stake rather than count one-node-one-vote? Because identities are forgeable and stake is not. This is the Sybil problem, and it is the reason permissionless consensus exists at all.

   one-node-one-vote:                  stake-weighted vote:


   attacker spins up 10,000 VMs        attacker must ACQUIRE the SOL to back a vote
   each is a "node" with a vote        buying/locking stake costs real money
   → majority is cheap to fake         → a majority of the vote costs a majority of the value

In a permissionless network anyone can create as many machine identities as they like — a laptop, a thousand cloud VMs, a botnet. If a vote were “one node, one vote,” an attacker could manufacture a majority for pennies by spinning up fake nodes. This is a Sybil attack: one adversary wearing thousands of masks. Counting nodes counts masks.

Stake fixes this by tying voting power to something you can’t forge: economic skin in the game. To wield a large share of the vote you must control a large share of the staked SOL, and acquiring that stake costs real money at market prices. The vote is weighted by amount-at-risk, not by number of identities — and this is a direct inheritance from Proof of Stake, which we lean on next.

Stake is what you risk — that’s why it can weight the vote

Section titled “Stake is what you risk — that’s why it can weight the vote”

Recall the core of Proof of Stake: validators (and the delegators behind them) lock SOL as a bond, and that bond can be slashed — destroyed or forfeited — if they misbehave in provable ways, such as voting for two conflicting blocks at the same slot. Stake is not just a popularity number; it is collateral the validator stands to lose.

That is exactly what makes stake the right thing to weight votes by. Weighting by stake means weighting by how much each voter has put at risk. A voter with more at stake has more to lose from attacking the chain, so giving their vote more weight aligns voting power with the incentive to keep the chain honest.

   forgeable  ─── node identities ───►  free to mint  ───►  useless as a vote weight
   costly     ─── staked SOL       ───►  bought + slashable ─►  sound as a vote weight

Contrast the two candidate weights. Node identities are forgeable and free, so they carry no commitment — weighting by them measures nothing an attacker can’t fake. Staked SOL is costly to acquire and slashable, so it carries a real commitment — weighting by it measures how much each voter would lose by betraying the chain. Sybil-resistance and incentive-alignment turn out to be the same property viewed from two angles, and stake delivers both.

The supermajority: two-thirds, not one-half

Section titled “The supermajority: two-thirds, not one-half”

Now the threshold. A block moves toward finality when validators representing a supermajority — more than two-thirds (≥ ⅔) of the total active stake — have voted for it. Not a simple majority (½), not some tunable knob: two-thirds is a specific, principled number that comes straight from Byzantine-fault-tolerant (BFT) consensus.

“Byzantine” is the technical word for arbitrarily faulty — a node that isn’t merely crashed but is actively lying: sending different messages to different peers, voting for two forks at once, doing whatever causes the most damage. A BFT system is one that stays correct even when up to some fraction of the participants (weighted by stake here) are Byzantine.

The classic result is that BFT consensus tolerates up to one-third Byzantine stake, and to do that it needs a two-thirds agreement threshold. Those two numbers — tolerate ⅓, require ⅔ — are the same fact stated from opposite ends. The reason isn’t arbitrary; it falls out of a short argument about overlap.

Why two-thirds, and not a simple majority

Section titled “Why two-thirds, and not a simple majority”

The danger consensus must rule out is two conflicting blocks — say two different blocks at the same slot, on two different forks — both being finalized. If that ever happened, the chain would have forked permanently and the “single global state machine” would have split into two. So the safety property we need is: it must be impossible for two conflicting blocks to each gather a finalizing quorum.

Suppose the quorum threshold is some fraction q of total stake, and suppose the fraction of stake that is Byzantine (willing to double-vote for both blocks) is at most f. Consider two conflicting blocks that each reach a quorum:

   total active stake = 1


   block A finalized:  voters(A)  ≥ q
   block B finalized:  voters(B)  ≥ q


   voters(A) and voters(B) can overlap by at most... the total, 1.


   overlap  ≥  voters(A) + voters(B) − total
            ≥  q + q − 1
            =  2q − 1

Any validator in that overlap voted for both A and B — it double-voted. Honest validators never double-vote (that’s what honest means, and doing it provably gets you slashed). So the entire overlap must be Byzantine, which means the overlap can be at most f:

   forced overlap  2q − 1   must be  ≤  f   (only Byzantine stake can be in it)


   pick q = 2/3 and the worst tolerable f = 1/3:


       2·(2/3) − 1  =  4/3 − 1  =  1/3   ≤  f = 1/3   ✓  (exactly saturates)

Set the threshold at two-thirds and any two quorums are forced to overlap in at least one-third of the stake — and that overlap can only be honest double-voters, which don’t exist, or Byzantine stake, which is capped at one-third. So two conflicting blocks can’t both finalize unless more than one-third of the stake is Byzantine. That’s the guarantee, and it’s why the number is ⅔.

Now see why a simple majority (½) fails. Plug q = ½ into the overlap formula:

   2·(1/2) − 1  =  0

Two majority quorums can overlap by zero stake. That means two disjoint halves of the network could each finalize a different conflicting block with no honest validator ever double-voting and nothing to slash — a clean, undetectable permanent fork. A simple majority gives you no forced overlap, so it gives you no safety against conflicting finalization. Two-thirds is the smallest threshold that forces every pair of quorums to share stake, and that forced overlap is the whole point.

   threshold q      forced overlap (2q − 1)      conflicting finalization?
   ───────────      ───────────────────────      ─────────────────────────
   1/2  (majority)  0                            possible — two disjoint halves, clean fork
   2/3  (super-)    1/3                          only if > 1/3 of stake is Byzantine

The real cost: votes eat throughput

Section titled “The real cost: votes eat throughput”

Return to the fact we started with — a vote is a transaction — and combine it with how often votes happen. Every validator votes on essentially every slot, and slots come very fast (on the order of hundreds of milliseconds each). Multiply “every validator” by “every slot” and you get an enormous, continuous stream of vote transactions flowing onto the ledger — historically a large share of all transactions Solana processed were votes, not user activity.

That is the tension this design creates, and it’s a pure expression of the book’s throughline. Votes have to be on-chain to be auditable, but on-chain votes compete for the same block space as the payments and swaps and mints users actually care about. The more validators and the faster the slots, the more of your hardware-speed pipeline gets spent on the network talking to itself about which blocks are real.

   ledger transactions
   ┌──────────────────────────────────────────────┐
   │  VOTE txs (validators confirming blocks)       │  ← historically a large fraction
   │  ────────────────────────────────────────────  │
   │  USER txs (transfers, swaps, program calls)    │  ← what users actually want
   └──────────────────────────────────────────────┘
       both compete for the same block space

This is why cheap voting matters for throughput, and why “just make every vote a heavyweight transaction and move on” was never an acceptable answer. Two pressures follow directly, and they set up the next several pages:

  • Make each vote cheap. Votes need special handling so they don’t crowd out user transactions — fee treatment and prioritization that keep the consensus chatter from eating the pipeline.
  • Make each vote say more. Rather than one flat “I vote for slot N,” Solana’s votes carry structure that lets a single vote commit the validator to a whole run of history and make earlier votes progressively harder to abandon. That structure — built on the PoH clock — is Tower BFT and its exponential lockouts, the subject of the next page.

Hold the thread: we needed votes on-chain for auditability, on-chain votes cost throughput, so the vote mechanism itself has to be engineered for cheapness and information density. The clock we built for ordering is about to pull double duty inside the vote.

The architect’s lens

Section titled “The architect’s lens”
  • Why does it exist? Producing a block doesn’t make it canonical — the network needs a way for everyone else to confirm a block and converge on one chain. Stake-weighted voting is that confirmation mechanism, and weighting by stake is what makes it Sybil-resistant in a permissionless setting.
  • What problem does it solve? Two problems at once: agreement (which blocks are real and final) and Sybil-resistance (an attacker can’t fake a majority by minting free identities, because voting power tracks costly, slashable stake rather than node count).
  • What are the trade-offs? Votes are on-chain transactions, so consensus is fully auditable from the ledger — but those votes compete with user transactions for block space, historically consuming a large share of throughput. Auditability is bought with capacity.
  • When should I avoid it? When your validator set is small and permissioned and you already trust every participant, a lighter off-chain BFT vote (or one-node-one-vote among known members) can be cheaper — Sybil-resistance is only worth its cost when identities are free to mint.
  • What breaks if I remove it? Everything downstream. Without a stake-weighted supermajority you have no principled notion of “confirmed” or “final,” fork choice has no weights to compare (see Fork Choice), and finality (see Optimistic Confirmation vs Finality) has nothing to stand on. Voting is the layer that turns “a leader wrote a block” into “the network agreed on it.”

Check your understanding

Section titled “Check your understanding”
  1. On Solana, what physically happens when a validator “votes for a block,” and why does putting that vote on-chain make consensus auditable?
  2. Votes are summed by staked SOL rather than counted one-per-validator. What attack does this prevent, and why does node-counting fail against it?
  3. Explain the two-thirds supermajority from first principles: what safety property does it guarantee, and why does a simple majority fail to provide it?
  4. How much Byzantine (arbitrarily faulty) stake can the ⅔ threshold tolerate, and what is the precise relationship between “tolerate ⅓” and “require ⅔”?
  5. Why does the fact that a vote is a transaction create a throughput problem, and what design pressure does that put on the vote mechanism (pointing ahead to the next page)?
Show answers
  1. The validator builds, signs, and lands a vote transaction that updates its on-chain vote account — “as of slot N, I voted for this block.” Because that record is durable, public, and signed, anyone replaying the ledger can reconstruct exactly who voted for which fork and tally the stake themselves; there’s no privileged vote server to trust, so consensus is auditable from the data alone.
  2. It prevents a Sybil attack — one adversary spinning up many fake node identities to manufacture a majority cheaply. One-node-one-vote counts identities, and identities are forgeable and free in a permissionless network, so counting nodes counts masks. Weighting by staked SOL ties voting power to something costly to acquire and slashable, so a majority of the vote costs a majority of the value.
  3. The safety property is that two conflicting blocks can never both finalize (no permanent fork). With threshold q, any two quorums are forced to overlap by at least 2q − 1 of the stake, and that overlap can only be double-voters — which honest validators never are. At q = ⅔ the forced overlap is ⅓, so a conflicting double-finalization would require more than ⅓ Byzantine stake. At q = ½ the forced overlap is 2·½ − 1 = 0: two disjoint halves could each finalize a different block with no honest double-vote and nothing to slash — a clean, undetectable fork. So a simple majority provides no forced overlap and no safety.
  4. It tolerates up to one-third Byzantine stake. The two numbers are the same fact from opposite ends: requiring a ⅔ quorum forces every pair of quorums to overlap in ⅓ of the stake, and since only Byzantine stake can occupy that overlap (honest validators don’t double-vote), the system stays safe exactly as long as Byzantine stake stays below ⅓.
  5. Every validator votes on essentially every slot, and slots are very fast, so vote transactions form a huge continuous stream that historically was a large fraction of all ledger transactions — and they compete for the same block space as user transactions. Votes must be on-chain for auditability but on-chain votes cost throughput, so the vote mechanism has to be engineered to be cheap and information-dense: each vote should carry more meaning per byte. That pressure leads into Tower BFT and exponential lockouts, where votes (built on the PoH clock) commit a validator to a whole run of history at once.