Consensus In Depth
Solana consensus is the process that turns a stream of leader-produced blocks into a single history your clients can trust at different depths of certainty.
//
Search across all documentation pages
Solana consensus is the process that turns a stream of leader-produced blocks into a single history your clients can trust at different depths of certainty.
Builders rarely implement BFT algorithms, but they choose commitment levels, interpret forks, and ship UX that must survive rare reorgs and evolving validator software.
This page is the umbrella for that builder view: TowerBFT and Proof of History (PoH) historically, vote accounts and confirmation levels on RPC, and Alpenglow (Votor + Rotor) as the upgrade path - without treating roadmap pieces as fully live protocol facts.
processed, confirmed, and finalized, while validators produce and vote on blocks ordered in slots.Consensus answers a practical question: which sequence of slots is the chain your application should treat as real?
A slot is a unit of leader time in which a scheduled validator may produce a block.
Leaders rotate by schedule; transactions are forwarded toward upcoming leaders and ordered into blocks that other validators receive and execute.
Forks appear when the network temporarily has more than one candidate history - after partitions, leader failures, or competing blocks.
Consensus does not mean every node always sees the same tip instantly; it means stake-weighted rules eventually select one history and make abandoning it progressively more expensive.
Historically, mainnet consensus behavior that builders learned in the Agave era is described as TowerBFT working with Proof of History.
PoH is a verifiable delay / ordering construct: a cryptographic clock that helps validators agree on event order without waiting for every peer to gossip wall-clock timestamps.
PoH is not consensus by itself; it is the ordering spine that makes high-throughput leader scheduling and replay efficient.
TowerBFT is the vote-based BFT layer: validators cast votes on forks, accumulate lockouts, and prefer the heaviest stake-weighted tower that respects those lockouts.
As votes stack on a fork, that fork becomes harder to switch away from - the builder-facing story behind deeper confirmation.
Vote accounts record a validator's voting identity and recent vote state.
Delegated stake weights votes; clients observe aggregate vote progress as commitment, not as a separate API programs call mid-instruction.
Programs still execute inside Sealevel against listed accounts; consensus decides which blocks of executed results are durable on the ledger you are reading.
Commitment is the client-facing compression of all of the above into three common RPC levels:
| Commitment | Builder meaning (TowerBFT-era intuition) | Risk posture |
|---|---|---|
processed | Seen / executed on a node at the current tip; little vote weight yet | Optimistic only |
confirmed | Supermajority of stake has voted for a block containing the tx (optimistic confirmation class) | Default for many UX actions |
finalized | Block is rooted / locked out deeply enough to treat as practically irreversible under normal conditions | Settlements, bridges, irreversible side effects |
Exact thresholds and timings can shift with software and cluster conditions; the product meaning of the ladder stays: optimistic, strongly voted, rooted.
Alpenglow is Solana's consensus redesign path - not a separate L2 and not a new account model.
Design and SIMD work associate two named pieces: Votor (voting / finality) and Rotor (block propagation), aimed at much lower time-to-finality (commonly discussed in the ~100-150 ms class under good conditions).
Treat Alpenglow as evolving infrastructure: track feature activation, test clusters, and Agave release notes rather than assuming every design claim is already universal mainnet behavior on every RPC you hit today.
End-to-end, a user transaction rides consensus as follows.
Client builds + signs tx --> RPC accepts submission
|
v
Forwarded toward upcoming leader(s)
|
v
Leader orders txs into a block for a slot
(historically aided by PoH ordering)
|
v
Block propagates to other validators
(historically Turbine; Rotor is the Alpenglow-direction propagator)
|
v
Validators execute / replay and cast votes
(historically TowerBFT vote towers + lockouts;
Votor is the Alpenglow-direction voting/finality design)
|
v
Commitment deepens for that slot's txs:
processed -> confirmed -> finalized
|
v
Client polls getSignatureStatuses / subscribes
until the chosen commitment is reachedLeader production creates candidate history; without votes, a processed tip can still lose a fork race.
Propagation determines how fast the rest of the stake can even see a block to vote on it; slow or lossy propagation stretches confirmation tails and raises orphan risk under stress.
Voting is stake-weighted: a supermajority vote turns "my RPC saw it" into "the cluster is committing stake to this fork."
In the TowerBFT framing, repeated votes increase lockouts that punish casual fork switching, so finality is earned over successive slots rather than declared by a single wall-clock timer in your app.
Vote accounts matter more for operators and stake markets than for ordinary dapp instruction authors, but they explain vote credits, delinquents, and stake concentration on explorers.
Unhealthy vote accounts or delinquent stake change confirmation quality (how much real stake is voting), not the commitment enum name in @solana/kit.
Client confirmation is where builders make the irreversible product decision.
Waiting only until sendTransaction returns a signature proves almost nothing about durability; the signature is a handle for status polling.
Typical policy patterns:
processed): show "submitted" or speculative state; keep an easy rollback path if the signature never confirms.confirmed): balances, mints, most in-app updates where a rare fork is acceptable if you reconcile.finalized): offramps, bridge mints/burns, custodial releases, anything you cannot un-send off-chain.Alpenglow's design intent is to compress time between those rungs - especially strong finality - by redesigning vote rounds (Votor) and how blocks fan out (Rotor).
What should not change in your wiring: accounts, program ownership, transaction atomicity, and commitment matched to risk.
What may change operationally: median and tail latencies for confirmed / finalized, vote traffic patterns, and which validator features are active on a given cluster version.
During rollout windows, pin Agave/RPC versions in runbooks and re-measure confirmation latency instead of hard-coding timeouts from old posts.
Commitment is not a vanity setting; it is a risk control.
| Level | Latency (qualitative) | Reorg exposure | Good for | Poor for |
|---|---|---|---|---|
processed | Lowest | Highest among the three | Prefetch, optimistic spinners, non-critical reads | Payouts, inventory deduction, legal settlement |
confirmed | Medium | Low but non-zero in edge cases | Most dapp "success" UX, game state, retail swaps | High-value irrevocable off-chain actions without reconciliation |
finalized | Highest (historically multi-slot rooted depth) | Lowest under normal safety assumptions | Bridges, withdrawals, compliance exports, multi-system handoff | Ultra-low-latency games that can reconcile later |
As Alpenglow components activate and mature, re-benchmark wall-clock waits for finalized; do not drop the commitment parameter because marketing said "sub-second finality."
Keep current mainnet reasoning separate from the upgrade path.
| Aspect | TowerBFT + PoH (historical / long-standing builder model) | Alpenglow direction (Votor + Rotor) |
|---|---|---|
| Ordering spine | PoH-assisted slot/block ordering | Redesign modernizes consensus around fast finality (do not assume PoH vanishes from all tooling overnight) |
| Voting / finality | Tower votes, lockouts, root over successive slots | Votor: streamlined voting/finality rounds targeting ~100-150 ms class finality under good conditions |
| Propagation | Turbine-style shred propagation | Rotor: redesigned propagation for faster, more efficient block delivery |
| Client RPC enums | processed / confirmed / finalized | Same product ladder expected; timings may change |
| App account model | Unchanged | Unchanged |
| Program CU metering | Independent of consensus algorithm | Still independent |
| Builder action | Choose commitment; handle expired blockhashes; retry | Same, plus re-measure timeouts per cluster/version |
Your transaction still names accounts, pays fees, and executes atomically.
Anchor 0.32.1 constraints, PDA seeds, and CPI rules do not become newly "consensus-aware" just because finality gets faster.
@solana/kit 7.0.0 still speaks commitment on RPC reads and signature status; migrate latency assumptions, not the whole application architecture, when consensus software advances.
Validators care about vote readiness, stake health, and feature gates; RPC providers care how quickly nodes observe supermajority and root.
For critical settlement infrastructure, follow cluster status, Agave notes, and SIMD activation - not only social announcements.
Local tools (Surfpool, LiteSVM) are strong for program logic and weak for finality SLOs; measure finality on real cluster RPC.
Encode commitment per action class in one policy module rather than scattering magic strings.
Log signature, commitment reached, slot, and wall time so you can detect regression after upgrades.
Treat "confirmed on RPC A, missing on RPC B" as fork or indexing lag, not user fraud, until finalized (or your policy equivalent) agrees.
confirmed and finalized are interchangeable if the UI is fast enough." They encode different reorg risk; speed of UX does not erase the difference for bridges and withdrawals.Stake-weighted agreement on which fork of leader-produced slots is canonical, exposed to apps mainly as commitment levels on RPC.
PoH provides a verifiable ordering/time structure for slots and entries; TowerBFT gathers stake-weighted votes and lockouts so the network converges on one fork and roots it over time.
An on-chain account tied to a validator's voting identity and vote state; delegated stake weights that validator's votes in consensus.
Lockouts are why finality deepens over successive votes: switching forks becomes costly, which underpins why finalized is safer than processed for irreversible actions.
processed is early node-local execution visibility; confirmed reflects supermajority vote progress; finalized reflects rooted / deeply locked history suitable for irreversible effects.
Many product actions use confirmed for responsive UX; use finalized before irreversible external effects; treat processed as optimistic only.
The consensus upgrade path designed to modernize voting and propagation for much faster finality, discussed as Votor (voting/finality) plus Rotor (propagation), without replacing the accounts/transaction programming model.
Do not assume universal mainnet completion from design blogs alone; treat components as staged and version-gated, and verify against current cluster release notes, feature status, and your RPC provider's Agave version (this page pins Agave 4.1.1 as the reference stack).
Votor is the Alpenglow-direction voting and finality protocol piece: fewer, faster vote rounds aimed at strong finality on the order of ~100-150 ms under good network conditions.
Rotor is the Alpenglow-direction block propagation design intended to deliver blocks to the validator set faster and more efficiently than the prior propagation stack alone.
You still select commitment on RPC methods and signature status; re-tune timeouts and UX copy as measured finality improves, rather than inventing a new settlement API.
No for ordinary business logic - Anchor 0.32.1 programs still validate accounts and execute instructions; commitment is a client/indexer concern, not a new on-chain pragma inside every instruction.
Rare fork edge cases are why irreversible off-chain actions should wait for finalized (or an equivalent policy you explicitly accept); always re-check status before payouts.
Unit-test program logic locally; integration-test commitment polling against devnet or mainnet RPC with the same commitment policy you ship, and re-run after validator upgrades.
Start with Consensus Basics for orientation, then TowerBFT + PoH, Vote Accounts & Voting, Introducing Alpenglow, Votor, and Confirmation Levels in Clients.
Stack versions: This page was written for Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1, and @solana/kit 7.0.0.
Reviewed by Chris St. John·Last updated Jul 15, 2026