Skip to content
Solana · First Principles

Tower BFT and Exponential Lockouts

The previous page, Stake-Weighted Voting, settled who gets a say and how much: a validator’s vote counts in proportion to the stake delegated to it, and a fork is confirmed when votes representing enough of the total stake land on it. That tells you how to count votes. It does not yet tell you what a single vote commits a validator to — or why a validator can’t cheaply vote for one fork now and a conflicting fork a moment later. That commitment rule is the whole subject of this page.

Solana’s consensus algorithm is called Tower BFT. It is a variant of Practical Byzantine Fault Tolerance (PBFT) — the classic BFT family where nodes reach agreement by voting in rounds — with one crucial adaptation: it leans on the Proof of History clock we built back in the Proof of History part, so that the expensive “agree on what time it is” messaging that ordinary PBFT needs is simply read off the shared clock instead. That single move is what makes voting on Solana cheap enough to do continuously. This page shows the mechanism: how each vote sets a lockout, why every confirming vote on top doubles the lockouts below it, and why that turns a stack of votes into a commitment that hardens toward irreversibility on its own — no separate finality round required.

Why ordinary PBFT is chatty — and what PoH removes

Section titled “Why ordinary PBFT is chatty — and what PoH removes”

Classic PBFT reaches agreement in explicit rounds of messages. Simplifying: a leader proposes a value, replicas broadcast prepare messages, gather a quorum, broadcast commit messages, gather another quorum, and only then commit. Each of those phases is a network round-trip across the whole validator set, and a big reason the phases exist at all is that the nodes have no shared notion of time or order. They must talk to establish “we are all voting on the same proposal, in the same round, at the same logical moment.” Order and timing are negotiated by messaging.

Solana already solved order-and-time in a different part of the book. Proof of History is a verifiable clock: a sequential hash chain that every validator can replay and check alone, so everyone agrees on the sequence of slots without exchanging a single “what time is it?” message (that’s the Proof of History part, and the throughput reason for it is in The Serialization Ceiling). Tower BFT plugs straight into that clock:

   Ordinary PBFT:                          Tower BFT (Solana):


   propose ──► PREPARE round (round-trip)   PoH already fixes the slot order for everyone.
           ──► COMMIT  round (round-trip)   A validator just SIGNS a vote on a slot and
           ──► commit                       broadcasts it — the clock supplies the timing
                                            the message rounds used to establish.
   time/order established BY MESSAGING       time/order established BY THE POH CLOCK

Because the clock is shared and verifiable, a Tower BFT vote does not need multiple rounds to pin down when it happened relative to everyone else’s — the PoH slot number already does that. A vote becomes a single signed statement: “I vote for the block at slot N.” The heavy machinery PBFT spent on agreeing on time collapses into “look at the clock.” This is the concrete reason PoH makes voting cheap, and it is the hinge of Solana’s consensus design.

A vote is a promise: the lockout

Section titled “A vote is a promise: the lockout”

Now the core idea. When a validator votes for a block, that vote is not just a tally mark — it is a promise not to vote for a conflicting fork for a while. The length of that “a while,” measured in slots, is the vote’s lockout.

Concretely: a fresh vote on a slot starts with a small lockout — think of it as a base of 2 slots. While the lockout is active, the validator has committed: it will not vote for any fork that would contradict this vote. If it did switch forks before the lockout expired, that is a protocol violation — the validator broke a signed promise. The penalty that actually bites is the opportunity cost the lockout imposes (the missed voting and rewards described below); protocol-level slashing of such violations has long been discussed for Solana but has not historically been enforced on-chain (see the finality discussion in Optimistic Confirmation vs Finality).

So a single vote already costs something: it temporarily ties the validator’s hands. But one vote’s lockout is small and expires quickly. The power of Tower BFT is what happens when votes stack.

The tower: every new vote doubles the lockouts below

Section titled “The tower: every new vote doubles the lockouts below”

Picture the validator’s votes as a stack — a tower. Each time the validator votes on a new slot, it pushes that vote onto the top of the tower. And here is the exponential rule:

Every time you add a confirming vote on top, the lockout of every vote already in the tower doubles.

A vote’s lockout starts at the base (2 slots) and doubles for each subsequent vote stacked above it. So the deeper a vote sits in the tower, the larger its lockout has grown:

   Vote tower (top = newest vote), base lockout = 2, doubling per vote above:


   depth  slot voted   confirmations above   lockout (slots)
   ─────  ──────────   ───────────────────   ───────────────
     1     slot 108           0                 2^1  =   2     ← newest, shallow, cheap to abandon
     2     slot 107           1                 2^2  =   4
     3     slot 106           2                 2^3  =   8
     4     slot 105           3                 2^4  =  16
     5     slot 104           4                 2^5  =  32
     …          …             …                  …
     n     slot (109-n)      n-1                2^n            ← oldest, deep, expensive to abandon

The votes near the top are shallow: they carry small lockouts and expire soon, so the validator is only lightly committed to them. But a vote that has had, say, twenty confirming votes stacked on top of it carries a lockout of 2^20 slots — over a million slots, which at Solana’s slot cadence is days. To abandon that deep vote and switch to a conflicting fork, the validator would have to sit out that entire lockout: no voting on the fork it wants, no block rewards, its stake idle, for the whole doubling window. The tower makes older commitments exponentially more expensive to walk back.

Under the hood — why doubling, and what “expiry” prunes

Section titled “Under the hood — why doubling, and what “expiry” prunes”

Why doubling specifically, rather than a flat or linear increase? Because it makes the cost of reversal scale the way confidence should. Each additional confirming vote is fresh evidence that this fork is the one the network is converging on. Doubling ties the cost of betrayal directly to the amount of accumulated evidence: after k confirmations, reversing costs 2^k slots. A few confirmations deep, reversal is trivial and a validator can still change its mind cheaply if the network is genuinely split. Many confirmations deep, reversal is astronomically expensive — which is exactly where you want switching to be nearly impossible, because deep votes represent blocks the whole network has been building on for a long time.

The tower also has a pruning rule that keeps it honest. If a vote’s lockout expires before another vote is stacked on top of it — meaning the validator stopped extending that particular line — the expired vote (and everything above it that depended on it) can be popped off the tower, freeing the validator to vote on a different fork without penalty. That is the legitimate, non-slashable way to change forks: not by breaking an active promise, but by waiting out a promise that has run its course. The design’s whole art is that shallow promises expire fast (cheap flexibility while the network is deciding) and deep promises expire slowly (near-irreversibility once it has decided).

Rollback cost is explicit, and it grows

Section titled “Rollback cost is explicit, and it grows”

Step back and notice what this buys. On most BFT chains, “how hard is it to reverse this block?” is an emergent, fuzzy property you reason about probabilistically. On Solana it is an explicit, per-vote number: the lockout is literally how many slots a validator must forgo to abandon a vote. Reversal has a price tag, and the price tag grows exponentially with depth.

   Cost, to a single validator, of switching away from a vote at depth d:


   must sit out its lockout  =  2^d slots of no voting, no rewards, idle stake


   d small  → cheap  → validator can still change forks if the network is split
   d large  → ruinous → validator will never rationally abandon this block

This is why deep votes approach practical irreversibility without a separate finality round. There is no distinct “now we finalize” phase that flips a block from tentative to permanent. Instead, permanence accrues: with every confirming vote, the lockouts underneath double, and the economic cost of unwinding the fork climbs out of reach. Finality is not an event Tower BFT triggers; it is a limit the tower converges to as votes stack. A block nobody can afford to reverse is final in every sense that matters, and it got there by ordinary continued voting rather than by a special ceremony.

That continuity is also why Tower BFT voting can run constantly in the background without drowning the network: a vote is one signed message referencing a PoH slot, not a multi-round negotiation. Validators vote every slot, the tower deepens, and commitment tightens — cheaply, because PoH already did the expensive part (agreeing on order and time).

Contrast with Ethereum’s fixed-checkpoint finality

Section titled “Contrast with Ethereum’s fixed-checkpoint finality”

It helps to see Tower BFT against a chain that finalizes differently. Ethereum’s proof-of-stake consensus (Gasper) finalizes at fixed checkpoints: time is divided into epochs, validators vote on epoch-boundary checkpoints, and a checkpoint becomes finalized once two consecutive epochs have been justified by a supermajority — roughly a two-epoch process. Finality there is a discrete event on a fixed schedule: you wait for the epoch boundaries, and then a batch of blocks flips from “not final” to “final” together.

   Ethereum (Gasper)                       Solana (Tower BFT)
   ─────────────────                       ──────────────────
   finality = discrete event at            commitment = continuous, per-validator
   fixed epoch boundaries (~2 epochs)       accrues every slot as votes stack
   blocks flip final in a batch,           each block hardens gradually as its
   on the epoch schedule                    lockouts double under new votes
   "are we past the checkpoint yet?"        "how deep is this in the tower yet?"

