Solana replaces TowerBFT with Alpenglow consensus

Solana activated Alpenglow on Oct. 21, replacing TowerBFT with a consensus protocol designed to make transactions final in about 150 milliseconds instead of 12.8 seconds. The change can let apps treat payments and deposits as settled sooner. The Solana Foundation’s Alpenglow upgrade page says the switch began with epoch 1064 at approximately 13:36 UTC.

The upgrade changes how validators agree on blocks, not how transactions run. The SVM, transaction formats, programs and fees are unchanged, and users can keep their existing wallets. The 150-millisecond figure is a target for finality, not a guarantee that every app will show settlement that quickly.

How does Alpenglow make a block final sooner?

Alpenglow’s Votor voting protocol moves validator votes out of on-chain transactions. Under TowerBFT, validators recorded votes on the blockchain, and a block became final after enough votes accumulated over 32 slots. With Votor, validators send votes directly to one another and aggregate them into certificates; a block can become final after one or two voting rounds.

The Block’s report on the mainnet activation says the new protocol reached mainnet at slot 459,653,000. The Foundation identifies slot 459,652,999 as the genesis block for the change, certified by votes from 446 of 654 participating validators. The handoff from TowerBFT took about 900 milliseconds, according to the Foundation.

Alpenglow’s rollout has two phases. Votor is live; Rotor, which is planned for a later release, is intended to replace Turbine’s block-data propagation with a single relay layer. That means the current finality change does not also mark Rotor’s deployment.

What changes for users and payment services?

Users do not need to change how they sign or send transactions. Apps that wait for finality before crediting a deposit or releasing goods can potentially act sooner, because the network can settle a transaction in a fraction of a second. Whether that improvement reaches a user immediately also depends on how quickly the app receives and displays finality information.

Finality is the point at which an application can treat a transaction as settled under the network’s consensus. It is distinct from slot time, the interval for block production. Solana separately reduced its slot time from 400 milliseconds to 200 milliseconds in stages; Alpenglow’s 150-millisecond target does not mean blocks are produced every 150 milliseconds.

What should developers and network watchers check?

Services that count or parse transactions in blocks need to account for votes leaving the chain. Dashboards may show fewer transactions even if user activity has not fallen, because validator votes previously appeared as transactions. The Foundation also says developers streaming block data through Geyser or gRPC must handle multiple candidate blocks per slot: Agave 4.3 adds a bank_id field, and consumers should buffer by slot and bank, then reconcile across providers using the blockhash rather than that node-local identifier.

Other data assumptions change too. Vote transactions are no longer in blocks, Proof of History no longer paces block production, and tick entries leave the shred stream. Programs reading Clock.unix_timestamp also need to account for its new source: it is no longer the stake-weighted median of validator vote timestamps. For applications that only send transactions and read account state, the Foundation says no migration is needed.

References

• Solana Foundation’s Alpenglow upgrade page — solana.com
• Block’s report on the mainnet activation — theblock.co