Alpenglow: Solana's Great Consensus Rewrite

Thank you to Brady, Wen Xu, Kobi, Quentin Kniep, Roger Wattenhofer, and Anatoly Yakovenko for reviewing earlier drafts of this article.

Actionable Insights 

• Alpenglow's headline benefit for Solana is a 100x reduction in time to transaction finality. Depending on a validator's geographic location, this will fall from 12.8 seconds to 100-150ms, allowing Solana to become competitive with more centralized Web2 infrastructure and enabling real-time applications.
• Alpenglow simplifies consensus by eliminating several of Solana’s legacy components, including Proof of History, Tower BFT, and gossip-based vote propagation. In place of Proof of History, Alpenglow introduces a fixed block time of 400ms, which is not the same as having a globally synchronized block, to coordinate timing across the network.
• The protocol is structured around two foundational components: Rotor, an improved block propagation protocol that extends and refines Solana’s existing Turbine architecture; and Votor, a new voting mechanism that replaces Tower BFT, Proof of History, and the use of gossip for vote propagation.
• All consensus activity moves off-chain—vote certificates will still be anchored on-chain, replacing per-slot vote transactions with a lightweight BLS certificate system. This change eliminates voting fees as we know it today, which have historically been the primary operational cost for validators, significantly improving validator economics for smaller operators. The exact economic model is still being finalized.
• Alpenglow offers a “20+20” resilience model: it maintains safety if up to 20% of stake is controlled by adversaries, and liveness if an additional, separate 20% of stake is offline or unresponsive. This allows the protocol to tolerate both hostile and unstable network conditions.
• Votor uses a two-tiered, concurrent voting system for consensus. In the Fast-Finalization path, if a block receives ≥80% stake approval in the first round, it is immediately finalized with a Fast-Finalization Certificate. In the Slow-Finalization path, a second round begins as soon as a block receives ≥60% stake approval. If this round reaches ≥60% approval, the block is finalized with a Finalized Certificate.
• Unlike Turbine, which relies on a multi-layer tree structure with a fanout of 200, Rotor uses a single-hop model where relay nodes handle shred dissemination. Each shred is transmitted as a single erasure-coded packet, and Rotor’s design is natively compatible with multicast systems such as DoubleZero. Note that Rotor will most likely be a separate SIMD compared to Votor.
• Alpenglow is currently expected to roll out to Solana mainnet by early next year. A reference implementation of the protocol can be found on Github.

Introduction

The Alpenglow consensus algorithm represents the most significant overhaul of Solana’s core protocol to date. Drawing on the latest advances in blockchain research, it fundamentally rearchitects how consensus is achieved across the network.

Alpenglow is the work of Anza’s new research division, led by Professor Roger Wattenhofer of ETH Zurich, one of the world’s top-ranked computer science institutions. A leading authority in distributed systems, Professor Wattenhofer previously co-authored the 2024 paper Halting the Solana Blockchain with Epsilon Stake, which uncovered possible liveness vulnerabilities in Solana’s current consensus protocol. Professor Wattenhofer is joined at Anza by his former PhD students, Kobi Sliwinski and Quentin Kniep.

The team’s task was to redesign Solana’s consensus algorithm to be more performant and provably correct, while preserving its Turbine-based architecture. Alpenglow incorporates many of the latest advances in distributed systems research, particularly in handling adversarial network behavior.

The name Alpenglow is derived from the German word Alpenglühen, meaning “Alps glow.” It refers to the striking light seen on mountain peaks at sunrise or sunset and is a nod to the protocol’s Swiss origins.

What are the benefits of Alpenglow?

Below is a high-level summary of the key benefits Alpenglow is expected to bring. Each of these will be explored in greater depth throughout the rest of the article.

Faster Finality

Alpenglow's headline benefit for Solana is a 100x reduction in time to transaction finality, or how quickly user transactions are rooted on a blockchain network. Depending on a validator's geographic location, this will fall from 12.8 seconds to 100-150ms, allowing Solana to become competitive with more centralized Web2 infrastructure and enabling real-time applications.

• Current Solana Finality: 12.8 seconds 
• Current Solana Optimistic Confirmation: 500-600 milliseconds
• Alpenglow Finality: 150 milliseconds (median value)*
• Fastest Competition Finality: 400 milliseconds (self-reported)

*fluctuates based on geography and cluster distribution.

No More Vote Transactions

With Alpenglow, all consensus activity happens off-chain. This will relieve load on the transaction processing unit (TPU) and replay, which will no longer be required to process vote transactions.

Alpenglow will also significantly improve the economics for smaller validators. Vote transaction fees are the largest operational expense for validators. By eliminating these fees through off-chain voting, participation costs are dramatically reduced, making it more feasible for smaller validators to operate and lowering the barrier to entry for contributing to network security.

