Alpenglow: How Solana Swaps Its Consensus in One Slot

Solana consensus has been using the same design since 2020. Every validator publishes votes as transactions in the blocks, adds increasingly strong lockouts and declares a block final once 32 more blocks have built upon it. It works, but it lacks a published safety proof, consumes over half of all transactions in the network, and its finality takes seconds despite the rest of the stack working in milliseconds.

Alpenglow is its replacement. The design is due to Quentin Kniep, Jakub Sliwinski, and Roger Wattenhofer, who left ETH Zurich and joined Anza after publishing their research on liveness issues in TowerBFT. Alpenglow was published in May 2025. Validators approved SIMD-0326 in September 2025 with 98.27% of participating stake in favor, and the protocol has been running on a community cluster privately for five months, undergone a bug bounty, rehearsed nine migrations and flipped on testnet and devnet. Mainnet is next.

Why TowerBFT Has to Be Replaced

There are three layers in today's consensus. Proof of History provides validators with a shared clock through continuous hashing. Turbine propagates blocks via a tree of validators, and Alpenglow will preserve this functionality for now. TowerBFT is a voting layer where every validator sends a transaction with the vote for the block it received, and this vote transaction is included into a future block similarly to others. Once there are 32 blocks built upon a block, it is rooted.

This 32-slot wait is responsible for the famous 12.8-second delay at 400-ms slots. Slots are 200 ms now under SIMD-0525, so the wait takes about 7 seconds on mainnet. Way before this moment, the block is optimistically confirmed at 66% of stake, which is what confirmed reports and most applications use.

The reasons for switching to Alpenglow are listed explicitly in SIMD-0326. Finality is slow for anyone requiring a no-rollback guarantee. Vote transactions make up between 54% and 59% of all mainnet transactions in late September 2026, according to Solana Compass, and each of them costs the validator about 5,000 lamports, which adds up to roughly 2.16 SOL per epoch. The votes go through gossip and are verified on chain. And, finally, TowerBFT lacks a formal safety proof. Votor solves all four of these.

Votor: Two Voting Paths at Once

The leader broadcasts the block in chunks via erasure coding. The moment a validator receives a valid and complete block with a parent block that it has already voted for, it broadcasts the notarization vote directly to every other validator. There is no transaction and no gossip here, just a signed UDP message. Then two paths of actions begin at the same time.

First, the fast path: if some validator collects notarization votes from 80% of stake, it puts together the fast-finalization certificate and declares the block final after a single round. Then the slow path: once 60% of stake has notarized, every validator casts a finalization vote, and a finalization certificate is created from 60% of them.

The first path to succeed wins. If 80% of stake is close to you, the fast path wins. If only 60% is close to you, two fast rounds among the latter can beat the single slow round that needs to gather 80%. The protocol does not have to guess the case.

The 80% and 60% thresholds are a result of the fault model. Under 20% Byzantine stake, any 60% certificate will be composed of votes from over 40% of honest stake, and since any honest validator can cast only one notarization or skip vote per slot, it is impossible for two different blocks to gather 60%. This is the basis of the safety proof of the algorithm. Every certificate consists of one BLS aggregate signature and a bitmap of signers, and thus is small enough to fit in one UDP message.

Timeouts are replacing PoH. When a validator receives a certificate for the block before the leader's four-slot window, it sets a timer for each slot in this window at once. In Agave, the base timeout is 400 ms plus one block time per slot, so at 200 ms blocks, the first slot in a window times out 600 ms after the parent block becomes ready. If the block arrives first, the validator votes for it. If the timer fires first, it broadcasts a skip vote for this slot and all subsequent unvoted slots in this window. No clocks need to be synchronized, as every validator just measures local short intervals. A skip certificate at 60% is a definitive outcome, and the next leader builds upon the latest notarized block, effectively ignoring the skipped slot.

Two fallback votes help to deal with leaders broadcasting different blocks to different validators. A validator who skips a block can switch to a notar-fallback vote once it notices 40% of stake notarizing a block, while a notarizing validator can switch to skip-fallback once it becomes obvious that no block can collect 80%. This guarantees that every slot will end with either a notarized block or a skip certificate. If no slot finalizes for 10 seconds, the validators rebroadcast their latest certificates and increase timeouts by 5% per window, so eventually even a regional outage resolves itself without coordination.

