Alpenglow: The Game-Changing Revolution for Solana (SOL)

What is Alpenglow?

Alpenglow is a new consensus protocol proposal for Solana. Officially introduced at the Solana Accelerate conference in New York on Monday, May 19, Alpenglow is being developed by Anza, a research and development entity focused on Solana.

Anza is notably the team behind Agave, Solana’s main validator client, as well as several tools and critical infrastructure upgrades to the network over the past few years.

→ Watch the Alpenglow presentation at Solana Accelerate, led by Roger Wattenhofer, Head of Research at Anza.

Alpenglow’s goal is to offer an alternative to Solana’s current consensus mechanism (Tower BFT and Proof of History) to improve network performance, reduce block latency and finality, and more broadly, simplify the protocol.

The proposal was formalized in a whitepaper published on May 19, and is part of a broader overhaul of the Solana stack built around three complementary components, which we will explore in this research:

• Alpenglow (the new consensus),
• Votor (the voting engine),
• Rotor (successor to Turbine for block propagation).

With Alpenglow, Anza’s ambition is clear: to make Solana not only the fastest network, but also one of the most robust—even under extreme load.

> “We believe that the release of Alpenglow will be a turning point for Solana. Alpenglow is not only a new consensus protocol, but the biggest change to Solana’s core protocol since, well, ever.”

---

Current Technical Context of Solana

Since its launch, Solana has relied on a consensus protocol based on two mechanisms: Proof of History (PoH) and Tower BFT. Here is a quick reminder of how they work:

• Proof of History (PoH) is a cryptographic function (a Verifiable Delay Function) that provides a timestamping mechanism within Solana—a verifiable sequence of timestamps that allows validators to coordinate efficiently without having to resynchronize for each block.
• Tower BFT is a consensus protocol that leverages the PoH clock to synchronize validators. Validators “lock in” their decisions over time in order to rapidly converge toward a single decision.

This design enables Solana to achieve very high throughput (several thousand transactions per second in production), but it also comes with some significant trade-offs:

• Long finality: Although blocks are produced quickly (around 400 ms), the finality (i.e., the time between block creation and the guarantee that it won’t be reverted) is around 12 seconds.
• Protocol complexity: Tower BFT relies on validators accumulating votes across epochs, which requires them to maintain an accurate memory of their past votes over time. This increases code complexity and makes the protocol harder to manage.

While this architecture has made Solana one of the most performant Layer 1s in terms of raw throughput (though some newer networks now outperform it), it has come at the cost of operational complexity and non-deterministic finality (which cannot be precisely anticipated).

---

What Alpenglow Proposes

Alpenglow is a complete redesign of Solana's consensus mechanism. Its goal is to drastically reduce block finality latency while simplifying the protocol's architecture to make it more intuitive, more secure, and more robust against failures.

This proposal introduces a new consensus approach and brings two key components: Votor and Rotor, which replace Tower BFT and Turbine respectively—the mechanisms previously used for consensus and block propagation on Solana.

1- or 2-Round Finality

At the core of Alpenglow lies a faster and more deterministic finality mechanism. Rather than relying on an accumulation of time-locked votes (as in Tower BFT), Alpenglow uses a much simpler logic:

• If a block gets 40% of the votes, it is considered safe (even a fork receiving the same number of votes will be finalized).
• If it reaches 60%, it is finalized in the next round.
• If it reaches 80%, it is finalized immediately.

This system allows each validator to determine whether a block is finalized based solely on the votes it has already received, without needing to wait for multiple voting cycles or to track complex historical vote records. This drastically reduces the protocol's complexity.

More importantly, it dramatically lowers the latency between block creation and finality. What used to take around 12 seconds has now been reduced to roughly 150 milliseconds (median), as illustrated by these simulations shared by Anza:

In the infographic, it's important to note the following:

• The light blue bars represent network latency. Most Solana nodes currently have around 50 ms latency, but some exceed 200 ms. Nevertheless, the fastest node determines total network latency, which is why the light blue curve rises as the percentage of reached validators increases.
• The pink bars represent the time needed for a node to receive votes from more than 60% of validators.
• The dark blue bars represent the execution time of Rotor (covered in the next section).
• The purple bars show block finalization time (often confused with block finality itself).

These improvements are critical for several reasons. By boosting network performance and, more importantly, by providing clear guarantees on transaction finality for developers, Alpenglow enables a whole new class of applications that require these kinds of performance metrics.

Votor: A New Finalization Logic

Votor is the new voting engine introduced by Alpenglow. It replaces the Tower BFT mechanism that previously handled block finalization on Solana. The goal is to deeply simplify how validators converge on a finalized block by introducing a less complex voting structure.

Votor radically simplifies Tower BFT by introducing a stateless, explicit voting structure. It is inspired by the Streamlet protocol, a modern Byzantine consensus algorithm designed for fast finality with minimal complexity.

Here are the core principles of how Votor works:

• Consensus proceeds in rounds, meaning voting cycles among validators, each aiming to finalize a candidate block (instead of accumulating votes over time, validators send their votes in each round).
• In each round, validators emit explicit votes for a given block based solely on the current network state (not on any historical locks).
• A block is finalized at the end of a round if it receives 80% of the votes (immediate finality in one round), 60% (finality in two rounds), or exceeds 40% (it is broadcast but not yet finalized).

This logic allows validators to make local decisions, meaning they can determine which block to vote for or finalize using only real-time information, without maintaining persistent locks or computing a complex vote history.