Additional advantages include simplified commitment logic and slower ledger growth, since vote transactions no longer consume blockspace or inflate the ledger size.

This shift also has the added benefit of removing ambiguity over Solana’s transactions per second (TPS) metrics. Today, TPS is often reported in two ways: total TPS, which includes vote transactions, and true TPS, which counts only non-vote transactions.

A More Streamlined Protocol

Alpenglow streamlines the process of reaching consensus by removing several of Solana’s legacy components, including Proof of History, Tower BFT, and the use of gossip for vote propagation. While it incorporates cutting-edge advancements from modern blockchain research, it does so without introducing unnecessary complexity.

Alpenglow’s Votor and Rotor lay the foundation for future upgrades, such as asynchronous execution and multiple concurrent leaders (MCL), positioning Solana well for further performance gains and protocol evolution.

What is Solana’s current consensus mechanism?

Proof of History

Proof of History (PoH) is not a consensus algorithm. Rather, it is a tool that aids in achieving consensus. The confusion likely arises due to its nomenclature—”Proof of X” which implies the object in reference is a consensus algorithm for those familiar with Proof of Work and Proof of Stake. It is more beneficial to consider it a “pre-consensus” algorithm that streamlines consensus via efficient transaction processing.

At a high level, PoH is a decentralized clock used to prove time in an adversarial network. More formally, PoH is a cryptographic time-stamping function that allows nodes to agree on an order of events without talking to one another. It uses a sequential preimage-resistant hash function to create a chain of hashes. Leaders apply timestamps to blocks using these hashes to prove some duration of time has passed. Since all hashes are chained, PoH provides a historical record proving data existed at a specific point in time. 

This approach differs from other chains, which often decide block ordering during consensus and then add timestamps thereafter. Instead, on Solana, a cryptographically verifiable clock is built first, transactions are streamed against that clock, and consensus verifies the pre-ordered log of transactions. The hash-chaining makes the time ordering indisputable. 

Tower BFT

Tower BFT operates after shreds (i.e., partial blocks) have been propagated to other validators and the network has replayed them to determine whether that block becomes part of the ledger. Conceptually, it’s a pBFT-like consensus algorithm, designed to take advantage of Proof of History’s network-wide clock. Instead of needing a synchronous consensus round for each slot, validators pre-commit to future slots based on the Proof of History sequence they have already observed, enabling continuous block production.

Validators cast one vote transaction per slot, signed by their vote account. Votes on a given fork incur a lockout (i.e., a timeout) for that fork. A lockout is a designated period of slots in which a validator cannot vote on another fork. The idea is to force validators to commit to one fork and exponentially increase the lockout if they want to switch forks. Each vote carries a lock-out counter that doubles every time the validator votes on a descendant slot, creating a “vote tower” of commitments. Thus, if a validator votes for block X, then they are locked out from voting on any conflicting fork for an exponentially increasing number of future slots (e.g., 1, 2, 4, 8…). Breaking the lockout can be proven and punishable, although slashing has yet to hit mainnet.

Solana achieves two tiers of finality under Tower BFT: optimistic confirmation and deterministic finality. 

When a new block is produced and ≥66% of stake votes for it, the block is recognized as part of the leading, or canonical, fork. This is referred to as optimistic confirmation, as the block is marked with a commitment level of “confirmed” as soon as a supermajority has voted on it. Optimistic confirmation was introduced in v1.3 of the Solana Labs (now Agave) client to improve UX by treating a block as finalized before it’s formally finalized.

Since Solana’s genesis block, no optimistically confirmed block has ever been rolled back. To do so would require at least one-third of total stake to reveal a conflicting fork after 66% had already voted honestly. Equivalently, once a block’s optimistic confirmation count reaches ~87% of stake, an adversary would need ≥20% of that same stake to double-sign, which is a provably slashable act. While not absolute finality in a strict consensus-theoretic sense, optimistic confirmation provides strong guarantees in practice. These blocks can be treated as finalized for nearly all use cases—hence why Solana’s finality is commonly cited as 500–600 milliseconds for practical purposes.

True deterministic finality requires a block to achieve maximum lockout in the vote tower, which amounts to 32 stacked votes confirming it. That is, the block must have 32 more blocks built on top of it to be considered “finalized” or rooted in the network. The time for a block to reach deterministic finality is ~12.8 seconds, given the 32-slot requirement and ~0.4 second slot times. Deterministic finality is achieved once the lockout vote depth makes a rollback impossible.

What are the limitations of Solana’s current consensus mechanism?

