Solana is preparing to activate its largest consensus overhaul to date on mainnet-beta on October 21. The Alpenglow upgrade will retire the TowerBFT system that has governed validator agreement since the network’s launch and introduce Votor, a new voting protocol designed to bring transaction finality down to a target of roughly 150 milliseconds from the current average of about 12.8 seconds.

Activation is tied to the start of epoch 1064. Estimates place the feature-gate trigger near 14:50 UTC or 15:00 UTC, though exact timing can shift with epoch boundaries. After the gate opens, TowerBFT will continue operating for another 5,000 slots—approximately 18 minutes—before the network hands control to Alpenglow at a predetermined slot. During that brief window, blocks will carry only validator votes so they can be rolled back cleanly if needed. Validators holding at least 82 percent of stake must then certify an Alpenglow genesis certificate, after which user transactions resume under the new system.

How Votor Changes Finality

Under TowerBFT, validators record their votes as ordinary on-chain transactions. A block reaches finality only after enough successive votes accumulate across roughly 32 slots. Votor moves that communication off the chain. Validators exchange messages directly, aggregate the responses into compact certificates, and can finalize a block after one or two voting rounds.

When validators representing 80 percent or more of stake support a block in the first round, finality is immediate. Support between 60 percent and 80 percent triggers a second round that also requires a 60 percent threshold. The design is intended to tolerate up to 20 percent malicious stake and another 20 percent offline stake. Ordinary transaction execution, program logic, fees, and the Solana Virtual Machine remain unchanged.

Because vote transactions will no longer occupy block space, published transaction counts and transactions-per-second figures are expected to decline sharply even if actual user activity stays constant. The freed capacity is intended for user transactions.

Validator and Developer Requirements

Operators must run an Agave-based client version 4.3.0 or later before the feature gate activates. Alternative clients such as Firedancer and Frankendancer will not support the initial migration and will need to switch temporarily. Each vote account must hold at least 0.8 SOL above its rent-exempt minimum to cover a new fixed Validator Admission Ticket of 0.8 SOL per epoch. That fee is burned and replaces the previous practice of spending roughly 1 SOL per epoch on vote-transaction fees. Validators unable to meet the balance requirement sit out voting and block production for the following epoch.

For application developers, the “confirmed” and “finalized” commitment levels become equivalent once Alpenglow is live. Teams are advised to update new code to rely solely on the finalized commitment after activation. Existing wallets and applications require no changes; users will continue to experience the same signing and submission flows.

Two-Phase Rollout and Prior Testing

October 21 delivers only the first half of Alpenglow—Votor, the voting and finality layer. A subsequent component called Rotor, intended to replace the existing Turbine data-distribution system, remains without a scheduled release date.

The upgrade follows more than 18 months of development. Validators approved the underlying proposal in September 2025 with 98.27 percent of votes cast in favor. Alpenglow already completed successful migrations on testnet and devnet in late September. Mainnet activation is structured as a live, single-slot handoff rather than a network restart.

The Solana Foundation and Anza, the team behind the Agave client, have published detailed migration guides for operators. Epoch timing and stake participation will determine the precise moment of the switch, but the calendar target remains Wednesday, October 21.