Solana activates Alpenglow, replacing TowerBFT consensus

Solana activated Alpenglow on mainnet on Wednesday, October 21, replacing TowerBFT, the consensus protocol the network had used since its 2020 launch. The change moves validator votes off the ledger and targets finality in about 150 milliseconds, according to The Block’s report on the activation.

The Solana Foundation’s Alpenglow technical overview says the new consensus took over at slot 459,653,000 in epoch 1064. The epoch began at approximately 13:36 UTC; TowerBFT continued for a 5,000-slot transition window before Alpenglow consensus started. The Foundation says the handoff’s genesis block was slot 459,652,999, certified by votes from 446 of the network’s 654 validators.

How does Votor change Solana’s finality process?

Alpenglow’s first phase, Votor, replaces TowerBFT’s on-chain voting process. Under TowerBFT, validators submitted votes as transactions, and a block became final after enough votes accumulated over 32 slots. Under Votor, validators send votes directly to one another and aggregate them into certificates. A block can then become final after one or two rounds of voting, rather than waiting for vote transactions to accumulate on the ledger.

The roughly 150-millisecond figure is a target, not a guaranteed settlement time for every block. The Foundation compares that target with about 12.8 seconds under TowerBFT. The Block reported Anza’s account that the new process condenses the previous two-step confirmation process into one. Actual finality depends on the network reaching the required agreement; the cited sources do not establish a measured mainnet average since activation.

What changed for transactions and block data?

Alpenglow changes consensus, not transaction execution. The Solana Foundation says the SVM, transaction formats, programs and fee mechanics are unchanged, so sending transactions and running on-chain programs continue as before. Validator vote transactions, however, no longer appear in blocks. Metrics that counted those votes will therefore report fewer transactions even if user activity stays the same.

Infrastructure that reads or streams blocks does have to account for changes. The Foundation says a slot can contain more than one candidate block and that Agave 4.3 adds a bank_id field to Geyser events to identify the bank associated with each event. Consumers should buffer by slot and bank, and reconcile data from separate providers using the blockhash because bank_id is local to each node. The Foundation also says confirmed and finalized now describe the same state.

Does the activation include Rotor?

No. The mainnet activation brought Votor online; Rotor is planned for a later release and has no scheduled date on the Foundation’s overview. Rotor is intended to replace Turbine, Solana’s block-data propagation protocol, with a single relay layer. That work concerns how blocks spread through the network, while Votor changes how validators agree on them.

The distinction matters for interpreting the upgrade’s scope: the consensus handoff is complete, but Alpenglow’s planned two-phase rollout is not. Solana’s execution layer remains intact, while consensus and some downstream block-reading assumptions have changed. The 150-millisecond target describes the intended speed of finality under Votor; the Foundation’s published material does not present it as a universal guarantee.

References

• The Block’s report on the activation — theblock.co
• Alpenglow technical overview — solana.com