Proof of History and Tower BFT helped Solana achieve high throughput and quick, optimistic confirmations. However, this design has several limitations regarding cost, latency, liveness, and validator operations.

High Voting Overhead and Cost

Every validator must continuously vote on each slot to contribute to consensus. Votes are transactions that interact with the vote program, consume network resources, and pay fees. 

Approximately three-quarters of transactions on Solana are vote transactions, taking up a significant network overhead while incurring a real cost for validators each slot. This unnecessary reliance on incessant voting introduces high overhead and costs that scale with the number of slots processed and the number of validators in the cluster. 

Finality Latency

While optimistic confirmation is fast, deterministic finality is not. ~12.8 seconds is slow compared to newer consensus protocols such as Sui’s Mysticeti, which boasts a time to finality of ~500ms. This creates issues for applications, such as exchanges, that require absolute certainty for their operations. In practice, users trust confirmed blocks. However, the network still needs to maintain long fork histories in the case of potential minor re-orgs before finalization. 

The gap between optimistic confirmation and deterministic latency is a trade-off: Tower BFT favors liveness with a short window of fork contingency at the cost of slower finality. Even without any sort of attacks or consensus bugs, ~12.8 second finality pales in comparison with fast finality chains and existing Web2 infrastructure.

Liveness and Network Partition Tolerance

Tower BFT requires a supermajority of validators to be online and responsive to confirm and finalize new blocks. Consensus can stall if more than one-third of the stake is offline or the network is severely partitioned. Solana may still produce blocks, preferring liveness, but the network may fail to reach the voting threshold to optimistically confirm these blocks. In the worst case, as seen in Solana's recent outages, validators stuck waiting for votes or unable to process the optimistic fork could trigger a network halt requiring a coordinated restart.

This is a classical limitation of BFT consensus. Solana has no built-in allowance for large chunks of validators being temporarily unresponsive. So, Solana’s liveness suffered during extreme conditions because the protocol could not gracefully handle falling below the supermajority threshold for consensus. Tower BFT had to keep producing blocks, with less than 60% of stake online. This means that those blocks could never reach optimistic confirmation and may be rolled back.

Validator Operational Complexity

Tower BFT demands a lot from validators: constant vote transactions, robust networking, client upgrades, avoiding delinquencies, and persisting “tower state.” If a validator were to restart or lose its latest tower state, it risks casting a vote that violates a previous lockout commitment, resulting in a loss of voting credits.

The protocol’s dependence on Proof of History’s continuous hashing and gossip propagation for votes means validators work hard to keep up with Solana’s ~400ms slot time. Solana’s high hardware requirements, albeit lowering as time progresses, are also non-trivial. Moreover, regardless of stake, all validators must vote on every slot to maximize rewards, meaning smaller validators pay the same fees and have the same workload, for the most part, as larger ones. Since leader slots are assigned proportionally to stake, validators with more stake produce more blocks, thus collecting more of the vote fees paid by other validators. This creates a circular flow of value where vote fees effectively redistribute capital toward higher-staked validators.

Moreover, Solana’s current consensus mechanism makes duplicate-block replay immensely complex as clients need to manage multiple candidates for the same slot. Votor’s certificate system guarantees that each slot commits either a single hash or an explicit skip, making duplicate-block replay trivial.

It becomes apparent that Tower BFT's design, albeit innovative, results in a fair amount of validator operational complexity.

How Does Alpenglow Work?

Alpenglow is built around two core components:

• Rotor: an upgraded block propagation protocol, building on and enhancing the existing Turbine architecture.
• Votor: a new voting protocol that replaces Tower BFT, gossip-based vote propagation, and Proof of History for consensus participation.

In the following sections, we’ll explore these components in detail.

Rotor: New Data Dissemination Layer

Rotor is an enhanced block propagation protocol that builds on Solana’s existing Turbine design, with key improvements to efficiency and simplicity. Unlike Turbine, which uses a multi-layer tree structure with a fanout of 200, Rotor uses a single-hop model (2δ). 

Blocks are split into slices, and each slice is then encoded into multiple shreds using Reed-Solomon erasure codes. To ensure the authenticity of the shreds, the leader creates a Merkle tree of the shreds' hashes and signs the root. Each shred includes its path in this tree and the leader's signature.

Each shred is sent directly to a relay node. Relays then broadcast their shred to all nodes in the network, with the next leader being first. This one-layer approach reduces latency and simplifies the propagation path. It is also surprisingly fast:

Both the leader and the shred relays are selected through stake-weighted sampling, meaning each node is responsible for transmitting data in proportion to its stake. Because of the erasure coding, nodes only need to receive a subset of the shreds to reconstruct the original block slice.

