Solana Could Go From 12.8 Seconds to 150ms Finality as Alpenglow Enters Testing

By Hassan Shittu

Key highlights:

  • Solana’s Alpenglow upgrade has entered public testnet, targeting a reduction in finality from 12.8 seconds to 150ms
  • End-user experience stays the same, but validators, indexers, and infrastructure providers must update as vote transactions are removed from blocks and slot/block identifiers are separated
  • Anza recommended Agave 4.3 for mainnet validator adoption on Sept. 21, but Alpenglow’s mainnet activation date remains pending

Solana is moving closer to a major change to its consensus system as the Alpenglow upgrade enters public testnet testing, with developers targeting a reduction in finality from about 12.8 seconds to roughly 150 milliseconds.

Designed by Anza, a Solana-focused development firm responsible for the Agave validator client, Alpenglow would replace key parts of the network’s existing consensus mechanism to allow validators to reach finality much faster.

The upgrade has already undergone months of testing on a smaller community validator cluster and will now be tested across a broader environment involving more validators, infrastructure providers, and developers.

The public testnet phase is intended to identify performance, compatibility, and security issues before Alpenglow can be considered for activation on Solana’s mainnet.

How can Alpenglow make Solana’s transaction finality almost instantly

Finality refers to the point at which a blockchain considers a transaction or block irreversible under its consensus rules. 

Faster finality can be particularly important for exchanges, payment providers, and bridges that require stronger confirmation before treating transactions as settled.

Solana currently relies on TowerBFT, where validators record votes as on-chain transactions. A block becomes finalized after enough accumulated votes are reached across 32 slots.

With Solana’s slots running at about 400 milliseconds, this produces a finality target of roughly 12.8 seconds.

Alpenglow takes a different approach by replacing TowerBFT’s voting mechanism in two major phases.

The first introduces Votor, which changes how validators participate in voting and how finality certificates are generated.

Rather than relying on Solana’s existing consensus process, Votor is designed to provide a faster mechanism for validators to reach agreement on finalized blocks.

The protocol can finalize a block through one or two voting rounds; as in the faster path, at least 80% of the network’s stake must notarize a block in the first round. 

If that threshold is not reached, a second round can finalize the block with a 60% stake threshold.

The second phase is Rotor, which is planned to replace Solana’s existing turbine block propagation system.

While Votor focuses primarily on consensus and finality, Rotor addresses how blocks and transaction data move across the validator network.

Anza and the Solana Foundation expect the new system to bring median finality down to about 150 milliseconds

That figure remains a testing target rather than a guarantee for every transaction under all network conditions.

Solana’s Alpenglow is not changing transactions, so what is changing?

For most Solana users, Alpenglow is not expected to change how applications execute transactions. The Solana Virtual Machine, transaction formats, programs, and fee mechanics will remain unchanged.

The major changes will instead affect validators, indexers, and infrastructure providers that process Solana’s underlying data.

One important change is that applications will no longer be able to treat a slot and block as interchangeable.

Agave 4.3, the validator software introducing Alpenglow protocol changes, adds a bank_id field to help data consumers identify which candidate block an event belongs to.

Systems using Geyser and similar data streaming tools will therefore need to update how they process and track network events.

Alpenglow will also remove vote transactions from blocks, while Proof of History ticks will no longer play the same role in pacing block production.

Infrastructure providers that rely on either data source will need to adjust their indexing systems, monitoring tools, and network metrics.

Anza recommended Agave 4.3 for general mainnet validator adoption on September 21 after staged rollouts to validators representing 10% and 25% of Solana’s stake.

However, this does not mean Alpenglow is already scheduled for mainnet activation.

Anza’s feature gate tracker still lists the upgrade as pending, while the September 28 date in the Agave 4.3 schedule refers only to a tentative resumption of mainnet feature activations.

For users, the intended result is largely invisible: applications continue using the same transaction and execution framework, while the underlying validator infrastructure changes to support much faster finality.

Source:: Solana Could Go From 12.8 Seconds to 150ms Finality as Alpenglow Enters Testing