Solana Alpenglow testnet: What does the 150ms finality upgrade change?

Solana has moved its Alpenglow consensus upgrade toward public testnet deployment as developers prepare to test a design intended to cut transaction finality from roughly 13 seconds to around 150 milliseconds.

According to github, the testnet stage will let developers test the migration across Solana’s established testing environment before the consensus system can be considered for the main network.

Finality refers to the point when a transaction becomes irreversible under the network’s consensus rules. Exchanges typically wait for finality before crediting deposits, while blockchain bridges use it before releasing assets on another network.

Solana currently relies on TowerBFT for consensus, with validators recording votes onchain and accumulating enough votes across 32 slots before a block reaches finality. Alpenglow replaces that process with a protocol called Votor, which lets validators exchange votes directly.

Under the new design, validators can reach agreement after one or two voting rounds. The change removes the longer sequence of onchain consensus votes required under TowerBFT while leaving transaction execution largely unchanged for applications and users.

Solana Alpenglow moves into public testnet

Alpenglow has already spent more than four months operating on a smaller community cluster created specifically to test the consensus system. Moving the upgrade into Solana’s established public testnet exposes it to a larger group of validators, infrastructure providers and services already connected to the network.

The public testnet uses tokens without monetary value, allowing developers to restart the network, test migration procedures and investigate problems without putting mainnet funds at risk.

Anza first moved Alpenglow into community validator testing in May, describing the upgrade as the largest consensus change in Solana’s history. As crypto.news previously reported, the community cluster allowed validator operators to test the new consensus design before deployment across Solana’s existing test infrastructure.

Votor is designed to reach finality through one of two voting paths depending on validator participation. Earlier specifications indicated that a block could settle after one round when enough stake participates, while a second round provides another route to finality under lower participation.

The expected result is a sharp reduction from Solana’s existing finality time. Anza has estimated median finality at around 150 milliseconds, with earlier simulations putting it as low as 100 milliseconds under favorable conditions.

Developers have not changed how applications execute transactions as part of the upgrade. Wallet users will continue sending transactions through the same interfaces, while the main changes take place in how validators communicate and agree on the permanent state of the blockchain.

Agave 4.3 carries the Alpenglow code

Validators participating in the Alpenglow test need to run Agave 4.3, the latest branch of the main validator software maintained by Anza.

Anza recommended Agave 4.3 for general adoption among mainnet validators on Sept. 21. The rollout had previously moved through controlled stages, first asking operators responsible for 10% of mainnet stake to upgrade before expanding the recommendation to 25%.

Alpenglow development has been tied to Agave releases for months. In August, the 150 millisecond finality target was expected to arrive through Agave 4.3 after the underlying Alpenglow code had already been included for testing in the previous software branch.

The Sept. 28 date listed in Anza’s Agave 4.3 schedule refers to the tentative resumption of mainnet feature activation. Anza states that its release dates are subject to change, while its feature gate tracker still listed the Alpenglow testnet activation as pending early Wednesday.

Sept. 28 therefore does not represent a confirmed date for Alpenglow to begin operating on Solana mainnet.

The distinction comes as several Solana performance upgrades have been moving through separate activation schedules. Transaction finality, slot production and transaction capacity are controlled by different network changes even though each can affect how quickly applications interact with Solana.

Solana has already reduced slot times to 250ms

Solana recently cut its target slot time from 300 milliseconds to 250 milliseconds under SIMD-0525, bringing the network to a target of four slots per second.

The 250 millisecond slot upgrade reduced each validator’s four slot leader window from 1.2 seconds to one second. Network processing limits were adjusted alongside the shorter slots, meaning the change did not raise overall processing capacity by the same proportion.

A final stage under SIMD-0525 targets 200 millisecond slots, which would bring the network to five targeted slots per second. Developers have not set a confirmed mainnet activation date for that stage.

Slot time and finality measure different parts of the network. Slot time determines how frequently Solana can produce new slots, while Alpenglow changes how validators reach agreement that a block is irreversible.

Solana began the current sequence of slot reductions in August, when its target fell to 350 milliseconds from the 400 millisecond setting used since the network launched. SIMD-0525 laid out successive targets of 350, 300, 250 and eventually 200 milliseconds.

Alpenglow follows a separate path through SIMD-0326 and replaces TowerBFT with Votor instead of modifying the duration of individual slots.

Firedancer remains outside the first Alpenglow test

Firedancer and Frankendancer, validator clients developed by Jump Crypto, do not currently support the Alpenglow test, leaving the initial migration dependent on Agave.

Client diversity gives Solana validators different software implementations for participating in the same network. If separate clients are available, a software fault affecting one implementation does not necessarily affect every validator.

Firedancer began producing mainnet blocks earlier this year after years of development by Jump Crypto. The team initially recommended a gradual rollout while security audits continued, with the independently built client intended to reduce reliance on Solana’s existing validator implementations.

Frankendancer serves as a hybrid implementation that combines components from Firedancer with existing Solana software. Neither implementation is listed as supporting the pending SIMD-0326 Alpenglow feature on Anza’s current feature gate tracker.

Agave 4.3 is therefore the supported client for the first public testnet migration. Anza’s tracker lists Alpenglow as a pending testnet activation under SIMD-0326, while support fields for Firedancer and Frankendancer remain marked as unavailable.