A notable difference with Turbine is that Rotor transmits only a single erasure-coded version of each shred, eliminating the need to send separate data and recovery shreds as Turbine does. While redundancy (i.e., data expansion ratio) remains the same, this design eliminates any weird games related to forwarding data shreds, and ensures simplicity in the protocol design.

Rotor’s architecture is also compatible with multicast systems like DoubleZero, offering flexibility in how blocks are delivered. Since block propagation consumes significant bandwidth (currently, large validators approach 150,000 outbound packets per second), Rotor introduces a model where relays are rewarded for distributing data, aligning incentives to support the network’s performance.

The Alpenglow whitepaper does not define a concrete mechanism for calculating or distributing rewards. However, it notes that Rotor rewards should account for the bandwidth consumed, with nodes that relay more data expected to receive a larger share of rewards.

What is Blokstor?

Blokstor is where nodes store and manage the block data they receive from Rotor. More formally, Blokstor is a data structure that manages the storage of slices. When a shred is received, its contents are added to Blokstor if certain conditions are met, which include:

• Blokstor does not already contain a shred for those indices
• A valid leader signature
• A valid Merkle tree path

Blokstor emits an event "Block(slot(b), hash(b) hash(parent(b)))" when it receives the first complete block b for slot(b). Blokstor can also perform repair procedures to collect and store alternative blocks for the same slot. When a block becomes finalized, Blokstor must store only that block in the given slot.

Votor: New Voting and Finalization Engine

Votor is Aplenglow’s new voting and finalization engine, replacing Tower BFT for notarizing and finalizing blocks. It draws inspiration from the Simplex line of research for enhanced efficiency and simplicity and applies it to a Proof of Stake context. 

Simplex demonstrates that Byzantine agreement can be reached in a rotating leader Proof of Stake setting in one or two rounds with extremely small messages, provided there is a tight upper-bound on network delay. Votor takes the following ideas from Simplex:

• Dual quorum sizes
• Single-packet vote messages

At a high level, Votor ensures that for every slot, there is either a skip certificate, indicating that the slot was skipped, or some notarized block that builds upon the canonical chain of notarized blocks. For a block to be notarized, it must have a valid certificate. Rather than flooding gossip with votes, validators broadcast lightweight vote messages to a stake-weighted peer set as a sort of “direct-send” mesh, rather than traditional Solana gossip. Any node can aggregate these signatures into a certificate using the Boneh–Lynn–Shacham (BLS) signature scheme once a quorum is reached. This eliminates the need for per-slot vote transactions, as the aggregated certificate header is what gets anchored on-chain.

How does Votor’s voting mechanism work?

Votor uses a tiered, concurrent voting mechanism that is broken down into two voting paths:

• Fast-Finalization: If the proposed block receives ≥80% of stake approval in the first voting round, the block is immediately finalized and a Fast-Finalization Certificate is produced. This one-round finalization is possible because 80% of stake is well above the supermajority threshold, such that a second round of voting is not necessary for finalization.
• Slow-Finalization: If the first round of voting receives <80% of stake approval but ≥60%, Votor immediately starts a second round of voting. Once this second round of voting reaches ≥60% of stake approval, a Finalized Certificate is produced.

Both paths run concurrently, and the first path to meet its threshold finalizes the block. As soon as a leader finishes ingesting the parent block, it can start transmitting the next block while votes are still accumulating, so one block is produced every ~400ms, just as Solana’s old consensus ensured. This design ensures that if the first round fails to receive ≥80% of stake approval, Votor falls back to the second round of voting. It also ensures that two conflicting blocks cannot both reach finality because of the overlap in stake.

What is Votor’s Pool data structure?

The Pool is a data structure maintained by every node that acts as a local ledger of voting activity and certificate generation. It memoizes received votes for each slot and each node. When enough votes are received, a corresponding certificate is generated. When a newly received or self-constructed certificate is added to the Pool, it is broadcast to all other nodes. 

Although multiple validators may forge the certificate at almost the same time, they are all aggregating the same signature set for that certificate, so the byte-for-byte output is identical. The one exception is the fallback certificate, as there may be up to three distinct certifications that need to circulate. There are never more than four unique certificates across all types for a given slot, and each unique certificate is broadcasted only once. This approach prevents vote spamming while still letting any honest node build and share the certificate the moment the Pool shows a quorum.

Key Takeaways

Votes are streamed as single UDP packets to all validators, who memoize received votes for each slot and each node. The notarization and finality of a given block under Votor are determined by the following three conditions:

• ≥80% of stake approval in the first round of voting.
• ≥60% of stake approval in the first and second rounds of voting.
• The validator receives a valid certificate from another validator stating the block has been finalized.

No More Proof of History

