On September 24, 2026, Solana activated Alpenglow on its public testnet. On paper the upgrade does one thing: it cuts the time to finality from roughly 12.8 seconds to about 150 milliseconds — a change of about 85x. In practice it replaces the two mechanisms that have defined Solana since launch, TowerBFT and Proof of History, with a single voting protocol called Votor. It is, by the network’s own description, the largest consensus change in Solana’s history.
The headline number is easy to quote and easy to over-read. A blockchain upgrade that ships a 150-millisecond target is not the same as a network that finalizes in 150 milliseconds in production. This article explains what Alpenglow actually changes, why finality is harder than throughput, what the client migration requires, and what to watch between the testnet and mainnet.
Key takeaways
- Alpenglow replaces TowerBFT and Proof of History in consensus with Votor, designed by Anza.
- It targets finality of about 150 milliseconds, down from roughly 12.8 seconds today — a stated target, not yet a measured mainnet result.
- Public testnet activated September 24, 2026 (slot 444,625,255); devnet followed on September 25 (slot 504,148,999).
- Mainnet requires Agave 4.3, targeted for October 2026. A first migration depends on Agave alone, temporarily reducing client diversity.
- Frankendancer support ends when Alpenglow activates, giving validators roughly a four-week window to move to full Firedancer or back to Agave.
What Alpenglow actually changes
Alpenglow is a new consensus protocol, not a new blockchain. It keeps Solana’s account model, its execution environment, and its ~400-millisecond slot time. What it replaces is the agreement layer: how validators decide that a block is final and can never be reverted.
Today that job is split between TowerBFT, a variant of practical Byzantine fault tolerance tuned for Solana’s fast slots, and Proof of History, a cryptographic clock that has long been Solana’s signature and its most misunderstood feature. Alpenglow removes Proof of History from the consensus path entirely, replacing it with a fixed slot time plus local timeout timers, and swaps TowerBFT for Votor.
The proposal behind it, SIMD-0326, was approved by validators with 98.27% support in September 2025. The unusually high number reflects a simple fact: finality latency has been Solana’s most-cited weakness, and the fix is not controversial. What is hard is shipping it without breaking a network that thousands of applications depend on.
How Votor reaches 150 milliseconds
The central idea in Votor is that voting moves off-chain. Instead of submitting each vote as an on-chain transaction, validators broadcast votes directly to one another as lightweight messages, and any node aggregates them into a compact certificate (a BLS12-381 signature of roughly 1,000 bytes) that is anchored on-chain. That single change has two effects:
- It frees block space. Roughly 75% of all Solana transactions today are validator votes. Moving them off-chain returns a large share of capacity to real transactions.
- It shortens the path to finality. Agreement no longer waits on block inclusion, so finality can be reached in one or two rounds of message-passing instead of the TowerBFT schedule.
Votor runs two finalization paths concurrently. A fast path finalizes in a single round when at least 80% of stake participates, targeting around 100 milliseconds. A fallback path finalizes in two rounds at a 60% threshold, targeting about 150 milliseconds. Under that model, the protocol tolerates 20% adversarial stake plus 20% offline or crashed stake — a security budget spelled out explicitly rather than implied.
Why 150 milliseconds is a target, not a measurement
Here is the caveat that every Alpenglow headline should carry. The 100–150 millisecond figures come from Anza’s simulations against the current mainnet stake distribution, plus an early community test cluster that ran at what was variously called ~100x the current speed. There is no published p50 or p99 finality data from mainnet, because mainnet has not run Alpenglow yet.
That does not make the numbers dishonest; it makes them provisional. Consensus upgrades are famous for looking binary in simulation and messy in production, where real-world stake distribution, network geography, and adversarial behavior all bite. The honest way to read “150 ms” is as the design goal the implementation is being tested against — and the testnet is where it either holds or does not.
Finality versus throughput: two different problems
It is worth separating two properties that get conflated. Throughput is how many transactions a network can process per second. Finality is how long until a transaction is irreversible — how long an exchange, bridge, or custodian must wait before it can safely treat a deposit as real.
Solana has always been fast on throughput and slow on finality, relative to its own ambitions. That gap is expensive for everyone downstream: an exchange that must wait 12.8 seconds before crediting a deposit is, in practice, running a slower business than a chain that can confirm in 150 milliseconds. Cutting finality is therefore not a vanity metric. It changes how fast centralized services can settle on top of a decentralized network — and that is the case Alpenglow is really making.
The migration problem: clients must move
Alpenglow requires Agave 4.3, the validator client maintained by Anza. That is where the upgrade gets operationally interesting, because Solana does not run on one client. A significant share of stake runs on Firedancer, Jump Crypto’s independent implementation, or on Frankendancer, a hybrid that pairs Firedancer’s networking stack with Agave’s consensus.
Alpenglow breaks that hybrid on purpose. Jump Crypto’s team explained the logic plainly: Frankendancer exists to bridge Firedancer’s networking with Agave’s consensus, and Alpenglow removes the consensus half of that bridge. Since Votor replaces TowerBFT, a client borrowing Agave’s consensus has nothing left to borrow — so Jump chose to retire Frankendancer rather than port it.
- The first migration depends on Agave alone — neither Firedancer nor Frankendancer supports Votor at activation.
- Frankendancer has run on mainnet since September 2024; full Firedancer since December 2025.
- The Firedancer family controls roughly 14%–26% of Solana’s stake, with full Firedancer alone at about 11%–14%.
- Operators get roughly a four-week window — from the late-September feature gate to October activation — to upgrade to full Firedancer or revert to Agave.
- Miss the window and a validator risks dropping out of consensus: no block rewards, no vote credits.
This is why the client mix becomes a genuine risk factor for the first time with Alpenglow. A consensus upgrade that temporarily funnels every validator through a single client is, by definition, a moment of reduced client diversity — the opposite of what the ecosystem usually wants.
The economics of voting change too
Moving votes off-chain does not make them free; it changes who pays and how. On-chain vote transactions disappear, replaced by a 1.6 SOL per-epoch Validator Admission Ticket (SIMD-0357) that is burned rather than redistributed. Two earlier steps gated the change: BLS public-key registration (SIMD-0387) activated on mainnet on July 8, 2026, and the VAT gate activated on July 22. Validators without a registered BLS key have been excluded from consensus since.
Separately, Solana is reducing its slot time independently of Alpenglow: SIMD-0525 cuts it from 400 to 350 milliseconds, with further targets of 300, 250, and 200 milliseconds. Alpenglow’s finality change and the slot-time change are related but distinct levers, and both must land for the full picture to show up in production.
Turbine’s successor is a later phase
For completeness: Alpenglow does not change Turbine, Solana’s block-propagation layer. Its replacement, Rotor, is a separate, later phase. This matters because it sets the boundary of what the first Alpenglow release can claim. The upgrade improves agreement; it does not, on its own, rework how blocks travel across the network. Reading the two as one change is a common mistake in coverage.
Why faster finality matters downstream
Finality is an infrastructure property, which is why its benefits show up somewhere other than the chain itself. Every service that touches Solana — an exchange crediting a deposit, a bridge releasing funds on the other side, a payments processor settling a merchant, a custodian reporting a balance — currently waits out the 12.8-second window. Cut it to a fraction of a second and each of those services can tighten its own loop.
For exchanges, faster finality means less capital tied up in the gap between “deposited” and “confirmed.” For bridges, it shortens the window in which a relayer or validator set is exposed. For payment networks, it moves on-chain settlement closer to the instant confirmation that card rails already provide. None of these are headline features, and that is the point: the upgrade changes a parameter that a great deal of software quietly depends on.
How this compares with Ethereum’s approach
It is useful to set Alpenglow beside Ethereum’s next upgrade, Glamsterdam, because the two L1s are solving related problems from opposite ends.
- Solana (Alpenglow) is optimizing agreement: how small the window is before a transaction is irreversible. It moves voting off-chain and replaces its consensus algorithm to shrink finality.
- Ethereum (Glamsterdam) is optimizing validation and block production: block-level access lists let clients validate in parallel, and enshrined proposer-builder separation moves the block-building market into the protocol.
Both upgrades reduce a structural ceiling, but they measure success differently. Solana’s number is a time — milliseconds to finality. Ethereum’s numbers are a multiple — roughly 5x faster block validation, and a payload window extended from about 2 to about 9 seconds. A user watching both will see the same theme from two directions: the base layers are being tuned for what is built on top of them, not for the demo.
What to watch
- The mainnet activation date. “October 2026” is a target tied to Agave 4.3, not a schedule. Watch for a named epoch and slot.
- Measured finality after activation. The first published p50/p99 numbers on mainnet will replace the simulation target with fact.
- Client diversity through the migration. Whether Firedancer ships Votor support and how much stake moves back to independent clients after the four-week window.
FAQ
Is Alpenglow live on mainnet?
No. As of early October 2026 it is live on public testnet (September 24) and devnet (September 25). Mainnet activation requires Agave 4.3, targeted for October 2026 with no confirmed date.
What is Votor?
Votor is the voting protocol at the core of Alpenglow. It moves validator votes off-chain, aggregates them into compact BLS certificates, and finalizes in one round at 80% stake participation (fast path) or two rounds at 60% (fallback).
Does Alpenglow remove Proof of History?
It removes Proof of History from the consensus path, replacing it with a fixed slot time and local timeout timers. Proof of History’s other roles are not the subject of this upgrade; the change is specifically about how agreement is reached.
Will Alpenglow make Solana faster at processing transactions?
Indirectly. It frees block space by moving votes off-chain — votes are roughly 75% of transactions today — and it cuts finality to a design target of about 150 milliseconds. Raw throughput still depends on execution and networking, which is why slot-time reductions (SIMD-0525) and Rotor are separate efforts.
Do SOL holders need to do anything?
No. The migration work falls on validators, and the indirect work on exchanges, bridges, indexers, and custodians, which must adapt to faster finality and new data structures. Validators must migrate their clients within the four-week window.
Why does the client mix matter so much here?
Because the first Alpenglow migration runs entirely through Agave — Firedancer and Frankendancer do not yet support Votor. That temporarily concentrates the network on a single client, which is exactly the concentration that independent implementations like Firedancer exist to reduce.
How does Alpenglow compare with Ethereum’s Glamsterdam upgrade?
They target different bottlenecks. Glamsterdam is Ethereum’s next upgrade, focused on block production and validation — ePBS and block-level access lists. Alpenglow is Solana’s consensus rewrite, focused on how fast a block becomes irreversible. Solana is chasing a smaller finality window; Ethereum is chasing faster, more parallel validation and a more open block-building market. Both aim at the same broad goal — more room for what is built on top.
Bottom line
Alpenglow is best understood as a finality upgrade, not a throughput headline. It replaces the mechanisms Solana has used since launch, moves voting off-chain to buy both speed and block space, and asks a large share of validators to move clients on a tight timetable. If the target holds on mainnet, the more interesting effect will not be the millisecond count — it will be how much faster centralized services can safely settle on top of Solana. Until then, treat 150 milliseconds as the goal, and watch the testnet and the client migration for the proof.
Sources
- Solana Foundation — Alpenglow upgrade page
- Chainstack — Solana: Alpenglow consensus explained
- CoinDesk — Solana starts testing upgrade that could cut finality from 12.8 seconds to 150 milliseconds
- KuCoin News — Solana founder highlights Alpenglow devnet activation, targets 150ms finality
- Edgen — Solana validators get 4 weeks to migrate as Alpenglow nears