The 20+20 Model, Honestly

The main claim is that Alpenglow tolerates 40% of stake going down. This is correct, but an imprecise statement, and an accurate one is important.

Under complete asynchrony, Alpenglow is safe as long as Byzantine stake is less than 20%. Even an adversary controlling the whole network and delaying every message could not make two honest nodes finalize conflicting blocks. In addition to this, 20% of crashed stake does not affect the safety. As long as the propagation layer does not deliver different blocks for the same slot to different honest nodes, liveness is preserved. Thus, crash-only faults under 40% stake are always tolerated.

However, an adversary who controls a leader with 18% stake and can partition the honest network into two isolated clusters and broadcast different blocks to each of them can stall a slot. A well-distributed validator set makes it hard to do, but it is a known liveness attack. Therefore, understand 40% fault tolerance as 20% malicious plus 20% crashed, not as 40% malicious.

Compared with TowerBFT's 33% Byzantine bound, Alpenglow is worse against a coordinated attack by more than 20% and less than 33% of stake and better against anything else. The trade-off here is that in a large proof-of-stake network, a coordinated attack by a third of stake is not the most likely scenario. Bugs, misconfigurations and outages are, and these correspond to crashes. Signing two conflicting votes is a provable violation under SIMD-0326, but slashing is a separate proposal and is not live yet.

Rotor Is Not Shipping Yet

Rotor is the second part of the design. It replaces Turbine's multilayer tree with a single layer of stake-weighted relays, and makes the leader's upload bandwidth not a limit anymore. Reaching 80% of stake would take around 150 nodes and roughly 2 ms. This is not included in the planned 21 October activation. The Foundation marks it as a feature for a later stage without any date, SIMD-0326 carves it out for its own proposal, and Turbine remains. Fast leader handover and geo-aware handoff are postponed as well.

Votes Are Out of the Blockchain

Three changes happened on the mainnet months before the migration to make off-chain voting possible.

BLS keys (SIMD-0387, July 8, 2026). Since the Ed25519 signatures cannot be aggregated, every validator had to register a 48-byte BLS public key in its vote account with proof of possession. A vote account without one will behave like unstaked when Alpenglow is active, and getVoteAccounts will show a blsPubkeyCompressed field, which is null for those accounts that haven't performed this operation.

The Validator Admission Ticket (SIMD-0357, July 22, 2026). Once the vote transactions are gone, the vote fees disappear too. The VAT replaces them with a flat fee, burned from the vote account at the beginning of each epoch, and gives admission to the next epoch. It was 1.6 SOL per epoch at 400 ms slots and scales with slot time, so at today's 200 ms slots, it is 0.8 SOL per epoch, compared with roughly 2.16 SOL that validators spend on vote fees now. The first charge will be done at the beginning of epoch 1064 and funds epoch 1065. A vote account that cannot pay is not admitted, and that validator neither votes nor produces blocks for the next epoch. The set of admitted validators is capped at 2,000 by stake, which is way above the roughly 680 voting validators today.

Rewards continue to exist. The leader of slot s+8 may include BLS aggregations of votes received for slot s; each included vote earns its voter a share of issuance, and the leader earns the same as each voter for performing the aggregation.

Thus, the practical outcome is that the vote account, not the identity account, has to remain funded. Anza recommends routing block revenue into the vote account to cover VAT automatically and warns that the reward paid at the epoch boundary is too late to rescue a validator that lacks funds at the admission time.

The Migration: Switching Consensus Engines in One Slot

SIMD-0384 describes the process of switching. Its goal is that no user-signed transaction should be dropped and if the migration fails, nothing will happen at all.

Activation. The feature gate becomes active at epoch 1064, which starts at slot 459,648,000, and the Foundation expects it to start around 15:00 UTC on Wednesday, 21 October. For now, nothing changes.

Boundary. Exactly 5,000 slots later, at slot 459,653,000 and about 18 minutes afterward, leaders start packing vote transactions only into blocks. Honest validators will mark any block with a user transaction as dead, and TowerBFT will stop rooting. Since all further blocks will contain only votes, rollbacks of any of them incur zero cost to users.