Since Rotor propagates block data in one hop and Votor has an upper target latency of ~150ms (we cover this more in depth in the next section), there is no longer a need for a decentralized clock on Solana. Instead, a simple synchrony assumption is enough. Alpenglow replaces Proof of History with a global timeout constant of 400ms. This is the assumed maximum network delay between any two honest nodes under synchronous network conditions.

How does Votor’s timeout mechanism work?

In practice, the timeout system works as follows:

• Leader Window: The leader will be in charge of a four-slot window with Δblock ≈ 400ms per slot.
• Data Arrival or Timeout: The moment the parent block of a leader is notarized, each validator invokes their timeouts and pre-sets four deadlines—one per slot—at t = now + Δtimeout + slotIndex * Δblock, where Δblock ≈ 400ms. Note these timers are never reset and act as upper bounds. If a block’s shreds arrive in time, that slot is voted on with a NotarVote message, and the pending timeout becomes a no-op. However, if the time expires before any shreds arrive, the validator assumes the leader is dishonest or delinquent and issues a SkipVote.
• Certification: A Fast-Finalization or Finalized Certificate is produced for notarized blocks, as described above. A Skip Certificate can also be produced for skipped slots.

Alpenglow introduces a system wherein every validator measures timeouts locally and independently. Solana, therefore, does not need a single, hash-driven clock like Proof of History. Since messages are only a single UDP packet and Rotor is only a single hop, the 400ms bound is realistic without hashing. Validators will no longer need to grind hashes continuously, can vote against blocks without being subjected to lockouts, and alternative clients, such as Firedancer, won't be forced to replicate the Agave client’s Proof of History implementation.

Skipping Slots

Validators can also skip a slot by sending a SkipVote message. If ≥60% of stake casts a SkipVote message, a Skip Certificate is produced, and that slot is formally skipped. Skip votes carry the same reward weight as notarization votes, so there is no incentive for a validator to stay silent when the leader misbehaves. Note that this may change once the economic model for Alpenglow is finalized.

Validators send a SkipVote for a slot whenever they determine they cannot finalize a block for that slot. This could be due to hitting a timeout, missing a block, or producing an invalid or malformed block. If the first slot of a leader’s four-slot window triggers any one of those conditions, validators mark the entire window as bad such that the remaining slots in the window are iterated over and SkipVotes are issued for every slot that they haven’t already voted on. Thus, the whole four-slot window can collapse into one skip round. Each of these votes still applies to one slot, but because most validators do the same burst, all three pending slots reach the 60% threshold around the same time. This is to prevent the cluster from idling through three more empty slots while an offline leader times out.

Obviously, this leaves gaps in block production. However, the cadence of slots continues uninterrupted, thanks to these fast skip certificates. This simplifies fork choice and improves consistency since a skip certificate acts as a canonical “null block” for that slot, so all honest nodes adopt the skip as the outcome. Thus, there is no competing fork, and skips do not lead to persistent forks, allowing regular block production timing.

Validator Rewards

Validator rewards under Votor are based on participation in voting and certificate generation. Nodes that contribute to consensus by casting votes, either in favor (NotarVote) or against (SkipVote) a block, are rewarded equally. This encourages honest participation, ensuring nodes vote based on their own state rather than trying to predict or align with the majority.

An exact rewards implementation has not been specified at this time.

Alpenglow Performance Benchmarks and Simulation Results

Simulations by Anza show Alpenglow finalizes a block in roughly 100-150ms, depending on whether the Fast-Finalization or Fallback (i.e., slow-finalization) paths notarize the block. The Fast-Finalization path targets ~100ms latency, whereas the Fallback path targets ~150ms latency.

Latency Histogram

Network latency sets a fundamental lower bound for communication in any distributed system. For example, if the leader is located in New York and the majority of stake is in Europe, the median one-way latency for a node to send information to other network nodes can reach around 200 milliseconds. Latency is lower for geographically close nodes (e.g., those within the same data center or region) and significantly higher for nodes located in the Global South or other distant areas.

• Network: This is the network latency to send 1 bit to other nodes over the internet
• Rotor: How much slower Rotor is compared to this lower bound
• Notarization: Time taken to receive notarized votes from 60% of stake (can also do one more round of voting; once received, finality can begin)
• Finality: Finalization time

Alpenglow’s finality overall is 2x the lower bound. That is, consensus overhead is a 2x multiplier on the raw network floor. So, if the longest one-way hop between the leader and supermajority stake is, say, ~70ms (i.e., ~140ms RTT), fast-path finality should land in the 120-150ms range.

The latency histogram from Anza’s simulations shows that 65% of stake finalizes within 50ms of raw network latency. This means that most validators vote almost as soon as the data arrives.

