Solana is scheduled to activate its Alpenglow consensus upgrade on October 21, 2026, replacing the blockchain’s existing TowerBFT voting mechanism with a system designed to finalize transactions in approximately 150 milliseconds.
The upgrade begins during epoch 1064, with the decisive consensus handover scheduled for slot 459,653,000, according to Solana infrastructure developer Anza.
Alpenglow targets a reduction in finality from approximately 12.8 seconds to 150 milliseconds, an improvement of roughly 85 times. However, that figure remains a technical target rather than a verified measurement of live mainnet performance.
The transition has attracted attention because validator readiness trackers identified substantial portions of staked SOL requiring software upgrades or configuration changes shortly before activation.
The Solana Foundation’s official upgrade page now lists mainnet activation as live in epoch 1064, although independent confirmation of the completed consensus handover and its performance remains important.
Epoch 1064 Brings Major Consensus Changes
Alpenglow replaces TowerBFT with Votor, a protocol that allows validators to exchange votes directly and aggregate them into cryptographic certificates.
Under the new system, blocks can achieve finality in one voting round with 80% stake participation or two rounds with 60%. The Solana Foundation estimates epoch 1064 begins around 13:20 UTC, while Anza’s later projection places the actual consensus transition near 14:00 UTC.
The difference reflects the approximately 5,000-slot interval between the epoch boundary and the final migration point. During that interval, TowerBFT continues operating before validators coordinate the transition to Alpenglow. The upgrade also introduces a Validator Admission Ticket costing 0.8 SOL per epoch, replacing the previous system of individual on-chain vote transaction fees.
Validators must operate compatible Agave-based software, maintain registered BLS public keys and fund their vote accounts. Firedancer and Frankendancer clients are not supported during the migration, requiring affected operators to switch to compatible implementations. The change primarily affects consensus rather than transaction execution, leaving Solana’s virtual machine, transaction formats and ordinary fee mechanisms unchanged.
Validator Readiness Remains Key Risk
On October 19, validator operator Pumpkin’s Pool identified 317 validators controlling approximately 198.1 million SOL, representing 45.2% of active stake, as not fully ready. However, 109.2 million SOL of that amount belonged to validators running Agave versions 4.3.0 or 4.3.1, which Anza representatives indicated could support migration despite version 4.3.2 being recommended.
The remaining 88.9 million SOL faced more substantial issues involving incompatible clients, insufficient vote-account balances or missing configuration requirements. A subsequent October 20 snapshot identified 151 validators representing 20.3% of stake as unprepared.
The figures are not directly comparable because readiness classifications and validator configurations can change. Importantly, a readiness warning does not establish that the corresponding stake will fail to participate in consensus. The migration specification requires validators representing 82% of stake to produce a genesis certificate before Alpenglow assumes control.
Failure to satisfy that requirement immediately could delay the handover, although the feature activation itself is not necessarily cancelled. The transition also changes network statistics because validator votes will no longer appear as ordinary on-chain transactions.
Consequently, reported transaction counts could decline sharply without a corresponding reduction in user activity. For Solana, successful activation would represent its most significant consensus overhaul since launch. The immediate indicators will be confirmation of the genesis certificate, actual transaction finality under mainnet conditions and the proportion of stake successfully participating after migration.