Genesis. The validators will wait for the block at or after the boundary carrying TowerBFT votes from at least 82% of stake in its direct child. Blocks usually carry votes from over 95% of stake, so the boundary block will usually pass immediately. The last block prior to the boundary in this chain will become Alpenglow's genesis block, every validator will sign a BLS genesis vote for it, and with 82% of stake, the genesis certificate will form.

Handoff. Seeing the valid certificate, every validator will launch Votor from the genesis block, disable TowerBFT, roll back all blocks past the genesis in the same way duplicate-block handling works, and enable user transactions again. The genesis certificate will be recorded in the first Alpenglow block and in an on-chain account, so a validator restarting from a later snapshot will know what consensus engine to run. Anza estimates the handoff to take hundreds of milliseconds, and Triton One estimates a user-visible gap of about two slots.

If 82% never signs the genesis, there will be no abort step, as there is no need for it. The validators will continue using TowerBFT, and the migration will not complete. There is no intermediate phase when the chain uses neither engine.

The client diversity issue. Firedancer's v26.10.2 release published on 14 October and labeled as mainnet ready supports Alpenglow consensus, but not the migration from TowerBFT to Alpenglow. So, for the migration itself, every validator must use a client descended from Agave 4.3.0, and that is practically Agave, Jito-Solana or Harmonic Salsa, and then may switch back to Firedancer. According to Solana Compass, as of 13 October, about 15.8% of stake among the top 500 validators used Firedancer-family clients. If this stake stays as is, what remains is barely above the 82% threshold. Anza has been quite explicit that these operators have to switch beforehand.

The Track Record

The community cluster became operational on 11 May 2026 with over 40 nodes. The first migration attempt uncovered two bugs that Anza acknowledged on the validator call of the Foundation and hotfixed. The next attempt completed successfully, and the cluster has been running since then. A public explorer shows the finalization time of about 107 ms and around 96% of blocks taking the fast path. A bug bounty lasted from August 5 to August 19, and featured a fund of up to 50,000 SOL, 115 researchers and more than 300 submissions. Anza has reported payouts exceeding 25,000 SOL, though the breakdown of severity has not been published. Testnet flipped on September 24 at slot 444,625,255, and devnet on September 25 at slot 504,148,999. Agave 4.3 including the full Alpenglow code was recommended for all mainnet validators on September 21.

The 150 ms figure is based on the latency simulation with real validator latencies, with a median around 110 to 130 ms and the slowest node below 200 ms. Consider it an expectation, not a fixed number. A 54 ms testnet median circulated without any publicly named source, so we do not reproduce it.

What Will Change for Developers

Execution will not change. The SVM, transaction formats, programs, fees and priority fees will stay the same. All below is about consensus outputs and data you rely on.

• Commitment levels. confirmed and finalized converge to the same state, defined as 60% of stake voting to finalize or 80% of stake notarizing, and finalized will arrive about 150 ms after the block instead of 32 slots later. They both will work on the activation day, and confirmed commitment level is scheduled for future removal, so use finalized in new code. Do not switch early. Until the genesis certificate is present, finalized commitment on the mainnet still means a 32-slot wait. Check getAgGenesisCert on your RPC, which will return null under TowerBFT and a certificate object once Alpenglow is live. The meaning of getBlockCommitment disappears, as there is no lockout stack to report.
• Transaction counts. Vote transactions will disappear from blocks, so per-block counts and every TPS chart will drop by over half without any change in actual activity. Adjust alerting thresholds before 21 October.
• Multiple candidate blocks per slot. A leader may produce multiple blocks for a slot, and only one will be notarized, so Agave 4.3 will tag Geyser events with a bank_id, and Yellowstone gRPC will expose it. If you build blocks from transactions or account updates, group them by slot and bank id, keep the candidate that reached confirmed and discard others. The ids are node-local, so align blocks across providers by blockhash only. The four legacy Geyser callbacks become deprecated in favor of bank-scoped ones.
• Ticks and block footer. PoH ticks will disappear from the shred stream. Alpenglow blocks start with a BlockHeader marker and will end with a versioned footer (SIMD-0307) containing the producer timestamp, a client user-agent string and the leader's latest finalization certificate. The footers are accessible via a gRPC opt-in filter, but are not accessible via JSON-RPC yet.
• Clock sysvar. The layout will be the same, but the unix_timestamp will become set by the leader in a bounded range, not derived from a stake-weighted median of votes. Use it as an approximation.
• Blockhash expiration. Slots still exist, and the 150-slot window will remain the same, corresponding to about 32 seconds at current slot timing. Fetch blockhashes at confirmed or higher, as a hash of a vote-only block that will be rolled back during the migration is useless.
• Yellowstone gRPC. The plugin release for Alpenglow is v16.0.0-rc10+solana.4.3.0. Old clients will continue streaming but will not be able to see bank_id and footers.
• Migration day for bots. Expect one or two slots of vote-only blocks somewhere near the boundary, followed by a small break in the slot numbering sequence. Read at confirmed through that window, and hold back from the activation slot until the genesis certificate appears if you are conservative. Jito’s BAM nodes will go into maintenance mode during the transition.