The Zurich-leader histogram also suggests that the 400ms global timeout is a safe synchrony bound, but more testing will be required to further confirm this constant.

With Alpenglow, deterministic commitments sit well below any competing L1, bringing Solana’s on-chain experience much closer to those of traditional Web2 services.

Alpenglow Security and Fault-Tolerance Analysis

Alpenglow’s consensus is an improvement to traditional BFT consensus, which maintains resilience against adversaries that control up to 33% of the network’s stake. This is denoted as “3f + 1.” Alpenglow lowers these bounds to 20% of the network’s stake based on the 5f + 1 bound introduced by Martin and Alvisi in Fast Byzantine Consensus. It uses a “20+20” resilience model wherein security is split into two parts:

• Byzantine Faults ≤ 20%: Safety holds if, at most, 20% of the total stake is controlled by adversarial validators. This is a considerable amount of money in the billions of dollars, and would be easy to identify and punish (the social layer is the strongest layer, but even automated slashing should be possible, if desirable, as long as the attacker has ≤60% stake). Thus, an attacker risks losing their entire stake, making such attacks economically unviable.
• Non-Malicious Phenomena ≤ 20%: Liveness holds if, at most, 20% of the total stake, separate from the adversarial stake, is offline, crashed, or otherwise not participating in consensus. This includes network outages, misconfigurations, and software bugs. Thus, the network can continue finalizing blocks even if a significant minority of validators are unresponsive.

Safety

Safety is guaranteed provided the total adversarial stake ≤20%, and cannot prevent at least 60% honest participation on one fork. These conditions make it so any vote threshold that the protocol treats as final (i.e., one-round fast, two-round fallback) is high enough that a conflicting threshold on another fork cannot be obtained. If adversarial validators try to equivocate (i.e., vote for two different forks, or produce two different blocks in the same slot), honest nodes will eventually receive their conflicting signatures. This is easily identifiable and, ideally, in the future, will lead to punishable offences such as slashing. 

Moreover, if a leader tried to produce an invalid block, honest validators would simply refuse to vote for it. Alpenglow’s model of direct communication for voting makes it hard for a malicious actor to isolate or eclipse an honest node in stake, as they’ll eventually be exposed by the honest majority’s votes. At best, a malicious leader could force consensus into its slower path or cause a one-slot delay, but it cannot permanently stall or diverge the chain.

Liveness

Liveness is guaranteed under partial synchrony conditions so long as the fault thresholds are respected. This means that, after some network delay, honest validators will be able to communicate and gather ≥60% of stake on some block. If exactly 20% of total stake is offline, the fast path may still succeed if all remaining honest nodes vote. If a bit more than 20% of total stake is offline, the network will consistently fallback to the fallback path for a second round of voting. Finality is still guaranteed, albeit slower. Thus, benign failures mainly impact performance and not safety.

High Crash Resilience

Alpenglow is explicitly designed with high crash resilience in mind to handle harsh network conditions. That is, Alpenglow will continue to remain safe and operate in 20% malicious and 20% unresponsive stake scenarios. 

However, this is not a cure-all for any conceivable failure. Alpenglow is a significant improvement for Solana, but it does not entirely eliminate the risk of network halts or outages if its assumptions are violated. ≥60% of stake is required for new blocks to be produced, and ≥20% of stake acting maliciously could prevent consensus or cause a fault. Nonetheless, under the defined limits, Alpenglow guarantees safety and liveness within one or two rounds of voting.

Does removing Proof of History weaken security?

Albeit being fundamental to Solana’s current operation, removing Proof of History does not weaken security in any meaningful way. As mentioned earlier, the universal 400ms bound replaces the Proof of History hash-clock. Even if the network sees significant delays, Votor’s overlap in stake (i.e., ≥80% one-round and ≥60% + ≥60% two-round) prevents honest validators from approving two different forks.

It does, however, shift liveness guarantees as liveness does rely on the synchrony message—liveness will hold so long as honest messages arrive within this delay. Rotor’s one-hop data dissemination and single-packet votes mean latency stays well within the 400ms envelope, even under stress.

Overall, removing Proof of History will eliminate the reliance on continual hash grinding, thereby removing any hash-stalling attack vectors. As mentioned above, it also shifts the liveness guarantees. But, removing Proof of History does not weaken security in any meaningful way.

Key Takeaways

Alpenglow trades a slight reduction in Byzantine tolerance for sub-second deterministic finality, graceful handling of large benign outages, and easier identification of malicious validators. These takeaways can be summarized as follows:

