Solana’s Alpenglow upgrade has reached its public developer network, letting application teams test a system designed to cut transaction finality from about 12.8 seconds to roughly 150 milliseconds.
Summary
- Alpenglow is active on Solana’s devnet and testnet, while mainnet still uses the current consensus system.
- The upgrade replaces onchain validator vote transactions with direct votes that can finalize a block in one or two rounds.
- Applications that only send transactions and read balances need no migration, but block-data services must update their systems.
- Anza has announced no firm date for Alpenglow’s mainnet activation.
According to the Solana Foundation’s upgrade page, Alpenglow is now active on devnet and testnet but has not been activated on mainnet. Anza, which develops Solana’s core validator software, announced the devnet switch on Sept. 25, one day after testnet completed its transition.
The two networks serve different parts of the rollout. Application teams can use devnet to check how their software behaves with tokens that have no real value, while testnet gives validators and infrastructure operators a place to test the network software under more demanding conditions.
For developers, the new devnet stage means they can check applications against Alpenglow without waiting for the system to reach the blockchain that handles users’ funds. Solana’s mainnet continues to use TowerBFT, so the 150-millisecond figure remains a target for the planned upgrade rather than a finality time available to users today.
Solana’s Alpenglow changes how validators finalize blocks
Under TowerBFT, validators submit votes as transactions that appear inside blocks. Enough votes must accumulate across 32 slots before a block becomes final, which currently takes about 12.8 seconds, according to the Foundation.
Alpenglow’s first phase, called Votor, has validators send votes directly to one another instead. The Foundation says a block can reach finality after one voting round if validators representing at least 80% of stake vote to accept it. A second round provides another path when the first does not meet that threshold.
Finality is the point at which the network has agreed on a transaction strongly enough that it can no longer be reversed under its consensus rules. A faster result could matter to a U.S. exchange deciding when to credit a Solana deposit or to a payment provider deciding when to treat a merchant’s sale as complete. Each service may still apply its own checks before releasing funds or confirming a payment to a customer.
The Foundation separates finality from the time it takes to produce a block. In September, Solana reduced its target slot time from 300 milliseconds to 250 milliseconds, with a further reduction to 200 milliseconds planned under a separate upgrade. Shorter slots change how often the network can produce them; Alpenglow changes how validators agree that a block is final.
A previous crypto.news report covered the testnet preparations on Sept. 23, when developers were preparing Agave 4.3 for the public test. The move to devnet now gives application teams access to the upgraded consensus system in the network they commonly use for development.
Block-data services face changes before mainnet
For an application that sends transactions and reads account balances, the Foundation says Alpenglow requires no migration. Transaction execution, fees, and the formats used to send transactions remain the same under the consensus upgrade.
Services that build transaction histories have more work to do. Alpenglow can expose competing candidate blocks for the same slot before the network selects one. The Foundation tells data providers to keep those candidates separate, then retain the block that reaches confirmation. Combining transactions from different candidates could leave an explorer or other service with an incorrect record.
Validator votes will also disappear from blocks because they will no longer be submitted as transactions. As a result, a chart that counts both user transactions and validator votes will show a lower transaction total after activation even if users make the same number of payments and trades. The Foundation has told data providers to reset comparisons and alerts built on the old figures.
Some services also read validator participation from vote transactions. Under Alpenglow, the Foundation says that information moves to certificates attached to block data, requiring those services to change where they obtain it. Operators using Solana’s Geyser or gRPC data streams must also account for the identifiers that distinguish candidate blocks within a slot.
The changes make devnet testing relevant to exchanges, explorers and other firms that rely on transaction records, including U.S. services connected to Solana. Their deposit rules remain their own operational decision; the network upgrade does not automatically change when a platform makes funds available.
Mainnet activation still has no firm date
Solana’s earlier Alpenglow roadmap tied the proposed mainnet rollout to Agave 4.3 and an October target. Neither the testnet transition nor the devnet activation sets a confirmed date for the live-network switch.
Anza’s software schedule tentatively allows mainnet feature activations to resume on Sept. 28. The schedule does not identify that day as Alpenglow’s activation date, and the Foundation’s status page still lists the upgrade as inactive on mainnet.
The Foundation describes Votor as the first phase of Alpenglow. A later phase, Rotor, is planned to replace the system used to spread blocks across the network. The current rollout concerns the voting and finality changes, while the roughly 150-millisecond target comes from testing and simulations rather than transactions settled under live-market conditions.
Leave feedback about this