Solana Alpenglow Mainnet Activation Set for October 21

Solana is preparing to replace the consensus system it has used since launch, with Anza confirming that Alpenglow is scheduled to activate on mainnet-beta on October 21 at approximately 14:50 UTC. The upgrade will replace TowerBFT with Votor and target transaction finality of roughly 150 milliseconds, compared with about 12.8 seconds under the current design.

According to Anza’s October 13 announcement, the transition follows around 18 months of development and will occur through a migration designed to complete within a single slot. Solana’s official upgrade documentation places the switch at the start of epoch 1064, which it estimates at approximately 15:00 UTC, effectively the same activation window. Testnet and devnet have already completed their Alpenglow migrations, giving operators production-like environments to test compatibility before mainnet.

The activation advances an upgrade that had previously carried a broader Q3 mainnet target. Since then, the network has also activated Transaction V1, expanding the maximum transaction size to 4,096 bytes. Those changes address different parts of Solana’s architecture: Transaction V1 expands transaction payload capacity, while Alpenglow changes how validators reach consensus and finalize blocks.

It’s time.

Alpenglow goes live on mainnet-beta Wednesday, October 21, ~14:50 UTC.

18 months of work for a migration that happens in one slot. Finality drops from seconds to ~150ms.

Make sure to follow us @anza_xyz as we countdown to go-live.

Details: https://t.co/MEf26uzCMW

— Anza (@anza_xyz) October 13, 2026

Votor Replaces TowerBFT and Moves Votes Offchain

Alpenglow’s central change is Votor, a new voting system that alters how validators certify blocks. Votor is designed to finalize blocks in one voting round when 80% of stake responds, or in two rounds when 60% participates, substantially shortening the time required for the network to consider a transaction irreversible.

Validator votes also move offchain as signed messages between nodes rather than appearing as ordinary vote transactions inside blocks. Removing vote transactions from blocks frees blockspace for user activity and changes how infrastructure measures validator participation, meaning indexers and analytics systems that previously counted vote transactions will need to adjust their assumptions.

The upgrade also changes Solana’s fault model, but not by simply raising a Byzantine threshold from 33% to 40%. Official documentation describes Alpenglow as capable of tolerating 20% malicious stake and another 20% offline stake at the same time. That combined operating envelope is different from claiming that 40% malicious stake can be tolerated.

For applications, the Solana Virtual Machine, transaction formats and user fee mechanics remain unchanged. The consensus migration does not require ordinary SOL holders to move funds or modify wallets, although infrastructure providers may need to account for changes in finality, commitment levels, block streaming and indexing.

Validators Must Be Ready Before Epoch 1064

Validator operators face more direct requirements. Solana says nodes participating in the migration must run Agave, Jito-Solana or Harmonic Salsa on a release built from Agave 4.3.0. Firedancer and Frankendancer are not supported during the Alpenglow migration, so operators using those clients must switch beforehand.

Validators must also have a registered BLS public key and maintain at least 0.8 SOL above the rent-exempt minimum in their vote account to cover the Validator Admission Ticket. That means Alpenglow leaves user transaction fee mechanics intact while changing the economics of validator participation, replacing the previous onchain vote-transaction cost model with the VAT mechanism.

The October 21 switch therefore marks more than a speed upgrade. If activation proceeds as scheduled, Solana will move from TowerBFT to a consensus architecture built around faster finality, offchain voting and a different validator admission model, while keeping transaction execution itself largely unchanged.