• No two conflicting blocks can finalize unless ≥20% of stake double-signs, which is an action trivially provable and punishable.
• Solana will continue to finalize blocks so long as ≥60% of stake can communicate, even with the rest of the stake offline.
• Worst-case finality falls back to second-round voting with a target of ~150ms latency such that attacks degrade the chain’s speed before they threaten safety.
• The cost of breaching the 20% Byzantine limit is prohibitive, while smaller wrongdoings are detectable and punishable socially and economically, once slashing goes live on mainnet.

What is Alpenglow’s impact on validators?

Voting costs are the largest barrier to entry for running a Solana validator. There is no strict minimum amount of SOL required to run a validator. However, sending vote transactions each slot, which is necessary to partake in consensus, can cost up to ~1 SOL per day.

Alpenglow seeks to replace per-slot vote transactions with a compact certificate system that effectively removes voting fees as we know them today. Each validator would broadcast lightweight vote messages to all other nodes. Any node can aggregate those signatures into a certificate via the BLS signature scheme once a quorum is reached. Now that these votes are BLS aggregated, only the certificate header is anchored on-chain. In practice, this would erase the daily ~1 SOL per validator cost. 

As mentioned earlier, with Alpenglow, every block proposal is evaluated among two concurrent voting paths:

• Fast-Finalization (one-round)
• • Triggers when the notarized vote tally for a given block in the first round of voting reaches ≥80% of stake
  • Produces a Fast-Finalization Certificate 
  • Has a latency target of ~100ms
• Fallback (two-round)
• • Triggers when the notarized vote tally for a given block in the first round of voting reaches ≥60% of stake
  • Produces a Finalization Certificate after the notarized vote tally for the second round reaches ≥60% of stake
  • Has a latency target of ~150ms

Votor runs both paths concurrently, meaning both tallies are updated from the same stream of first-round votes such that the first certificate that crosses its threshold finalizes the block. The overlapping stake set (i.e., ≥60%) ensures two conflicting blocks can never both reach finality.

The operational consequences of this new design are positive for validators:

Reduced Operational Costs 

Removing voting fees significantly lowers the barrier to entry for prospective validators. In turn, voting fees made smaller validators more dependent on inflation rewards during bear markets. Its removal could warrant future discussions regarding Solana’s inflation, given SIMD-228’s contentious vote. Under the currently discussed implementation of Alpenglow, such a reduction would reduce the minimum amount of SOL to be profitable from ~4850 SOL (~800k USD) to ~450 SOL (~75k USD), as calculated using Cogent Crypto’s Validator Profit Calculator.

Streamlined Key Management 

Solana validators no longer require a per-slot vote signing. This means that the validator identity key can live in a Hardware Security Module (HSM) without any performance risks, effectively reducing hot-wallet risk.

Reduced Leader-Slot Network Load

Aggregating one certificate per block replaces thousands of individual vote transactions per epoch, reducing leader-slot network load. 

No Lock-Out Math

Solana’s Tower-style exponential lock-out table is removed. Now, validators only need to track the latest certificate chain in memory, shortening restart times.

What is Alpenglow’s impact on RPC providers?

The operational consequences of this new design are mostly positive for RPC providers, with a few posing potential scalability concerns:

Simplified Commitment Levels 

This new level of finality would erase the historical gap between the confirmed (i.e., optimistic) and finalized (i.e., rooted) commitment levels. For instance, this means that any UX logic that waits for two confirmation levels (e.g., show spinner until finalized) can be reduced to a single certificate check.

Reduced Ledger Size

Given Solana's current demand, ledger growth would drop by roughly three-quarters due to the lack of vote transactions. This also means reduced snapshot sizes and archives. However, given the projected targets for block limit CU increases, how this plays out in practice is yet to be determined.

WebSocket Fan-Out Bottleneck

With Alpenglow, it no longer makes sense to poll transactions, given finality arrives in ~100-150ms and is encoded in a single certificate. It would make more sense to get finality information via a push channel that stays open for the life of the app, browser, or bot, and broadcasts every new certificate to every subscribed client. Pain points shift from millions of tiny HTTP polls to hundreds of thousands of real-time sockets.

Real-Time Cache Freshness

Any cache that hangs on to account data longer than a quarter of a second could potentially surface stale data, given certificates settle a block within 100-150ms. Edge caches, CDNs, and Layer 7 proxies will need extremely short TTLs or certificate-aware purge hooks.

What is Alpenglow’s development timeline?

Alpenglow was officially unveiled at the New York Accelerate conference in late May. The next phase involves publishing a formal Solana Improvement Document (SIMD), which will open the proposal to community feedback via GitHub, Solana governance forums, and the Solana Tech Discord.

Following the community review period, the proposal will proceed to an on-chain governance vote by the validator community. In parallel, the new design will undergo extensive testing to ensure performance and security.

