Solana: Alpenglow consensus explained

TLDR:

• Alpenglow is the biggest change to Solana’s consensus since launch: it replaces TowerBFT with Votor and removes Proof of History (PoH) from consensus, targeting ~100–150ms finality instead of today’s ~12.8s.
• Validator governance approved it (SIMD-0326) in September 2025, and it now runs on a dedicated community test cluster — but it is not on public testnet or mainnet yet, with mainnet targeted for the second half of 2026.
• This first upgrade ships Votor only. Rotor, the planned Turbine replacement, is deferred to a separate later proposal, so block propagation does not change yet.
• On-chain vote transactions go away — today they are roughly 75% of all Solana transactions — which frees block space and reshapes validator economics.
• For RPC and node operators, the headline is finality: the confirmed and finalized commitment levels effectively collapse into one near-instant certificate, so audit any code that hardcodes confirmed or polls for finality.

​

Main article

Alpenglow is the most significant change to Solana’s core protocol since the network launched. It rebuilds how validators agree on the chain — the part of Solana that decides which blocks are real and when they are final. The goal is to take finality from the current ~12.8 seconds down to around 100–150 milliseconds, which is a category change rather than an incremental speedup. If you build on Solana or run infrastructure for it, Alpenglow changes assumptions you have probably baked into your code, your streaming pipelines, and your caching. This guide explains what Alpenglow is, what it changes under the hood, and — most importantly for a node and RPC audience — what you should prepare for. To experiment as builds become available, you’ll want a Chainstack Solana RPC endpoint. For the building blocks this guide assumes, see Solana: blocks vs slots explained and Solana: understanding block time.

​

What Alpenglow is

Alpenglow is a new consensus protocol designed by Anza, first presented in May 2025. The design has two parts:

• Votor — the voting and finalization engine that replaces TowerBFT.
• Rotor — a planned block-propagation layer that would eventually replace Turbine.

The governance proposal that was actually approved, SIMD-0326, covers Votor and the related economic changes. Rotor is explicitly held back for a separate proposal.

​

What changes under the hood

At a high level, here is the before-and-after. Note that several rows are deliberately unchanged — Alpenglow is a consensus upgrade, not a wholesale rewrite of the network.

​

Votor: voting and finality, rebuilt

Today, validators cast votes as on-chain transactions, and a block reaches deterministic finality only after it is rooted roughly 32 slots deep — about 12.8 seconds. Votor replaces that with direct, off-chain voting:

• Validators broadcast their votes directly to other validators as lightweight messages, not as on-chain transactions.
• Any node can aggregate those votes into a compact BLS12-381 certificate once a stake threshold is reached, and only that certificate — about 1,000 bytes — is anchored on-chain.
• Two finalization paths run concurrently. The fast path finalizes a block in a single round when at least 80% of stake participates; the slow path finalizes in two rounds when at least 60% participates in each. Whichever crosses its threshold first finalizes the block.

The result is deterministic finality in roughly 100–150ms instead of ~12.8s, with one block still produced about every 400ms.

​

Proof of History leaves consensus

Proof of History acted as a cryptographic clock that helped validators agree on time and ordering. Alpenglow removes PoH from consensus and replaces it with a fixed ~400ms block time plus local timeout timers: each validator sets per-slot deadlines and votes to skip a slot if the block does not arrive in time. The protocol is partially synchronous, so clock drift cannot break safety. The ~400ms slot time itself does not change in this upgrade — a separate proposal may reduce it later.

​

The end of vote transactions

Because votes move off-chain, the on-chain vote transactions that dominate Solana today disappear. Roughly 75% of all Solana transactions are currently validator votes, and each validator spends on the order of 1 SOL per day on vote fees. Removing them frees a large share of block space for user transactions. Vote fees are replaced by a Validator Admission Ticket (VAT): a flat 1.6 SOL per epoch, deducted before a validator is admitted for the epoch and then burned. That is about 80% of current vote costs, so per-validator economics improve — but with two caveats worth stating plainly:

• The VAT is burned rather than redistributed, which removes the per-epoch vote-fee flow that currently reaches block proposers. Some validators have flagged this as a meaningful economic change, not a pure saving.
• Lower running costs reduce the barrier to entry. Independent estimates put the minimum profitable stake dropping from roughly 4,850 SOL to roughly 450 SOL, though the exact figure depends on the SOL price.

​

The 20+20 security model

Alpenglow uses what Anza calls a 20+20 model: safety holds as long as 20% or less of stake is adversarial, and liveness holds with up to an additional 20% offline or crashed — about 40% non-responsive stake tolerated in total. This is a deliberate trade-off. It is lower than the classic 33% Byzantine threshold of two-round protocols, exchanged for single-round speed and stronger crash-fault tolerance. The design includes formal safety proofs, which TowerBFT lacked. The trade-off is real and has been debated in governance, so it is worth understanding rather than glossing over.

