Solana: Alpenglow consensus explained

What Solana’s Alpenglow upgrade changes: Votor consensus, sub-second finality, and the end of on-chain vote transactions. Plus what changed for RPC integrations.

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 TowerBFT’s ~12.8s.
• Validator governance approved it (SIMD-0326) in September 2025. After running on devnet and testnet, it activated on mainnet on October 21, 2026, in epoch 1064.
• 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 are gone. They were roughly 60% of all Solana transactions, so removing them frees block space and reshapes validator economics.
• For RPC and node operators, the headline is finality: the confirmed and finalized commitment levels 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 TowerBFT’s ~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, what happened during the mainnet switch, and, most importantly for a node and RPC audience, what changes for your integration.

To test your integration, 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.

Status. Alpenglow runs on mainnet, devnet, and testnet. On mainnet, epoch 1064 started on October 21, 2026, at 13:36 UTC, and the cluster switched to Alpenglow at slot 459,653,000, about 18 minutes later. See the Solana Alpenglow upgrade page for the current status.

This first upgrade is Votor only. Rotor, and with it any change to how shreds propagate across the network, is deferred to a future, separately numbered proposal that does not exist yet. Until then, Turbine remains the data-dissemination layer and your bandwidth and relay assumptions do not change.

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.

Aspect	Before (TowerBFT + PoH)	With Alpenglow (Votor)
Finality	~12.8s, rooted	~100–150ms certificate (target)
Voting	On-chain vote transactions	Off-chain BLS votes aggregated into certificates
Timing	Proof of History	~200ms slots plus local timeouts
Block propagation	Turbine	Turbine, unchanged (Rotor is a later upgrade)
Validator vote cost	Vote transaction fees	0.8 SOL admission ticket per epoch, burned
Byzantine tolerance	~33%	20%, plus 20% crash tolerance

Votor: voting and finality, rebuilt

With TowerBFT, 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 200ms.

The ~100–150ms numbers are Anza’s targets for validators that receive votes directly. RPC nodes that are not staked learn about finalization from a later block, which can add about one block interval. Cite these as targets until they are measured on mainnet.

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 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 slot time was reduced separately from Alpenglow, from 400ms to 200ms in four stages that completed in October 2026.

Two side effects matter if you read ledger data directly. Tick entries leave the shred stream, and the Clock sysvar timestamp gets a new source: the leader now sets the timestamp for its block within a bounded range, instead of the stake-weighted median of vote timestamps. Re-check any logic tuned to the old behavior, including getBlockTime consumers.

The end of vote transactions

Because votes moved off-chain, the on-chain vote transactions that dominated Solana are gone. Before Alpenglow, roughly 60% of all Solana transactions were validator votes. Removing them frees a large share of block space for user transactions.

Vote fees are replaced by a Validator Admission Ticket (VAT): a 0.8 SOL fee charged once per epoch, deducted before a validator is admitted for the next epoch and then burned. Voting validators need to hold at least 0.8 SOL above the rent-exempt minimum in the vote account to pay it. Two caveats are worth stating plainly:

• The VAT is burned rather than redistributed, which removes the per-epoch vote-fee flow that reached 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, since 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 happened during the mainnet switch

The switch follows SIMD-0384:

1. Epoch 1064 started on October 21, 2026, at 13:36 UTC, and the feature gate activated. The cluster kept running TowerBFT for the first 5,000 slots, about 18 minutes.
2. From slot 459,653,000, blocks carried only vote transactions and nodes stopped sending commitment updates to RPC. User transactions were not included in this period.
3. Once validators with at least 82% of stake signed a genesis certificate, nodes dropped the vote-only blocks after the Alpenglow genesis block and continued under Alpenglow. Confirmed user transactions were not rolled back.

During the migration period:

• Transactions sent in this period did not land, and clients had to sign them again after the switch.
• Subscriptions at confirmed or finalized paused.
• Streams at processed showed vote-only blocks that the network then dropped. If you index across the switch, data captured at processed from those slots is not part of the chain.

To check whether a cluster runs Alpenglow, call getAgGenesisCert. It returns null on a cluster still on TowerBFT and the Alpenglow genesis certificate after the switch. On mainnet and devnet, it returns the certificate.

What Alpenglow means for RPC and node operators

This is where most teams feel Alpenglow. Even though it is an L1 consensus change, it reshapes assumptions buried in client code, streaming pipelines, and caches.

Commitment levels collapse into one

On TowerBFT, Solana’s three commitment levels meant:

• 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, confirmed and finalized are the same: both point to the latest block with a finalization certificate. The practical consequences:

• Code that defaults to confirmed to “go fast” while accepting rollback risk no longer has a meaningful trade-off to make.
• Point new code at finalized, which now arrives as fast as confirmed. confirmed keeps working and is removed in a later release.
• In getSignatureStatuses, the confirmations count comes from TowerBFT vote lockouts. Under Alpenglow, it stays at 0 until the transaction is final and then becomes null. If your code waits for a number of confirmations, check confirmationStatus instead.
• The getBlockCommitment method exposes the TowerBFT lockout structure, which Votor does not use, so its meaning changes fundamentally.

From polling to push

When finality arrives in well under a second 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, three 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 60% smaller in transaction count.
• One slot can carry more than one candidate block, and Geyser tags every event with a bank_id. Buffer data per slot and bank_id, and stop assuming one block per slot. bank_id is local to each node, so if you merge streams from more than one connection, match blocks by blockhash.
• Slot-status notifications move to a sub-second 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 60% of transaction volume, which means 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 changed shape at activation: historical data before slot 459,653,000 contains vote transactions, and data after it does not. This is relevant for anyone indexing or running historical queries across the boundary, and for anyone who reports transaction counts or TPS.

Validator operators: client version, BLS key, and VAT

A mainnet validator needs:

• v4.3.2 or later of an Agave-based client: Agave, Jito-Solana, or Harmonic Salsa. Firedancer and Frankendancer were not supported during the migration.
• A BLS public key registered on the vote account (SIMD-0387). Since the VAT feature activated on mainnet on July 22, 2026, validators without a registered BLS key are excluded from the admitted validator set.
• At least 0.8 SOL above the rent-exempt minimum in the vote account for the VAT. The first fee was charged at the start of epoch 1064 and paid for epoch 1065.

A migration checklist

1. Audit commitment assumptions

   Search your SDKs, RPC handlers, and internal services for hardcoded confirmed usage, confirmations counts, and signature-status polling loops.

2. Shift finality detection to push

   Replace polling with subscriptions, and shorten caches to sub-250ms with certificate-aware invalidation.

3. Review streaming consumers

   Update Geyser and Yellowstone gRPC consumers for the disappearance of vote transactions, for bank_id, and for the new finality cadence.

4. Test against a cluster that runs Alpenglow

   Mainnet and devnet both run Alpenglow. Use getAgGenesisCert to confirm that a cluster has switched.

Timeline

• 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.
• July 22, 2026 — the VAT feature activated on mainnet.
• September 25, 2026 — Alpenglow activated on devnet. Testnet also runs it.
• October 2026 — the slot time reduction from 400ms to 200ms completed.
• October 21, 2026 — mainnet activation. Epoch 1064 started at 13:36 UTC, and the cluster switched to Alpenglow at slot 459,653,000, about 18 minutes later.

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 take ~12.8s — on mainnet, finalized now arrives as fast as confirmed.

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.