If all stages proceed as planned, the deployment to Solana mainnet is expected by early next year.

Alpenglow Risks and Open Questions

A New Consensus Algorithm

Transitioning to a new consensus protocol is a significant undertaking, but there is meaningful precedent. Ethereum’s 2022 Merge demonstrated that a major live network can successfully shift its core consensus mechanism, moving from Proof-of-Work to Proof-of-Stake without disrupting operations. That is to say, there are still numerous risks, but it’s not entirely uncharted territory.

Such a transition would also necessitate migration guides so apps, SDKs, wallets, and bots don’t silently break as Alpenglow collapses the confirmed and finalized commitment levels into a single certification check. Any code that explicitly polls for two commitment levels, or defaults to a confirmed commitment level, will cease to work. A co-ordinated ecosystem effort is needed regarding documentation, lint warnings, RPC methods, and general code architecture before Alpenglow goes live. 

Governance

Governance risk is another factor to consider. The recent SIMD-228 vote demonstrates that Solana operates as a truly decentralized network where proposals, even those backed by core developers and prominent community members, are not assured passage. However, the upcoming changes introduced by Alpenglow, particularly the reduction in voting costs, are broadly favorable to validators, especially smaller operators. As a result, we believe the likelihood of governance resistance is relatively low.

Rewards

The Alpenglow whitepaper and related materials published so far do not specify the exact mechanisms for rewarding validator voting activity or compensating Rotor relays for bandwidth usage. The whitepaper also clearly states that equivocation is punishable, but who actually submits the penalty, how large the penalty is, and whether the punishment in question is automatic or governance-driven isn’t specified. These omissions leave key aspects of validator economics undefined and could become points of contentious debate within the ecosystem.

MEV

Alpenglow will also fundamentally restructure the current MEV landscape on Solana. Latency continues to be a driving factor regarding MEV, as some profitable strategies rely on mirroring TPU traffic or spam canceling and replacing transactions in a certain order before they become optimistically confirmed. This all occurs within the current ~500-600ms window, which Alpenglow seeks to collapse to ~150ms. At first glance, leaders, especially validators that already host customized block building infrastructure, stand to capture a larger share of MEV, while independent latency arbitrageurs may see their edge disappear unless they continue to develop even faster, more granular trading systems.

Multiple Concurrent Leaders

Alpenglow’s design is much more flexible to adopt a multi-leader framework—known as Multiple Concurrent Leaders (MCL)—compared to Solana’s current consensus architecture. As Anatoly Yakovenko noted, a first-cut MCL prototype could entail spinning up two Alpenglow instances that share the same Rotor set and release all shreds simultaneously. Rotor would fan out the parallel streams, and Votor would notarize each lane. However, several execution-layer questions begin to appear. Namely,

• How should write-sets be partitioned so that two leaders’ blocks never lock the same account—or, if they do, that conflict resolution be both deterministic and cheap?
• How do we merge per-lane certificates into one canonical state root without doubling replay cost?
• What sort of fee market logic applies when lanes compete for assets?
• What kind of cross-lane MEV strategies would this enable?
• Could a single high-stake validator dominate concurrent slots without lane caps? 

While Alpenglow’s design helps make MCL a realistic roadmap item by removing consensus-level blockers, it still remains a promising, future endeavor until these open questions are answered.

Conclusion

This report explored Alpenglow's core components and examined how they reshape Solana’s consensus model. We’ve also analyzed the technical improvements, changes to validator economics, network-level impacts, and benefits for performance, simplicity, and scalability.

The Alpenglow whitepaper marks a turning point for Solana, not just in protocol design but also in development philosophy. For the first time, Solana has published formal correctness proofs for its consensus algorithm, signaling a shift from its traditionally empirical, engineering-driven approach toward a more rigorous, research-backed foundation. This evolution reflects a maturing ecosystem that continues prioritizing performance, but now with the added discipline of formal verification.

The deprecation of Proof-of-History (PoH) represents a similarly symbolic shift in the network’s identity. While PoH’s practical importance has often been overstated, it has long served as Solana’s signature innovation, featuring prominently in technical primers and has become synonymous with the brand. Its removal marks the end of an era and the beginning of a new one. Solana is growing up.

Additional Resources

• Accelerate Alpenglow Presentation Slides - Roger Wattenhofer
• Alpenglow: A New Consensus for Solana - Anza blog
• Alpenglow Reference Implementation - GitHub
• Alpenglow Whitepaper - Quentin Kniep, Jakub Sliwinski, Roger Wattenhofer
• Consensus on Solana - Helius blog
• Scale or Die at Accelerate 2025: Introducing Alpenglow - Solana’s New Consensus - YouTube Video