​

What is not changing yet: Rotor and Turbine

It is easy to read about Alpenglow and assume block propagation is changing — much of the public commentary focuses on Rotor, the proposed single-hop, erasure-coded successor to Turbine. For this upgrade, it is not. Rotor is split into its own future proposal that has no number or activation date yet, and Turbine stays in place. If you are planning around bandwidth, relays, or shred propagation, nothing changes on that front with this upgrade.

​

What Alpenglow means for RPC and node operators

This is where most teams will actually feel Alpenglow. Even though it is an L1 consensus change, it reshapes assumptions buried in client code, streaming pipelines, and caches. The work below is the difference between a smooth activation and a scramble.

​

Commitment levels collapse into one

Solana exposes three commitment levels today:

• processed — the most recent block, which may still be on a fork.
• confirmed — voted on by the cluster, available in roughly 500–600ms (optimistic).
• finalized — rooted and deterministic, available in roughly 12.8s.

Under Alpenglow, the gap between confirmed and finalized effectively disappears: both converge into a single deterministic certificate that arrives in roughly 100–150ms. The practical consequences:

• Code that defaults to confirmed to “go fast” while accepting rollback risk no longer has a meaningful trade-off to make.
• Code that polls for two commitment levels, or that treats finalized as the slow and expensive option, needs review.
• The getBlockCommitment method exposes the TowerBFT lockout structure, which Votor does not use — its meaning changes fundamentally.

See getSignatureStatuses and getBlockCommitment for the methods most affected. We will publish updated commitment-level guidance as activation approaches.

​

From polling to push

When finality arrives in under 150ms and is encoded in a single certificate, polling a signature’s status in a loop becomes wasteful and often slower than the event it is waiting for. Move finality detection to push: subscribe with signatureSubscribe rather than polling getSignatureStatuses. Watch your caches too — any cache with a TTL above ~250ms can start serving stale data once finality is near-instant, so add certificate-aware invalidation.

​

Streaming and Geyser pipelines

If you consume Geyser or Yellowstone gRPC streams, two things change:

• Vote transactions vanish from the transaction stream. Any consumer that counts, filters, or parses votes — or that sizes itself around vote volume — must adapt to a stream that is roughly 75% smaller in transaction count.
• Slot-status notifications move to a ~150ms finality cadence rather than ~12.8s. Pipelines that special-case the finalized status, for example by retroactively marking ancestor slots as finalized, should be reviewed against the new certificate-based model.

​

Archival and ledger growth

Removing vote transactions cuts roughly three-quarters of transaction volume, which means materially slower ledger growth and smaller snapshots and archives over time. Planned compute-unit and block-size increases will offset some of that, so the net effect is not yet settled. Note also that the ledger changes shape at activation: historical data before Alpenglow contains vote transactions, and data after it does not — relevant for anyone indexing or running historical queries across the boundary.

​

Validator operators: register a BLS key

If you run a validator, there is a concrete prerequisite. Before Alpenglow activates, each validator must register a BLS public key on its vote account (SIMD-0387) or the vote account behaves as unstaked. The BLS keypair is derived from the existing vote authority, and a proof-of-possession is required to prevent rogue-key attacks. This prerequisite reaches public testnet before full Alpenglow does, so it is the first concrete step to track.

​

A readiness checklist

​

Timeline and what to watch

Alpenglow is moving, but it is not on mainnet.

• September 2025 — validator governance approved SIMD-0326 with 98.27% of votes in favor (52% of stake participated).
• December 2025 — demonstrated publicly at Breakpoint.
• May 2026 — went live on the community test cluster, including the live “Alpenswitch” migration from TowerBFT.
• Second half of 2026 — mainnet target. Alpenglow ships through the Agave 4.x release line: prerequisites are landing in early 4.x release candidates, while full Votor activation is expected later in the line, so avoid pinning it to a specific minor version. Firedancer, Solana’s independent validator client, has endorsed the proposal but has not yet shipped a Votor implementation on any cluster.

The most concrete near-term gate to watch is SIMD-0387 (BLS key management) reaching public testnet — that is the signal that the prerequisites have moved from a private cluster to a public network. Every date here is a target, not a commitment.

​

Avoid these assumptions

• Assuming block propagation changes — Rotor is not in this upgrade. Turbine is unchanged, so bandwidth and relay assumptions hold for now.
• Hardcoding confirmed as the fast path — once confirmed and finalized collapse, the optimistic-versus-deterministic trade-off your code relies on goes away.
• Expecting finalized to stay ~12.8s — it will not after activation, but equally, do not assume the collapse has happened before activation.

Alpenglow is a large change, but most of the preparation for it is unglamorous and code-level: find your commitment-level assumptions, move from polling to push, and make your streaming and caching layers finality-aware before activation rather than after.