Alpenglow is live on Solana's devnet, with no mainnet date set
Victoria Shinder2 min readAlpenglow, the consensus protocol meant to replace Solana's Tower BFT, is now running on the network's developer network. Anza, the company that builds Solana's main validator client, announced the devnet switch on 25 September, a day after the testnet completed its own transition, according to CoinDesk. The Solana Foundation's transition dashboard lists Alpenglow as active on devnet, from genesis slot 504,148,999.
The design target is finality in roughly 150 milliseconds, against about 12.8 seconds under the current system. Validators will exchange votes directly instead of submitting them as transactions inside blocks, and agreement takes one or two voting rounds. The dashboard gives a first live reading. When we opened it on the morning of 26 September it showed 13 certificate signers on devnet, a latest observed finality of 322 milliseconds, and a tower vote share of 0% of block transactions - the old vote transactions are gone. Devnet is a test network with a small validator set and tokens of no value, so neither number says much about mainnet conditions, and the 150 ms figure remains a target derived from simulation.
No mainnet launch date has been set. Anza's release schedule tentatively allows feature activations to resume on 28 September, but does not name that as Alpenglow's date.
What it means
The most immediate effect will be on data, not on users. Because votes currently count as transactions, Solana's headline transaction totals will fall sharply once Alpenglow reaches mainnet even if user activity is unchanged; the Foundation has warned data providers to adjust their comparisons. Any dashboard, report or investment thesis built on raw transaction counts needs a break in the series at the switch-over.
For builders, the Foundation says applications that only send transactions and read balances need no migration. Indexers and anything that reconstructs transaction history do: until the network settles on one block, competing candidate blocks must be kept apart, and merging them can produce a wrong record. Exchanges and payment apps should also remember that faster consensus finality does not shorten their own deposit confirmation policies automatically - those are set by them, and will need an explicit decision once mainnet numbers exist.