The distinction is when and how commitment happens. Ethereum’s model is checkpoint-based and synchronous to epochs: nothing finalizes between boundaries, but at each boundary a clean, protocol- level “finalized” flag is set. Tower BFT’s model is continuous and per-validator: there is no boundary to wait for, but there is also no single flag — each validator’s tower expresses its own strengthening commitment, and the network’s confidence in a block is the aggregate depth of that block across all validators’ towers, converging toward irreversibility as votes accumulate.

Neither is strictly “better” — they are different trade-offs on the book’s throughline of building one global state machine at hardware speed. Ethereum gets a crisp, unambiguous finality flag at the cost of waiting for epoch boundaries. Solana gets smooth, always-on commitment that never pauses for a boundary, at the cost of finality being a threshold you reason about (depth in the tower) rather than a single protocol event. Solana layers a fast, human-facing notion of “confirmed” on top of this, which is the subject of the next page: Optimistic Confirmation vs Finality.

The architect’s lens

Section titled “The architect’s lens”
  • Why does it exist? To let a stake-weighted validator set converge on one fork cheaply and continuously, by replacing PBFT’s expensive time/order-agreement rounds with reads off the shared Proof of History clock — so voting can run every slot without saturating the network.
  • What problem does it solve? How a validator can commit harder over time to a fork, and make reversal progressively more expensive, without a separate, chatty finality protocol. Each vote’s doubling lockout turns “how reversible is this block?” into an explicit, growing number.
  • What are the trade-offs? You give up a crisp, single “finalized” flag (Ethereum-style) and instead reason about depth in the tower; and the whole scheme leans on PoH being sound and the network staying live enough to keep stacking votes. Continuous commitment buys smoothness but not a boundary that rescues you if production stalls.
  • When should I avoid it? When your setting has no cheap, verifiable shared clock (no PoH), or when applications genuinely need a crisp, protocol-level “final at this exact boundary” guarantee more than they need continuous, low-latency commitment — a checkpoint model may serve them better.
  • What breaks if I remove it? Stake-weighted votes would still count, but nothing would make a vote a binding, escalating promise — validators could flip forks for free, deep blocks would never harden toward irreversibility, and the chain would need to reintroduce PBFT’s expensive rounds (or a separate finality gadget) to get commitment back.

Check your understanding

Section titled “Check your understanding”
  1. Tower BFT is described as a PBFT variant. What specific piece of ordinary PBFT does it not need to pay for, and what supplies that for free instead?
  2. What does a single vote actually promise, and what is the name and initial size of the quantity that measures that promise?
  3. State the exponential rule precisely: what happens to the lockouts already in the tower when a validator adds one more confirming vote on top? Give the lockout of a vote sitting k confirmations deep.
  4. Explain, in terms of missed slots and rewards, why a vote deep in the tower is “practically irreversible” even though there is no separate finality round.
  5. Contrast Tower BFT’s commitment with Ethereum’s finality: name one advantage each design gets from its choice (continuous-per-validator vs fixed two-epoch checkpoints).
Show answers
  1. It does not need the message rounds PBFT uses to agree on time and order (the prepare/commit round-trips whose job is partly to pin down “same proposal, same logical moment”). The Proof of History clock supplies that for free: every validator can replay and verify the slot ordering alone, so a vote becomes a single signed statement about a PoH slot rather than a multi-round negotiation. This is why PoH makes voting cheap.
  2. A vote promises not to vote for any conflicting fork for a period of time, measured in slots. That quantity is the vote’s lockout, which starts small (a base of 2 slots) and grows as more votes are stacked above it. Breaking an active lockout by switching forks is a protocol violation whose real cost is the opportunity cost the lockout imposes (missed voting and rewards).
  3. Every confirming vote added on top doubles the lockout of every vote already in the tower. A vote that has k confirmations stacked above it (i.e. sits k deep) has a lockout of 2^k slots — so deeper votes carry exponentially larger lockouts.
  4. To abandon a deep vote and move to a conflicting fork, a validator must wait out that vote’s lockout — for a vote k deep, 2^k slots during which it cannot vote on the fork it wants and earns no block rewards, leaving its stake idle. Because the lockout doubles with depth, that idle period quickly grows to days or longer, exceeding any plausible reward from switching. Reversal never becomes impossible by fiat; it becomes economically ruinous — which is what “practically irreversible” means, and it is reached by ordinary continued voting, with no separate finalization step.
  5. Tower BFT (continuous, per-validator): commitment accrues every slot with no boundary to wait for, so there’s no pause between finalization events and confirmation latency is smooth/low. Ethereum (fixed two-epoch checkpoints): finality is a crisp, unambiguous protocol-level event — a block is flagged “finalized” at a known boundary — so applications get a clean yes/no rather than having to reason about depth. Each buys one property at the other’s expense: smoothness vs a definitive flag.