Solana Activates Alpenglow, Targeting 150ms Finality

Solana validators activated Alpenglow on mainnet-beta on Oct. 21, replacing TowerBFT with a consensus protocol designed to make transactions final in about 150 milliseconds. Anza said the handoff took place at slot 459,653,000; the Anza announcement describes the change as a reduction from roughly 12.8 seconds. The shorter interval matters to exchanges and payment services that wait for finality before treating a transfer as irreversible.

How does Alpenglow reach finality faster?

Its first phase, Votor, replaces TowerBFT’s vote transactions with direct validator-to-validator votes aggregated into certificates. TowerBFT accumulated votes across 32 slots; Votor can finalize a block after one or two voting rounds. The Solana Foundation’s technical account says the fast path finalizes after at least 80% of stake votes to notarize a block in the first round. If that threshold is missed, a second round uses certificates with 60% stake thresholds to finalize, notarize or skip the block.

That distinction makes the 150-millisecond figure a target, not a fixed time guarantee. Solana’s documentation says observed time depends on stake distribution, network latency and topology; a block may take the second round, and a geographically concentrated 60% of stake can complete two rounds before a widely distributed 80% completes one. Votor is designed to tolerate up to 20% adversarial stake alongside 20% offline stake while still reaching consensus. If votes cannot form the required certificates, the protocol can skip a candidate block rather than finalize it.

What changed at the mainnet handoff?

The feature gate began with epoch 1064, but TowerBFT continued for the first 5,000 slots of that epoch. Alpenglow consensus took over at slot 459,653,000, according to Solana’s rollout documentation. This separates the scheduled activation from the actual consensus switch. Anza said validators carried the existing ledger through the migration while maintaining network availability.

Transaction execution did not change: the Solana Virtual Machine, programs and fees continue to work as before. The change is in how validators agree on blocks and confirm that they cannot be reversed. Under Alpenglow, “confirmed” and “finalized” converge; the Foundation says applications can use the stronger finalized commitment without TowerBFT’s former wait for finality.

Which operators and data feeds are affected?

Validators had to run an Agave-based client for the migration. Solana’s documentation lists Agave, Jito-Solana and Harmonic Salsa; Firedancer and Frankendancer were unsupported during the handoff. Votes no longer appear as transactions in blocks, so transaction counts and TPS reported by block parsers will fall as vote traffic disappears. The Foundation characterizes this as an accounting change, not a drop in user activity. Validator participation data now comes from certificates in the block footer rather than Vote-program instructions.

Validator economics also change: vote transactions no longer incur their former fees, while the Validator Admission Ticket charges each voting validator 0.8 SOL per epoch from its vote account. The first charge funds participation in the following epoch. Alpenglow’s second phase, Rotor, is planned to replace Turbine’s block-propagation path, but Solana says it is not yet scheduled. The mainnet activation therefore delivers the new voting and finality mechanism; it does not complete every planned Alpenglow component.

Sources and documents

• Anza announcement — prnewswire.com
• Solana Foundation’s technical account — solana.com