Requirements for Validators. If you operate a validator, here are the three requirements you need to satisfy: operate a client based on Agave 4.3.0, since Firedancer can’t help you through the transition; register a BLS key and confirm it with solana vote-account; keep the vote account balance at the rent-exempt minimum plus 0.8 SOL before epoch 1064, with a refill plan. Otherwise, you’ll be left outside the admitted set and earn nothing until you sort it out.

Things That Alpenglow Does Not Do

• It does not improve throughput. “100 times improvement” is about finality latency, not block limits, execution, and compute budget.
• It did not cut the slot time. The transition from 400 ms to 200 ms was SIMD-0525, implemented in four phases from August to October, unrelated to Alpenglow.
• It does not eliminate MEV. The window from block visibility to finality narrows to around 150 ms, thus squeezing the latency arbitrage space, but it does not change the block building incentives.
• It does not bring in slashing, Rotor, or fast leader handover.
• It is not quantum-resistant. There is an experimental quantum-resistant hash-signature scheme called Quantumglow, with no plans on the schedule yet.

Implications for Building on OrbitFlare

As we run RPC, WebSocket, Yellowstone gRPC, Jetstream, and Shredstream, all the above features land on our infrastructure stack and on yours.

RPC and WebSocket users will benefit the most for free. Once getAgGenesisCert starts returning a certificate on mainnet, the guaranteed finalized state will come in a sub-second timeframe, and your signature status flow will respond even faster. Do not switch to finalized prematurely, and do reset any alerts about transaction counts. The gap described in our commitment levels explainer between confirmed and finalized is going away.

Yellowstone gRPC and Jetstream users should implement bank_id processing mentioned above if they build blocks from the transaction-level data and upgrade to the Alpenglow client release prior to activation day. For Jetstream users who act on decoded transactions at processed, their logic will remain the same, but the window where that data is ahead of finality will become shorter, from seconds to about 150 ms.

Shredstream users will be impacted the least as Turbine will stay, and so will shreds. Ticks will disappear, blocks will acquire a header marker and a footer, and under SIMD-0337 the FEC sets will be fixed at 32 data shreds plus 32 coding shreds. Rotor, when it ships, is the change that touches the propagation path, and our Shredstream piece covers how the current one works.

In case you are uncertain about your category, contact us in the OrbitFlare Discord channel prior to activation rather than after.

The Short Version

Alpenglow is a protocol with published proofs, a fault model that is worse for one particular type of attacker, but better for all others, and a migration that cannot lose user transactions or leave the chain between two engines. The primary risk on 21 October is not about the protocol itself; it is about ensuring that all validators run a single client family for the transition, and about one sixth of stake has to move before then. If the transition experience repeats the testnet and devnet one, then the transition will take a few hundred milliseconds, and Solana will wake up with 150 ms finality and votes off the chain.

---

OrbitFlare is a Solana infrastructure layer providing RPC, WebSocket, Yellowstone gRPC, Jetstream shred-decoded streaming, and Shredstream services.

Resources

1. Solana Alpenglow Consensus white paper v1.2 (Kniep, Sliwinski, Wattenhofer, Anza)
2. SIMD-0326: Alpenglow
3. SIMD-0384: Alpenglow Migration
4. Solana Foundation upgrade page: Alpenglow
5. Alpenglow operator documentation (Anza docs)
6. Alpenglow on Mainnet: What to Update (Triton One)