Solana Alpenglow Upgrade Set for October 21, Cutting Finality to 150 Milliseconds

Solana’s Alpenglow consensus upgrade is scheduled to go live on mainnet on Wednesday, October 21, 2026, cutting transaction finality from roughly 12.8 seconds to about 150 milliseconds, according to the Solana Foundation’s upgrade page. The change replaces the network’s TowerBFT voting mechanism with a new protocol called Votor and is the first major replacement of Solana’s consensus layer since TowerBFT.

SOL was trading near $104 on October 14, down roughly 3.7% over the prior 24 hours, as validators and infrastructure providers prepared for the migration. For most users the effect is simple: transactions settle almost immediately, and wallets and applications keep working as they do today.

What the Alpenglow Upgrade Changes

Today Solana validators vote by sending transactions, and a block becomes final only after enough votes have stacked up over 32 slots — a process that takes about 12.8 seconds. Alpenglow replaces that layer entirely. Under Votor, validators send votes directly to each other instead of recording them as on-chain transactions, bundle those votes into aggregate certificates, and finalize a block in one or two rounds of voting.

The result is roughly 150 milliseconds to finality, which the Solana Foundation describes as about 99% faster than TowerBFT. The upgrade is also designed to tolerate up to 20% malicious stake plus 20% offline stake. The 150 millisecond figure describes how long a transaction takes to become final, not how often blocks are produced — block time was reduced separately, from 400 to 200 milliseconds, through a staged rollout completed in October.

A Two-Phase Rollout: Votor First, Rotor Later

Alpenglow ships in two phases. Votor, the voting protocol, is the first and arrives in the Agave 4.3 validator client. Rotor, which replaces Turbine — the protocol that spreads block data across the network — with a single relay layer, is planned for a later release and is not yet scheduled.

The upgrade has already run on test and developer networks. Solana moved Alpenglow to public testnet in late September, and devnet activated the feature in epoch 1167 on September 25, 2026. Mainnet activation in epoch 1064 is expected around 15:00 UTC on October 21, behind feature gate A1pengvuM6JEcyNuTnMqepBKhwHE3N6PmUrdATGawhJS.

What Validators Must Do Before October 21

Validator operators face two hard requirements before epoch 1064 begins. First, they must run an Agave-based client — Agave, Jito-Solana, or Harmonic Salsa, on a release built on Agave 4.3.0. Firedancer and Frankendancer are not supported during the migration. Second, each validator must hold at least 0.8 SOL in its vote account, above the rent-exempt minimum, to pay the Validator Admission Ticket (VAT) fee. That fee is charged at the start of each epoch and pays for the following epoch; if it goes unpaid, the validator does not vote or produce blocks in the next epoch.

What Does Not Change — and What Infrastructure Must Update

Alpenglow does not touch transaction execution. The Solana Virtual Machine, transaction formats, programs, and fee mechanics remain unchanged, and applications that only send transactions and read account state need no migration. That block-time work is separate: Solana completed its slot-time reduction to 200 milliseconds earlier in October.

Infrastructure that consumes block, voting, or finality data does face breaking changes. Vote transactions leave blocks entirely, so any metric that counted them must be re-baselined, and reported transaction totals are expected to decline. The confirmed and finalized commitment levels converge into one. Because Proof of History no longer paces block production, tick entries leave the ledger and the Clock sysvar’s timestamp gets a new source. Geyser and gRPC consumers must also handle a new bank_id field, since a slot can now carry more than one candidate block.

Frequently Asked Questions