Solana schedules Alpenglow for Oct. 21, targeting 150ms finality

Solana has scheduled its Alpenglow upgrade for Oct. 21, setting a date for a new validator voting system that targets transaction finality in about 150 milliseconds. The change replaces TowerBFT, which Solana has used since launch, and moves validator votes out of the blockchain’s transaction record. CoinDesk’s report on the schedule says the finality figure is a target; actual results will depend on network conditions.

That distinction matters because a payment can appear successful before it is final. Alpenglow aims to shorten the wait for the stronger assurance that a transaction cannot be reversed, a difference relevant to merchants accepting payments and bridges releasing funds on another blockchain.

How does Alpenglow change Solana’s route to finality?

Alpenglow replaces TowerBFT’s on-chain voting transactions with direct validator messages, which are combined into a certificate. Under the Votor protocol, a block can finalize after one voting round if 80% of stake responds, or two rounds if 60% responds; the first route to completion wins. Solana Foundation figures cited by Solana Compass’s account of Anza’s announcement and upgrade documentation put current finality at about 12.8 seconds and Alpenglow’s target at roughly 150 milliseconds.

The comparison is with finality, not the time it takes a transaction to first appear successful. That early signal can already arrive quickly on Solana, but it does not provide the same assurance of irreversibility. Alpenglow’s proposed gain is a shorter gap between a transaction being observed and being settled; the target does not mean every transaction will finalize in 150 milliseconds under every condition.

What will change for validators and transaction counts?

The scheduled migration is tied to epoch 1064, expected to begin around 15:00 UTC on Oct. 21. CoinDesk reports that Solana will keep the old system running for the first 5,000 slots before switching, a handoff expected to take roughly 18 minutes. Validators need software built on Agave 4.3.0; operators using Firedancer or Frankendancer will have to switch clients temporarily because those alternatives are not supported for the initial migration.

Taking validator votes out of blocks will also lower the network’s reported transaction count, even if user activity stays steady. The old count includes votes as transactions, so a drop after activation would partly reflect a change in what gets recorded, not necessarily fewer payments or trades. Validator charges change too: roughly 1 SOL per epoch in vote fees will be replaced by a flat 0.8 SOL admission fee.

What should users watch after the date?

The main test is whether the live network reaches finality near the target while handling actual stake responses. The upgrade’s voting thresholds make performance dependent on how much stake responds and how quickly; a target measured in testing is not a guarantee of the same result under all network conditions. Operators’ client readiness and the migration itself are also immediate signals, since the network must move from its established consensus system to the new one.

After activation, dashboards will need to distinguish user transactions from validator activity when comparing counts across the change. Developers and data services that read block data should also track the new format, while wallet users and most applications are expected to continue working as before. The next useful evidence will be the measured finality after the switch, alongside confirmation that the migration completed and the network remained available.

Source material

• CoinDesk’s report on the schedule — coindesk.com
• Solana Compass’s account of Anza’s announcement and upgrade documentation — solanacompass.com