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. Summary Solana’s Alpenglow upgrade is moving to public testnet with a target of cutting transaction finality from roughly 13 seconds to around 150 milliseconds. Alpenglow replaces TowerBFT with Votor, allowing validators to reach agreement through one or two direct voting rounds. Agave 4.3 is required for the test, while Firedancer and Frankendancer do not yet support Alpenglow. Sept. 28 is listed for tentative Agave 4.3 feature activation on mainnet, but it is not a confirmed Alpenglow launch date. 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.
