Anza confirmed Solana's Alpenglow upgrade activates on mainnet-beta October 21, targeting finality near 150 milliseconds against today's 12.8 seconds.
SOL$107.15-1.22%Updated 14 October 2026: Anza has confirmed that Alpenglow goes live on Solana mainnet-beta on October 21 at about 14:50 UTC, so the article now carries the date, the migration mechanics, the validator requirements and the.
Anza has set a date. Alpenglow, the consensus overhaul designed to cut Solana's finality from about 12.8 seconds to roughly 150 milliseconds, activates on mainnet-beta on October 21 at about 14:50 UTC. Anza, which builds Solana's Agave validator client, frames the work as 18 months, and says the change takes finality "from seconds to ~150ms."
Finality is the moment a transaction stops being "probably done" and becomes settled. Under TowerBFT, Solana took about 12.8 seconds to get from a new block to that point. Alpenglow is meant to close that gap to roughly 150 milliseconds.
That's not a small tune-up. In its announcement of Alpenglow, Anza calls it:
the biggest change to Solana's core protocol since, well, ever.
The 150ms figure comes from simulations, not live network measurements. So it's worth seeing what's been changed to make it possible, what has to happen on October 21, and what the number does and doesn't tell you.
Alpenglow retires two pieces of Solana's original design: TowerBFT and Proof-of-History. Gossip, the old way messages spread across the network, is replaced with direct communication.
The job of voting and finalizing blocks moves to a new component called Votor. Its rule is simple to state. If 80% of the stake is participating, a block is finalized in a single round of voting. If only 60% of the stake is responsive, it takes two rounds.
The neat design choice is that both paths run concurrently. Picture two lanes open at the same time: the fast lane needs more of the network to show up, the slower lane needs less. The comparison has limits, since nothing here is a physical queue, but the point holds. The network isn't forced to pick one route before it knows how many validators are answering.
Voting is only half the problem. Before validators can vote on a block, its data has to reach them.
Solana has done that with Turbine, which passes data through a multi-layer tree of nodes. Alpenglow's replacement, Rotor, uses a single layer of relay nodes instead. Fewer layers means fewer handoffs between the block's producer and the validators who need to see it.
Anza expects Alpenglow to reach finality in about 150ms at the median, and sometimes in as little as 100ms. Set against the 12.8 seconds under TowerBFT, the median target works out to roughly 85 times faster.
Two qualifiers matter here, and Anza states both. The numbers are based on simulations using the current mainnet stake distribution. They also don't count computation overhead, the time machines spend actually processing the work.
Geography is a big part of that simulation. Anza says about 65% of Solana's stake sits within 50ms of network latency from Zurich. The long tail of stake is more than 200ms away. A finality target this tight is shaped by where validators physically are, and the simulation assumes the stake map as it stands today.
Speed comes with a stated tolerance for things going wrong. Anza describes Alpenglow's resilience as "20+20": it is designed to tolerate up to 20% of stake acting adversarially, plus another 20% of stake that simply isn't responding. TowerBFT handled under 33% adversarial stake, with no separate allowance for validators that go quiet.
That pairs with Votor's two thresholds. The single-round fast path needs 80% participation, while the two-round path can still finish with 60% responsive.
The switch doesn't happen the moment October 21 arrives. The migration runs through a feature gate, SIMD-0384, which activates at an epoch boundary. Nothing migrates immediately.
Then, 5,000 slots later, the migration boundary hits. Blocks stop carrying user transactions at that point and hold only votes. Anza's page explains why that matters: it's what makes the handoff safe, because every block past the boundary can be rolled back without losing anything a user signed.
At the boundary, validators wait for one block to get 82% of stake voting for it in the following slot. That block's last ancestor before the boundary becomes the Alpenglow genesis block, the starting point the new protocol builds from.
Anza expects the whole handoff from TowerBFT to Alpenglow to take hundreds of milliseconds. After that, TowerBFT is retired.
Every validator has to register a BLS public key on its vote account. That isn't new housekeeping. The Validator Admission Ticket feature gate, live on mainnet since July 22, 2026, already requires it, and an operator without a registered BLS pubkey is excluded from the admitted validator set and stops taking part in consensus.
Validators also need to upgrade to Agave 4.3, the release that carries Alpenglow, and check the cluster's consensus state with the solana alpenglow-genesis-info command. It returns null while the cluster is still on TowerBFT, and the Alpenglow genesis certificate once migration is complete. That gives an operator a simple way to tell which side of the switch they're on.
The sequence has been rehearsed. Alpenglow activated on Solana's public testnet on September 24, 2026, and on devnet the next day at epoch 1167.
Alpenglow touches consensus only. The Solana Virtual Machine, transaction formats, programs and fee mechanics stay as they are. For most application developers, that means no migration at all: apps that send transactions and read account state keep working. The work lands on validators and the low-level infrastructure providers that consume block data.
Those block stream consumers get one new field to handle. A bank_id distinguishes multiple banks within a single slot, and any timeout, retry or user experience delay tuned to 12.8-second finality should be rechecked.
Anyone reading commitment levels has a change coming too. Under Alpenglow, confirmed equals finalized, and the confirmed commitment level is set to be deprecated. Agave 4.4, planned for November 2026, will require sBPFv3 for new program deployments and add fast leader handoff, which makes multiple banks per slot more common.
Alpenglow is separate from the slot time reduction. Solana began moving slot times from 400ms toward 200ms at block 440,208,000, or Epoch 1,019, after six years that included roughly one year flat at 400ms. That 200ms target went live on 9 October 2026.
Shorter slots came with a cost. Vote latency rose, with nodes in Asia and South America affected most. Under TowerBFT every vote is a transaction that has to land on chain, and a shorter slot leaves it less room to do that. Solana's own write-up calls votes "transactions, that need to land on-chain," and points to Alpenglow as the fix: votes become direct messages between validators, with proof of voting collected within 8 slots.
The 150ms figure remains a simulated median rather than a measured one. The simulations used today's stake distribution and left out computation overhead, so the real number will be decided by processing time and by how far the slowest validators sit from the rest. That is the figure to watch once the network is running the new protocol.
The effect on validator economics, such as vote costs and fees, is another thing this reporting doesn't establish.
The clock is now set: October 21, around 14:50 UTC, with the migration boundary following 5,000 slots later.
Ethereum is caught between bulls and bears with no clear winner emerging this week.
BGB
Bitcoin is at a crossroads. Here's what the charts are really telling us right now.
BTC
Here's why the smart money is watching NEAR closely.
NEAR
