Alpenglow explained: Solana's new consensus, tested from the inside
What Alpenglow changes on Solana: finality in 150 milliseconds instead of 12.8 seconds, cheaper validator voting, and life inside the community test cluster.
Alpenglow is the biggest change Solana has ever made to itself. It replaces the way the network agrees on blocks, retires Proof of History, and cuts the time to real finality from 12.8 seconds to roughly 150 milliseconds.
The design came out of Anza’s research team in 2025, validators approved it in a governance vote that summer, and mainnet activation is targeted for late 2026. Since May 2026 it has been running on a dedicated community cluster - and I have been part of it since its first genesis. This article is my attempt to explain Alpenglow in plain language: what it is, why it gives Solana a new gear, who will feel the change, and what testing it looks like from the inside.
How Solana reaches finality today
Solana’s current design rests on two pillars. Proof of History is a cryptographic clock: a continuous chain of hashes that lets validators agree on the order of events without constantly talking to each other. Tower BFT is the voting system built on top of that clock - Solana’s take on classical Byzantine fault tolerant voting: every validator sends a vote transaction for every slot, roughly every 400 milliseconds, around the clock.
This design made Solana fast, but it has a price. Vote transactions make up about three quarters of everything the network processes, and the fees on them are the biggest recurring bill a validator pays - roughly 1.1 SOL per day, or about 2.16 SOL per current two-day epoch. And while a block is treated as confirmed within about half a second, true deterministic finality requires 32 more blocks on top of it - roughly 12.8 seconds. For most uses that gap does not matter. But for exchanges, market makers, and anyone who needs certainty rather than confidence, it does.
Alpenglow in plain language
Alpenglow rebuilds this from the ground up around two components.
Votor is the new voting engine. Votes stop being transactions. Instead, validators exchange tiny vote messages directly with each other, off the chain, and any node can aggregate them into one compact certificate once enough stake has spoken. Two finalization paths run at the same time: if a block collects at least 80% of stake in the first round, it is finalized instantly - the fast path, around 100 milliseconds. If it collects at least 60%, a second round starts, and another 60% finalizes it - the slower path, around 150 milliseconds. Either way, consensus on a block is sealed by one small certificate instead of thousands of vote transactions. And since finalizing one block takes less time than producing the next, finalization keeps pace with the chain - no queue of unfinalized blocks ever builds up.
Rotor is the new data distribution layer. Today, the Turbine protocol passes block data down a tree of validators, layer by layer. Rotor flattens that into a single hop. The leader splits the block into erasure-coded pieces and hands each piece to a relay - a regular validator picked for that slot by stake weight. Every relay then broadcasts its piece to the entire network at once. Fewer hops mean lower latency and fewer things that can go wrong.
And Proof of History retires. With single-hop data and sub-second voting, the network no longer needs a shared cryptographic clock. Slots keep a fixed length, and each validator simply runs local timers: if a block arrives in time, vote for it, and if not, vote to skip the slot. These timers are relative countdowns, not synchronized clocks - nodes do not need to agree what time it is. And a skipped slot is not an accident scene: it just passes the turn to the next leader, the same way skipped slots work today, and gets its own certificate, so there is always an unambiguous answer to what happened in slot N.
Alpenglow also brings a new resilience model, called “20+20”: the network stays safe if up to 20% of stake is outright malicious, and keeps producing blocks if another 20% on top of that is offline or broken. That is a deliberate trade: slightly less tolerance to coordinated attackers than the classical one third, in exchange for sub-second finality and graceful behavior during real-world outages.
What actually changes
For users and traders:
| Today | With Alpenglow | |
|---|---|---|
| Finality | ~12.8 s | ~100-150 ms |
| Commitment levels | Confirmed, then finalized ~12 s later | Effectively one: finalized |
| What TPS shows | ~75% of transactions are votes | User transactions only |
For validators:
| Today | With Alpenglow | |
|---|---|---|
| Voting cost | ~1.1 SOL per day in fees, from the identity account | VAT: ~0.8 SOL per day, from the vote account |
| Signing load | Identity key signs every slot | No per-slot vote signing - key management can get far more conservative |
| Fork protection | Vote lockouts and the local tower file | Finalization certificates and the local vote history file |
| Accounting | ~432,000 vote transactions per epoch | One participation fee per epoch |
For the network:
| Today | With Alpenglow | |
|---|---|---|
| Clock | Proof of History hash chain | Local timers on every node |
| Block propagation | Turbine, a multi-layer tree | Rotor, a single hop through relays |
| Slot time | ~400 ms | Stepping down toward ~200 ms |
| Ledger growth | Inflated by vote transactions | Roughly three quarters lighter |
| Fault tolerance | Up to 1/3 faulty stake | 20% malicious plus 20% offline |
A few of these deserve a closer look. TPS - transactions per second, the number everyone quotes when comparing chains - finally starts to show real user activity, because votes no longer count as transactions. The long gap between “confirmed” and “finalized” collapses into a single certificate check, which matters most for exchanges, payments, and anything latency-sensitive.
For developers the change is quieter but just as real. The two commitment levels collapse into one, so apps stop juggling confirmed-versus-finalized logic. Blocks arrive without vote transactions, which makes indexing lighter and block data cleaner. And with finality at 150 milliseconds, the whole genre of optimistic interface tricks - showing a result and hoping it sticks - can simply retire.
On the validator side, vote fees as we know them disappear, but they are not simply erased - they are replaced by the Validator Admission Ticket, or VAT: a single payment per epoch, charged from the vote account, that buys the right to participate in consensus for the next epoch. It is being calibrated at about 0.8 SOL per day, against the roughly 1.1 SOL per day validators pay in vote fees now. The numbers were deliberately kept close so that validator economics do not jump at activation, and deeper economic changes are explicitly left for future, separate decisions. Beyond the ticket, operations get simpler: nothing needs the identity key every 400 milliseconds anymore, so keys can be handled much more conservatively, there is no more lockout math, and accounting shrinks from four hundred thousand vote transactions per epoch to one fee.
How the idea became a protocol
Alpenglow comes out of Anza’s research division, led by Professor Roger Wattenhofer of ETH Zurich - the Swiss technical university, whose abbreviation predates Ethereum by about a century - together with Quentin Kniep and Kobi Sliwinski. The team published the whitepaper and unveiled the design at the Accelerate conference in New York in May 2025, with formal mathematical proofs of correctness attached. Even the name is a nod to the protocol’s Swiss roots: Alpenglow is the light that sets mountain peaks glowing at dawn.
The design became a formal proposal, SIMD-0326, and in late August 2025 it went to an on-chain governance vote. Validators approved it decisively: 98.27% voted yes, with 52% of all stake taking part - one of the strongest mandates any Solana proposal has received. I voted yes with my validator and would do it again. Since then, the pieces have been landing step by step in the Agave validator client, external audits have been running, and the community cluster has been doing the rest.
The community cluster: a new consensus meets real people
You cannot test a consensus rewrite on paper. It has to be started, broken, restarted, and broken again - and that is exactly what the Alpenglow community cluster is for.
It launched in early May 2026: around fifty independent operators brought their own hardware, Anza engineers prepared a genesis, and the cluster came alive once 80% of its stake was online and ready. There are no rewards here - everyone is a volunteer, giving the developers real-world data at the cost of their own servers, time, and attention. I have been in it since that first genesis, and along the way helped several operators from the Ukrainian community bring up nodes of their own.
Anza could have spun up twenty of its own machines and called it a testnet. The point of the community cluster is that it is made of real people: different hardware, different datacenters, different time zones, different habits and opinions. That is much closer to what mainnet actually is - and it surfaces problems no lab setup ever would.
The moment everyone remembers is May 9 - the first Alpenswitch, when the cluster switched consensus live from TowerBFT to Alpenglow mid-flight. Finalization times dropped dramatically, and a chat full of node operators got to watch a 12-second network become a millisecond one in real time. One of the questions raised in the cluster chat that very day - what happens to vote credits when voting leaves the chain - is one that validators and stake pools are still figuring out.
Since then the cluster has lived the life it was built for. Coordinated restarts, and a new Alpenswitch after each of them. Features switched on here before any production cluster sees them. Genuinely useful failures too - more than one - of the kind you can only catch on a network this real. The cluster has since moved to the fast slots as well: by August it was already running at roughly 200 milliseconds per slot, the pace mainnet is heading toward. And the cluster has become a proving ground for more than the consensus itself: Overclock tests its Mithril light client here, the new on-chain governance voting flow got a parallel trial run here alongside mainnet, and teams like Allnodes, JPool, JagPool, and QuickNode keep nodes of their own in the set. Anza engineers are in the trenches daily, and the cluster has grown to around a hundred validators.
Tools the community built
One of my favorite things about this cluster is how quickly operators started building for it. Within weeks, a temporary test network had its own explorers, dashboards, status pages, and even a stake pool - all community-built:
| Tool | What it does |
|---|---|
| Valid Blocks explorer | Block explorer for the cluster, a live leader-schedule feed, and a working faucet |
| Validator.Info | Cluster analytics: finalization latency, quorum state, voting leaderboard, rewards calculator |
| Trillium | Live dashboard: slot times, epochs, leader schedule, per-validator performance |
| Vybe | Extended cluster metrics |
| SONDA | Decentralization and datacenter distribution metrics |
| Puffin metrics | An early attempt at new voting metrics: who contributes to fast finalization |
| agSOL pool | A liquid stake pool for the test cluster itself |
| Abracadabra | Terminal UI that makes Alpenglow validator logs readable |
One of the cluster’s own participants also curates a living list of these tools - it keeps growing here.
The support nobody promised
The cluster was a volunteer effort from day one. Everyone who joined knew there would be no rewards - this was work for the network’s sake, and that was the deal. And then support started appearing anyway, from the community itself, each team in its own style.
SolBlaze is one of the quiet legends of Solana staking: a solo builder who has been shipping liquid staking infrastructure since the network’s earliest days and grew his pool from two thousand SOL to over a million without a single VC behind it. On the community cluster he is everywhere: a genesis operator, the builder of the cluster’s largest stake pool, and the de facto moderator of the cluster’s Discord channel. In May he put mainnet stake behind the volunteers:
Currently, many validators are volunteering their time and hardware towards a community cluster to test out Alpenglow before it goes live on mainnet, but there are no incentives in place to reward active community cluster operators […]
Therefore, we are allocating up to 50k SOL in mainnet stake to validators participating in the Alpenglow community cluster.
That is a shared pool of up to 50,000 SOL - individual validators can receive up to 2,000 - distributed through the SolBlaze Verified Validators program, announced here. More than compensation, it is a way of telling the volunteers their work is noticed.
Allnodes looked at the same problem from the infrastructure side. It is one of the largest node-hosting platforms in crypto, running validators and nodes across dozens of networks, with high-performance bare-metal servers, including machines built specifically for Solana - and it is the biggest hosting provider on the community cluster itself, with almost a fifth of the cluster’s validators on its machines. For the cluster’s long-time participants, Allnodes offers free bare-metal servers for as long as the cluster remains operational, until Alpenglow goes live on mainnet. Konstantin Boyko-Romanovsky, the founder and CEO of Allnodes, shared his motivation with me:
This is a challenging time for many validators, and we didn’t want hardware costs to stand in the way of testing and adoption. By providing free infrastructure for the Alpenglow community cluster, we hope to make it easier for operators to experiment, contribute, and help prepare the network for what’s next.
This is my favorite part of the Solana validator world: people who notice each other’s work and step in to support it. At its best, this ecosystem feels less like an industry and more like a family.
The bug bounty: last public stress test
With external audits wrapping up, Anza opened the Alpenglow logic to a dedicated bug bounty competition: a prize pool of up to 50,000 SOL, a submission window from August 5 to August 19, 2026, and findings filed through GitHub Security Advisories, one per report. While Alpenglow was being built and audited, its code sat outside the regular Agave bounty program - this competition is its public debut, and the last big shake before mainnet.
The open questions validators are living with
This is the part you will not find in the whitepaper, because it comes from the cluster chat and from operators’ own planning. Alpenglow answers the big questions and opens a set of very practical new ones.
How do you measure performance when votes leave the chain? Today the delegation industry runs on vote metrics: timely vote credits are among the key inputs to the Solana Foundation’s delegation program and to the scoring of most major stake pools. With Alpenglow, vote credits are redefined - as Ashwin Sekar, an Anza engineer, explained in the cluster chat, the credit field now simply shows the exact lamports a validator is expected to receive for the epoch - and the old TVC-style rankings stop existing. What replaces them is still an open question. Puffin, a validator active on the community cluster, is already experimenting with metrics of who contributes to fast finalization. Zantetsu of Shinobi Systems plans to score vote latency - Alpenglow gives an 8-slot grace window for votes to be aggregated, and a pool can prefer validators who vote much faster than that - with the raw data gathered by a cooperative set of validators, since it is no longer on-chain. Anza has no ready answer either: no current plans, but an openness to suggestions, including a discussed idea of putting finalization certificates and reward aggregates into an on-chain account so RPC could serve them. For the first time in years, how validator performance gets measured is genuinely open ground - and the teams experimenting now are shaping what the standard will look like. My StakePools Dashboard will be watching how delegation responds, epoch by epoch.
Can users verify finality? Today anyone can check on-chain votes through RPC. Under Alpenglow, certificates are not exposed through RPC yet - a user querying a block essentially trusts the node’s word that it was finalized. Parsing the certificate from the shred stream is possible, but the debate about a cleaner, queryable proof is still running.
VAT is a new operational discipline. The admission ticket is charged from the vote account balance, once per epoch, in advance. Let that balance run dry and your validator drops out of consensus - and the way the advance payments work, getting back in takes a couple of epochs, not one. It is a small thing - and exactly the kind of small thing that will bite inattentive operators in the early days.
Migrations got stricter. Alpenglow’s replacement for the tower file is vote_history - a local file the node refuses to start without, because there are no on-chain votes left to rebuild your state from. An escape flag exists, but using it after the node has voted can produce a double vote, which the proposal treats as a provable offence and plans to make slashable. Anza’s stated intention is not to slash for hardware failures - the exact rules are what operators and developers will negotiate as slashing gets closer.
The transition itself will cost money. Before Alpenglow ships, mainnet slot times are planned to step down toward 200 milliseconds, in 50-millisecond increments - starting in August and penciled in for about six weeks, though schedules like this have a way of stretching. The same number of votes packed into half the time means the daily vote bill roughly doubles, to about 2.16 SOL. For large operators the difference is noise, for small ones it is real money every epoch. Shortening that expensive window is one more reason the community cluster exists: the more data the developers have, the faster it can end.
And a number to keep in mind: Alpenglow bounds the consensus set at 2,000 validators. Mainnet currently has around 700 and the count has been drifting down, so there is no squeeze today - but for the first time, the seat count is a design constant rather than an open horizon.
What happens next
The bug bounty runs through mid-August. The staged slot-time reduction begins on mainnet. The current plan ties Alpenglow to the Agave 4.3 release line: the code ships in the client first and switches on as a feature activation once the network is ready. The mainnet Alpenswitch itself is targeted for late this year. And the community cluster that made it possible will quietly retire, its dashboards frozen as artifacts of the strangest, most useful testnet Solana has run.
I plan to keep my node in it until the lights go out, and to be there when mainnet switches. After that the real work starts: running a validator under the new rules, learning the new metrics together with everyone else, tracking how delegation finds its shape in my dashboard - and keeping an eye out for the next big change Solana decides to make. There always is one.
Read more
A closer look at JPool, our liquid staking partner on Solana What JPool is and how it works: JSOL liquid staking, direct staking to your chosen validator, stake matching, and the Community Good program that backs Solana builders. 
Joining Superteam Ukraine: from Kumeka Team to a global Solana network CryptoVik is now a Superteam Ukraine member. The story of a community that grew from Kumeka Team into the Ukrainian hub of a global Solana network, told from a validator seat.