Alpenglow: Solana's New Consensus Mechanism Explained
Anza replaces TowerBFT and Proof-of-History with Alpenglow. What Votor and Rotor are, how block finality drops from 12.8 seconds to 150 milliseconds, and what Constellation contributes as a complementary proposal.
Solana is getting the biggest upgrade in its history — and it concerns the question of how thousands of computers reach agreement, in milliseconds, on what just happened.
In plain terms: Imagine your club needs to vote, within 5 minutes of a match, whether the last goal counted. Previously all 1,000 members had to vote one after another — taking nearly 13 seconds. With Alpenglow everyone votes simultaneously: once 80% raise their hands, the decision is valid — in 150 milliseconds, less time than it takes to blink. And even if 40% of members are temporarily unreachable, the club keeps running — as long as no more than 20% are actively sabotaging. Alpenglow brings Solana as close as physics allows to the speed of light across the network.
Core Idea
Alpenglow is Solana’s new consensus mechanism, published by Anza in May 2025. It replaces the existing core components TowerBFT and Proof-of-History with two new ones: Votor handles voting and finalization logic, Rotor handles data distribution. Block finality drops in simulation from roughly 12.8 seconds to about 150 milliseconds. The network stays operational as long as no more than 20 percent are adversarial and 20 percent unresponsive (“20+20” resilience). Separately, Helius Research has proposed Constellation for the block-construction layer — the two approaches target different layers and can coexist.
Overview
Solana’s core protocol is getting its largest rework since the 2020 mainnet launch. Anza, one of the two main validator-client developers, published the whitepaper for Alpenglow in May 2025 — a completely new consensus mechanism replacing TowerBFT and Proof-of-History. In parallel, the Helius Research team has presented Constellation as a complementary proposal for block construction.
This article explains what Alpenglow is, which components it replaces, how Votor and Rotor work together, and what role Constellation could play in the further evolution.
No financial advice. This article describes technical protocol changes.
What Alpenglow Replaces
Until Alpenglow, Solana’s consensus rests on two pillars:
TowerBFT is the voting and block-finalization logic. Validators vote on every slot; a block is considered final only after a certain number of confirmed votes. TowerBFT works but is latency-heavy: real finality takes around 12.8 seconds on average, according to Anza.
Proof-of-History (PoH) is Solana’s verifiable timestamp layer. PoH produces a continuous hash chain that functions as a cryptographic clock. Validators can agree on the order of events without additional communication rounds. PoH was historically a key performance lever for Solana, but costs compute on every validator.
Both components disappear with Alpenglow. Anza describes this in their Alpenglow whitepaper blog post: “When moving to Alpenglow, we say goodbye to a number of legacy components of the core protocol, in particular, TowerBFT and Proof-of-History.”
In their place come two new components.
Votor: The New Voting Layer
Votor (the new voting path) replaces TowerBFT and handles the collection of validator votes and block finalization.
The central innovation: Votor has two integrated voting modes running in parallel.
- Fast mode (1 round): when at least 80 percent of stake actively participates, Votor finalizes a block in a single voting round.
- Fallback mode (2 rounds): when only 60 percent of stake responds, Votor runs across two voting rounds.
Both modes operate simultaneously. The one that reaches its quorum first wins — finalization therefore happens as fast as possible, without the network having to decide upfront which mode is active.
Instead of the previous gossip protocol for vote propagation, Alpenglow uses a more direct communication primitive. This reduces the number of network hops and thereby total latency.
Rotor: The New Data Distribution
Rotor (the new data-distribution layer) is the evolution of Turbine (previous block-propagation mechanism), Solana’s previous data-dissemination layer.
Turbine breaks each block into many small erasure-code fragments (error-correcting data shards) and distributes them across a tree of relay nodes to all validators. Each node contributes bandwidth proportional to its stake. This architecture has from the start allowed Solana to produce large blocks without a leader bottleneck.
Rotor keeps this core principle — erasure codes plus stake-proportional bandwidth — and shortens the topology. Instead of a multi-layered relay tree, Rotor uses a single relay layer. This reduces the number of network hops, and Anza additionally describes a new selection logic for relay nodes that, according to the whitepaper, improves resilience under unreliable network conditions.
The Latency Numbers
Anza has published latency simulations in the whitepaper. The key points:
| Phase | TowerBFT (current) | Alpenglow (new) |
|---|---|---|
| Block finality (median) | ~12.8 seconds | ~150 milliseconds |
| Best-case finality | (not applicable) | ~100 milliseconds |
| Voting rounds | many, sequential | 1 (fast path) or 2 (fallback) |
| Data distribution | Turbine (multi-hop tree) | Rotor (single-hop relay) |
The simulations were, according to Anza, run with the current mainnet stake distribution and without additional computation overhead. A key finding: the natural lower bound of any finalization latency is the geographic network latency itself. If a node is 100 milliseconds away from the leader’s region, no consensus protocol can finalize there faster than 100 milliseconds.
Alpenglow is therefore not “magically fast” — it approaches the physical lower bound of the network, rather than adding extra protocol latency on top.
The “20+20” Resilience
Classical Byzantine-fault-tolerance protocols (protocols designed to handle deliberately malicious participants) typically tolerate up to one third of adversarial stake. Alpenglow defines a more differentiated threshold:
- up to 20 percent adversarial stake (validators showing active misbehavior)
- plus up to 20 percent non-responsive stake (validators that are offline or delayed without actively attacking)
This separation is relevant because in practice the most common form of stake loss is temporary unreachability, not active attack. Alpenglow can therefore maintain block production even when 40 percent of the network fails for various reasons — as long as the actively-adversarial share stays below 20 percent.
Constellation: Complementary Proposal by Helius Research
While Alpenglow concerns the consensus layer, Constellation addresses a different layer: block construction.
Helius Research describes Constellation in a detailed research post as the first formal protocol-level proposal for Multiple Concurrent Proposers (MCP) on a production blockchain.
The model: instead of a single leader deciding alone which transactions enter a block, around 16 proposers work in parallel on a 50-millisecond cycle. These proposers assemble transactions into erasure-coded segments (“pslices”) and distribute them to roughly 256 attesters. The attesters cryptographically sign which transaction sets they observed.
The property Constellation promises: selective censorship resistance (no proposer can quietly exclude individual transactions). Either all fee-competitive transactions in a cycle are included, or none are. A leader cannot selectively exclude individual transactions without producing a block that the network will reject.
Helius explicitly points out open problems in the post. Two are especially relevant:
- Content-visible ordering remains unsolved. Transactions are visible to all proposers on receipt — the multi-proposer architecture may actually widen this attack surface.
- Time-based latency games are described as unpunishable under the current design.
Constellation is a proposal, not a finalized protocol. Anza and the Solana Foundation have not signaled official adoption yet.
How Alpenglow and Constellation Fit Together
Both proposals address different layers of the Solana stack:
- Alpenglow changes how validators agree on finalized blocks (consensus layer).
- Constellation changes who assembles blocks in the first place (block-construction layer).
Technically they can coexist. Alpenglow finalizes blocks regardless of whether they came from a single leader or from multiple concurrent proposers. Alpenglow is currently in the whitepaper-to-implementation phase. Constellation is research-stage.
Implementation Status
Anza has published the Alpenglow whitepaper in two versions:
- Alpenglow Whitepaper v1.0 — May 2025, original release
- Alpenglow Whitepaper v1.1 — July 2025, revised version with additional correctness proofs and simulations
Mainnet migration is a multi-stage process. A concrete public timeline for full mainnet activation has not been provided in the blog post. Observers typically track rollout steps via validator-client releases (Agave, Firedancer) and SIMD documents.
Constellation is in research stage. Helius Research notes that further iterations and a formal SIMD process would be needed before implementation.
What Changes for Different Roles
Plain reporting of the documented effects from the whitepaper and the Helius post:
Validators: modified software requirements for Votor (new voting path) and Rotor (new relay selection). The “20+20” resilience allows higher tolerance against temporary outages. Constellation would, if implemented, introduce new roles (proposer, attester) in addition to the validator role.
Application developers: sub-second finality changes user-experience expectations for DeFi, trading, games, and real-time applications. What previously relied on “optimistic confirmation” can in the future wait for real finality without breaking user experience.
End users and wallet operators: no direct actions required. The changes happen at the consensus level and are transparent to wallets and end users.
What This Means for You
Alpenglow is not yet live on mainnet — it is currently moving from whitepaper to implementation. When it does arrive, nothing changes visibly for end users or wallet holders: no migration, no new address, no manual action required. The improvement happens under the hood. Alpenglow matters most for anyone watching Solana as a platform: sub-second finality changes what becomes technically possible — faster DeFi settlement, real-time applications, less reliance on optimistic confirmations. Whether and when Alpenglow activates can be tracked through validator-client releases and SIMD documents.
Want to navigate Solana with confidence? This article covers the concept. For the step-by-step path — wallet setup, security, staking, DeFi, and taxes — see the Solana Guide.
Sources
- Anza Blog — Alpenglow: A New Consensus for Solana, May 19, 2025, authors Quentin Kniep, Kobi Sliwinski, Roger Wattenhofer
- Alpenglow Whitepaper v1.0 — PDF, May 19, 2025
- Alpenglow Whitepaper v1.1 — PDF, July 22, 2025
- Helius Research — Constellation: A Proposal For MCP on Solana
- Solana Improvement Documents — SIMD repository on GitHub for official protocol proposals
Related SolanaHub Content:
Related glossary terms: