Solana’s Alpenglow Switch Targets 150ms Finality on October 21
Solana’s Alpenglow migration targets roughly 150ms finality by changing validator consensus, separately from the completed 200ms slot-time rollout. Image: Solana Foundation
Technology & Security

Solana’s Alpenglow Switch Targets 150ms Finality on October 21

Solana’s Alpenglow migration is scheduled for epoch 1064, targeting roughly 150ms finality while leaving ordinary wallet and staking flows unchanged.

Make us preferred on Google

Key Notes

  • Alpenglow is scheduled for epoch 1064 on October 21, targeting roughly 150ms finality.
  • The consensus handoff follows a 5,000-slot countdown and may briefly interrupt user transactions.
  • Wallet users need no token migration, while validators and data services must prepare.

Solana is preparing to activate Alpenglow on October 21, replacing the consensus system that has coordinated its validators since launch. The upgrade targets transaction finality of roughly 150 milliseconds, a major reduction from the approximately 12.8-second reference used in the Solana Foundation’s comparison.

The Foundation’s upgrade guide schedules the process for epoch 1064, estimated to begin around 13:20 UTC, or 16:20 in Moscow. That marks the start of activation, not the instant the network changes consensus.

Anza’s October 20 countdown update puts go-live at approximately 14:00 UTC and identifies slot 459,653,000 as the migration boundary. The published clock estimates differ, and epoch timing can drift; the slot-based sequence is the more precise guide to what happens.

Faster certainty, beyond faster slots

Finality is the point at which consensus treats a transaction as irreversible. Moving from 12.8 seconds to a 0.15-second target would make that process about 85 times faster. The comparison describes the design objective, not a measured guarantee for every mainnet transaction.

Alpenglow’s initial phase introduces Votor, which replaces TowerBFT voting. Instead of recording validator votes as ordinary transactions in blocks, validators exchange signed messages directly and combine them into certificates.

Anza’s protocol overview describes two voting paths operating alongside each other: a one-round route when 80% of stake responds, and a two-round route using a 60% threshold. A separate data-propagation component, Rotor, is planned for a later release.

This is distinct from Solana’s 200ms slot rollout, which shortened the interval between block-production opportunities. Faster slots and faster finality address different parts of processing a transaction; one milestone does not prove the other has occurred.

The handoff includes a brief transaction gap

The migration does not require stopping the network for the entire countdown. Anza says TowerBFT continues operating for 5,000 slots after the feature gate activates. Only at the migration boundary do blocks temporarily stop carrying user transactions and contain validator votes instead.

Validators then form a genesis certificate with 82% of stake, switch consensus to Votor and resume user transactions. Anza expects the handoff to take hundreds of milliseconds. Infrastructure provider Triton estimates a gap of roughly two slots, or about 400 milliseconds, in its migration guide. Those are expectations, rather than a guaranteed maximum interruption.

CoinScreamer’s earlier testing coverage followed Alpenglow’s community-validator phase. The upcoming mainnet transition is a separate operational milestone.

Wallet users can wait; operators need to prepare

Ordinary wallet users and people delegating SOL do not need to migrate their tokens or change how they sign transactions. The upgrade preserves the execution environment, transaction formats and user fee mechanics. Running a validator is different: operators need compatible software and must follow the migration checklist.

The Foundation currently specifies Agave-based v4.3.2 software and says Firedancer and Frankendancer are unsupported during the migration. Indexers, explorers and services consuming block streams also need to account for changes in the data they receive.

One visible consequence may be a sharp fall in headline transaction counts because validator votes will leave blocks. That accounting change should not automatically be interpreted as falling user activity. Successful activation and actual finality performance must be checked after the handoff, rather than inferred from the scheduled date.

Disclaimer: CoinScreamer is an independent media brand owned and operated by NuvexMedia LLC, publishing news, research, and market insights on digital assets and related technologies. NuvexMedia LLC invests in and collaborates with companies across the digital asset, blockchain, and technology sectors. These relationships do not influence CoinScreamer’s editorial coverage, and the publication maintains full editorial independence to provide accurate, timely, and objective information. © 2025 NuvexMedia LLC. All rights reserved. This content is for informational purposes only and should not be considered legal, tax, investment, financial, or other professional advice.

Altcoins, News, Technology & Security