The number that decides whether a blockchain can settle a card-speed payment is not throughput, it’s finality, and Solana is now testing a change that would move its own from roughly 13 seconds to 0.15 seconds. Alpenglow, the upgrade carrying that change, has moved onto Solana’s public test network, according to CoinDesk.
Finality is the point at which a transaction can no longer be reversed. Exchanges wait for it before crediting deposits, bridges wait for it before releasing funds on another chain, and a merchant needs it to know a payment will not be clawed back. At 12.8 seconds, that wait is a product constraint. At 150 milliseconds, it stops being one.
Key Takeaways
- Alpenglow has moved to Solana’s public testnet, where developers will test cutting finality from about 13 seconds to 0.15 seconds, per CoinDesk.
- The upgrade replaces Solana’s TowerBFT consensus with Votor, a protocol in which validators vote directly to each other and can settle a block in one or two rounds.
- Applications and wallets are unaffected: users do not change how they send funds.
- Participating validators need Agave 4.3, which Anza recommended to all mainnet validators on Sept. 21.
- Firedancer and Frankendancer do not yet support the Alpenglow test, so the first migration runs entirely on Agave.
Votor removes the onchain vote stack
The mechanism change is in how validators register agreement. Under TowerBFT, Solana’s current consensus system, validators write their votes onto the blockchain itself and stack enough of them across 32 slots before a block is considered final, CoinDesk reports. That accumulation is what produces the multi-second wait.
Votor, the protocol Alpenglow substitutes in, has validators send votes directly to one another instead. A block can be settled after one or two rounds of that direct voting, which removes the long chain of onchain votes entirely. The saving is structural rather than a matter of tuning: it deletes a step rather than speeding one up.
Execution is untouched. Applications keep processing transactions the way they do today, and users do not need new wallets or a different way of sending funds, per CoinDesk. That separation is why a change this deep in the stack can ship without breaking anything above it, and it is also why the risk concentrates almost entirely in the validator layer.
The first migration runs through a single client
Alpenglow has already spent more than four months on a smaller network built specifically for the upgrade, according to CoinDesk. Moving it to Solana’s established testnet is a different test: whether the broader population of computers and services already running the chain can switch over together. The testnet uses tokens with no monetary value, so developers can attempt the migration, hit problems and restart the network without putting user funds at risk.
Validators taking part need Agave 4.3. Agave is the main software used to run Solana and is maintained by Anza, one of the companies developing the network. Anza recommended 4.3 to all mainnet validators on Sept. 21, after first rolling it out to operators responsible for 10% and then 25% of the SOL securing the network, a staged release pattern that limits blast radius if a release misbehaves.
The gap worth watching is client diversity. Firedancer and Frankendancer, the two alternative validator programs built by Jump Crypto, do not yet support the Alpenglow test. Those clients exist precisely so Solana does not depend on one piece of software, so that a fault in Agave does not hit every validator simultaneously. Their absence means the first Alpenglow migration will run entirely through Agave, which makes this a test of the upgrade and a test of a single implementation at the same time.
What to Watch
Sept. 28 appears in Anza’s schedule as the tentative date for turning on features included in Agave 4.3 on the main network, CoinDesk reports. That date is not a confirmed Alpenglow launch, and the two should not be conflated: it covers the feature set bundled into 4.3, with the tentative label still attached.
Anza’s tracker still listed the testnet switch itself as pending early Wednesday, so the first checkpoint is whether the migration actually executes on testnet rather than how fast it runs afterwards. After that, the open questions are how the broader validator set handles the switch in practice, and when Firedancer and Frankendancer add Alpenglow support, because until they do, the diversity argument for running multiple clients does not apply to Solana’s newest consensus path.
