Skip to content
ChainBrief

News from across Web3

Solana schedules Alpenglow mainnet activation for Oct. 21

Solana schedules Alpenglow for mainnet epoch 1064 on Oct. 21, replacing TowerBFT with Votor and targeting roughly 150-millisecond transaction finality.

The ChainBrief Editors

Solana schedules Alpenglow mainnet activation for Oct. 21

With Solana’s current TowerBFT consensus taking about 12.8 seconds to finalize a transaction, the Solana Foundation’s Alpenglow upgrade page says the network is scheduled to activate Alpenglow on mainnet in epoch 1064, beginning Oct. 21 at approximately 15:00 UTC.

The change replaces the consensus mechanism that orders and finalizes transactions, with the Foundation targeting finality in roughly 150 milliseconds.

Anza, the team behind Solana’s Agave validator client, also set Oct. 21 for the mainnet-beta transition, according to Solana Compass’s report on the announcement. The Foundation describes 15:00 UTC as an estimate because epoch start times can drift with slot timing.

How will Solana switch from TowerBFT to Alpenglow?

The feature gate is scheduled to activate at the start of epoch 1064, but TowerBFT will continue running for the first 5,000 slots of that epoch, the Foundation says. That interval is about 18 minutes; Alpenglow consensus is scheduled to take over at slot 459,653,000. The Foundation says operators tracking the transition should check the cluster’s status rather than infer it from the clock.

Alpenglow’s first phase is Votor, which changes how validators vote. Instead of sending votes as onchain transactions, validators send votes directly to one another and aggregate them into certificates. The Foundation says a block can then become final after one or two rounds of voting. The Solana Virtual Machine, transactions, programs and fees remain unchanged.

What changes for validators and applications?

Validator operators must run an Agave-based client built on version 4.3.0 and keep at least 0.8 SOL above the rent-exempt minimum in their vote account, according to the Foundation. That balance pays the Validator Admission Ticket. The first fee is charged at epoch 1064’s start for participation in the following epoch; a validator that does not pay will not vote or produce blocks in that next epoch. The Foundation says Firedancer and Frankendancer are not supported during the migration.

Applications that stream or index Solana data may also need to adjust. The Foundation says slots can carry more than one candidate block, vote transactions leave blocks, and Geyser events now include a bank identifier. It also says “confirmed” and “finalized” become the same commitment level. These changes affect how systems interpret blocks and finality, even though transaction execution itself is unchanged.

What comes after the first phase?

The October activation brings Votor; Rotor is planned for a later release, the Foundation says. Rotor is intended to replace Turbine, Solana’s block-data distribution protocol, with a single relay layer, but it has not been scheduled. The mainnet date therefore marks the consensus transition, while the broader Alpenglow rollout remains in phases.

Sources