In summary, Votor brings three major benefits:

• Fast and deterministic finality in one or two rounds, with clear guarantees.
• Reduced software complexity by removing dependencies on historical state.
• Greater resilience in the face of forks or unexpected events, thanks to a more intuitive and verifiable protocol.

Rotor: More Robust and Deterministic Propagation

Rotor is the new block propagation protocol introduced by Alpenglow. It replaces Turbine, the original block propagation mechanism used since Solana's inception. Rotor aims to improve block dissemination efficiency by making network behavior more predictable.

Turbine was based on a gossip-inspired approach, where blocks were transmitted in fragments through successive layers of randomly selected nodes. This system was bandwidth-efficient but came with certain risks (such as inconsistencies when some fragments were lost).

Rotor replaces this non-deterministic distribution (i.e. randomly broadcasting fragments) with an explicitly defined propagation scheme. Each block is propagated according to a pre-established structure derived from a dissemination tree, in which each node knows its target peers and relays blocks in a defined order.

Here are the key principles of Rotor's design:

• The propagation structure is deterministic, allowing for predictable and controlled block dissemination.
• Each block is encapsulated in a validator’s vote, ensuring that propagation and validation are tightly connected.
• The protocol supports asynchronous execution, enabling multiple rounds to be handled simultaneously and reducing confirmation delays even under degraded network conditions.

→ For further details, see Anza’s official blog post introducing Alpenglow

---

Comparative study of Solana with Alpenglow

---

Outlook and Community Reception

The announcement of Alpenglow was met with overwhelmingly positive feedback, particularly from key figures in the Solana ecosystem. Anatoly Yakovenko, co-founder of Solana Labs, praised the elegance and simplicity of the new consensus model, stating that it finally meets the two fundamental requirements for a high-performance system:

“I got nearly everything wrong about consensus, except the important parts: 1) it can’t be in the way of block producers utilizing 100% of the bandwidth 100% of the time. 2) users need some deterministic finality in one round (2-delta)”

This view is shared by several Solana developers, who see the conceptual clarity of the new protocol as a turning point for the ecosystem’s future. As Anatoly also put it:

“There are no words in human languages to express how core engineering feels about dealing with no more than 2 blocks of state transitions at a time instead of up to an epoch of full of unconfirmed blocks.”

At the same time, some concerns have been raised about the rollout timeline, which is expected to extend through the end of 2025. This echoes familiar debates from the Ethereum community, where it took over two years of preparation to complete The Merge, followed by months of work to implement Pectra.

Much like those major milestones for Ethereum, Alpenglow is not a simple update: it is a full redesign of several of the protocol’s most critical components. It’s only natural that such a transformation would require time.

It’s also worth noting that network resilience does not depend solely on the consensus protocol, but also on validator client diversity. Currently, Solana relies primarily on a single client, Agave, developed by Anza. For this reason, the arrival of Firedancer — an alternative validator client built by Jump Crypto — is increasingly anticipated.

Note: Some have voiced concerns that this new development from Anza might delay progress on Firedancer. According to Anatoly, however, that won’t be the case.

→ Read our introduction to Firedancer:

---

The End of Vote Fees and a New Economic Model for Solana?

Among the many implications of Alpenglow, one of the most impactful for the Solana ecosystem is the removal of “vote fees.” Until now, each block on Solana required validators to submit a vote transaction to confirm their participation in the consensus.

These validator vote transactions represented a significant operational cost, especially for smaller validators — up to 1.1 SOL per day, or more than 400 SOL per year, just to be eligible to vote.

This is one of the main reasons why the barrier to entry for becoming a validator on Solana was so high. The estimated breakeven threshold is around 4,850 SOL, or approximately $825,000.

With Alpenglow, this vote fee mechanism is removed. Voting is now handled via aggregated BLS signatures and is natively integrated into the protocol layer. In other words, validators will no longer need to submit a vote transaction for each block.

This change is expected to cut validator operating costs by about 80%, according to early estimates. Practically speaking, the breakeven threshold for running a validator could drop from 4,850 SOL to around 450 SOL, making it economically viable for more independent validators to join the network.

More importantly, this change fundamentally alters the economics of validator operations on Solana. Previously, small validators were heavily reliant on SOL inflation and the associated rewards to cover their costs — especially vote fees. Removing these fees reduces dependence on inflation and improves long-term network sustainability.

It could also revive proposals recently explored by the Solana teams. In March 2025, proposal SIMD-228 — which aimed to reduce SOL inflation — was rejected. While most large validators voted “yes,” smaller validators opposed it, fearing their profitability would be severely impacted.

→ Read our article on SIMD-228:

---

Key Takeaways

With Alpenglow, Solana is undertaking a full redesign of its consensus mechanism. In short, the goal is twofold: to drastically improve performance and simplify the protocol’s architecture.

To put it simply, the most significant improvement is the reduction of block finality time from around 12 seconds to under 250 ms, with a median of approximately 150 ms — and in the best case, performances of 100 ms according to Anza’s internal simulations.

This means that beyond becoming the blockchain with the lowest latency, Solana can now rival the top Web2 infrastructures. It opens the door to a whole new wave of applications that require near-instant finality — in finance, gaming, and more.

Ultimately, the real breakthrough of Alpenglow is positioning Solana not just as a fast blockchain, but as a platform that can compete with Web2 standards without compromising on decentralization or security.