SIMD-0326: Proposal for the New Alpenglow Consensus Protocol

Governance
1

Authors: Quentin Kniep, Kobi Sliwinski, Roger Wattenhofer

Summary

Alpenglow is a major overhaul of Solana’s core consensus protocol, replacing the existing Proof-of-History and TowerBFT mechanisms with a modern architecture focused on performance, resilience, and whenever possible simplicity.

At the heart of this new design is Votor, a lightweight, direct-vote-based protocol that finalizes blocks using either a single or dual-round voting process, depending on network conditions. Alpenglow significantly reduces latency (from 12.8 seconds under TowerBFT to as low as 100-150 milliseconds) while also improving bandwidth efficiency by eliminating heavy gossip traffic. The protocol introduces a robust certification mechanism, with different certificate types corresponding to notarizating, skipping, or finalizing blocks based on validator votes. To support this, validators will exchange votes directly, using cryptographic aggregates to prove consensus. Rotor, Alpenglow’s new data dissemination protocol, will be introduced in a later update, the current rollout focuses on finalization and voting logic.

This forum post only outlines the most important aspects of Alpenglow. On all the topics below, there is much more detailed information available. In particular we recommend reading the actual Alpenglow white paper: https://github.com/rogerANZA/Alpenglow-White-Paper/blob/main/Alpenglow-v1.1.pdf .

However, there is also a list of additional information available:

Motivation

The move to Alpenglow is driven by the need to address both performance and security limitations in Solana’s legacy consensus protocol TowerBFT. TowerBFT imposes long finality delays and lacks formal safety guarantees. Alpenglow is designed with insights from recent advances in distributed systems and blockchain research, enabling much lower latency, improved fault tolerance, and generally greater protocol efficiency. The introduction of direct voting, local signature aggregation, and off-chain vote messaging substantially cuts down on unnecessary computation and communication costs. Furthermore, Alpenglow addresses key incentive flaws in the previous system—such as validators delaying votes for strategic gain—by rebalancing economic rewards and introducing mechanisms like the Validator Admission Ticket (VAT) to maintain fair participation without on-chain vote fees. Its “20+20” resilience model allows the protocol to remain live even if up to 20% of validators are adversarial and another 20% are unresponsive. In short, Alpenglow brings consensus latency to a level comparable with Web2 applications while strengthening the system’s security posture, scalability, and economic fairness.

Protocol Overview

Let us outline Alpenglow from a broad perspective. The protocol operates across a large network of nodes which may number in the thousands. These nodes are part of a defined validator set that remains stable throughout a period known as an epoch. Each node can directly communicate with any other node in the network by sending messages.

Alpenglow functions as a proof-of-stake blockchain, meaning that each node has an associated amount of stake, which reflects its level of participation and influence. Nodes with greater stake have proportionally higher responsibilities and rewards, including contributing more bandwidth and earning higher fees.

Time is divided into discrete intervals called slots. Every slot is assigned a specific leader, chosen in advance using a randomized, verifiable process. Each leader is responsible for a sequence of consecutive slots, referred to as their leader window. During this window, the leader collects transactions from users and from other nodes and uses them to create a new block.

Blocks are built in a pipelined fashion: they are split into intermediate units known as slices, which are further divided into smaller pieces called shreds. Initially, these shreds are dispersed across the network using Turbine. Later, we will replace Turbine with the more efficient Rotor. (Rotor will need to pass its own SIMD process.)

Once a block is constructed, the following leader begins producing the next block without delay. Meanwhile, all nodes receive the newly created block and store its data using a dedicated storage system. After receiving a block, nodes begin the voting process to signal whether they accept it. This involves a range of vote types and corresponding aggregated proofs, which are maintained in a local structure that tracks voting history and progress.

The core voting logic (Votor) decides whether a block should be finalized. If a node receives the block in a timely and valid form, it will cast a vote in favor. If the block is delayed or invalid, the node will vote to skip it. Finalization occurs when a sufficient portion of the stake affirms the block. If consensus isn’t reached in the first round of voting, a fallback round may be used to determine whether the block should be skipped or accepted.

In cases where a node misses data—such as shreds or entire blocks—there is a “Repair” recovery mechanism that allows it to request missing information from other nodes, ensuring data completeness and integrity even in the presence of faults or delays.

Together, these components form the foundation of Alpenglow’s consensus protocol, aiming for high performance, strong fault tolerance, and efficient operation at scale. Since a 50+ page document can only be summarized, we encourage reading the actual detailed documentation: https://github.com/rogerANZA/Alpenglow-White-Paper/blob/main/Alpenglow-v1.1.pdf.

Rewards and Incentives

Alpenglow introduces a revamped rewards and incentive system that aligns with its new consensus design, aiming to preserve economic fairness, eliminate inefficiencies, and reinforce active participation. Under the previous protocol, validators submitted on-chain vote transactions for each slot, incurring significant overhead in bandwidth, transaction fees, and processing load. Alpenglow replaces this system with off-chain voting and efficient signature aggregation, dramatically reducing the cost and complexity of participation while maintaining reward fairness.

Each validator’s reward is proportional to their stake, as in traditional proof-of-stake systems. For every voting action a validator performs, they receive a portion of the protocol’s inflationary issuance. This issuance is calculated per slot and distributed based on stake weight. In each slot, a validator casts one of two possible votes (e.g., in favor of a block or to skip it), and these are collected and aggregated by the designated leader 8 slots in the future.

To ensure validators remain engaged and do not game the system, Alpenglow introduces stricter rules and more transparent accountability. Validators are required to cast exactly one valid vote per slot. Submitting conflicting votes is detectable. Validators that fail to participate are not eligible for rewards and risk being excluded from the active set of validators.

A mechanism introduced alongside this new model is the Validator Admission Ticket (VAT). Since voting is no longer posted on-chain (and hence no longer requires direct transaction fees), the VAT serves as an upfront cost to maintain an equivalent economic barrier. Before each epoch, each validator must pay a fixed fee—initially set to 1.6 SOL per epoch. This fee is non-refundable and burned, helping to offset inflation while preserving the economic dynamics of the current system. If a validator does not hold sufficient balance to cover the VAT, it is removed from the validator set.

Leaders also receive compensation for their role in aggregating and submitting vote data. For each valid aggregate they submit (either notarization or skip votes), the leader earns a reward equal to that of all votes included in the aggregate. Additionally, leaders are rewarded with a flat bonus for including fast-finalization or finalization certificates, recognizing the higher computational cost of processing aggregate signatures. These rewards and incentives are described in more detail in the SIMD: https://github.com/solana-foundation/solana-improvement-documents/pull/326

Voting Process

The voting process will proceed as follows:

  • Discussion period: Validators are encouraged to participate in discussions to address any concerns.

  • Stake weight collection period: Stake weights will be captured and published for voting. Validators will have the opportunity to verify these weights.

  • Vote token distribution will require validators to utilize the adapted Jito Merkle Distributor tool (available at https://github.com/laine-sa/solgov-distributor) to claim the vote tokens corresponding to their stake weights.

  • Three token destination accounts will be created for voting choices: Yes, No, and Abstain.

    Validators will have a designated period to vote by sending their tokens to the respective addresses.

  • After the voting period, if the sum of Yes votes is equal to or greater than 2/3 of the total sum of Yes + No votes, the proposal will pass.

  • The proposal has a quorum threshold of 33%, abstentions count towards the quorum.

  • All announcements regarding this process will be made in the Governance category of the Solana Developer Forums.

  • Stake weights and a tally script will be available at https://github.com/laine-sa/solgov-distributor/tree/master/votes/simd0326

    Timeline

  • Epoch 833–838: Discussion period

  • Epoch 839: Stake weights captured and published, discussion/confirmation of stake weights

  • Epochs 840–842: Voting tokens available to claim, voting completes at the end of epoch 842

Discussion

Active participation in discussions about this proposal is crucial. Discussions may also take place in the various forums and channels mentioned at the beginning.

6 Likes
2

Strong support from Firedancer regarding replacement of the consensus algorithm. These simplifications save months of work getting TowerBFT edge cases right. Thank you to the Alpenglow team for this important contribution.

I won’t comment on reward changes, but looking forward to hear from validator operators.

4 Likes
3

Before each epoch, each validator must pay a fixed fee—initially set to 1.6 SOL per epoch. This fee is non-refundable and burned, helping to offset inflation while preserving the economic dynamics of the current system.

I would like to know more about how this 1.6 number is chosen, thats only about a 25% decrease from todays voting costs. Do we not have an opportunity here to make it much more affordable to run a validator?

3 Likes
4

The 1.6 SOL was chosen to mimic the current economics. Now on-chain votes cost about 2 SOL per epoch, and the 1.6 SOL is simply 80% of that (so basically the same, but a little lower to make sure that nobody is worse off). After Alpenglow has launched and is stable, we discuss economics again. We do not want to disrupt the economics for the “AlpenSwitch.” We initially continue with roughly the same set of trustworthy validators as we have now.

1 Like
5

If proof-of-history is replaced, how does it change transaction expiration policy? Currently txn is valid for 150 hashes after its blockhash was made. If this is removed in Alpenglow, does this mean, that there is no formal ttl? And user cant rely on the blockhash invalidation to know whether the txn is included in the block or no? Or is there any other mechanic, that replaces the old way of txn invalidation?

1 Like
6

Currently, if I remember correctly a tx is valid for 150 slots. We can just keep that, we still have slots.

(Since you mentioned it: This rule may be a problem going forward, some people in finance say that they need a longer validity – just including a sequence number might be better. All of this is independent of Alpenglow though.)

1 Like
7

It causes problems not only to a finance (inspecting instructions for example takes a long time when txn is more complex), since ~60s is pretty short time window. On the other hands it makes sure you know the txn will get into final state in 60s without any other user action. Adding other validation or prolonging the time would make sense though.

8

If votes will now be offchain as opposed to being recorded onchain through vote transactions, what would be the best way to track a validator’s voting performance (e.g. whether they voted for a slot or not, if they voted twice, if they voted in a timely manner)?

1 Like
9

Whether validators voted we will still see in the certificates and aggregates (which both go on chain). There is no more incentive to vote late, since there is no more punishment for voting wrongly (e.g. on the wrong branch). Everybody just votes truthfully, no speculation necessary. However, we will collect some metrics. If we eventually see bad behavior, we are going to design rules that punish that bad behavior.

2 Likes
10

Yes, this is something that is already discussed among the Solana people (independently from Alpenglow).

11

Is there a place I can read more about this discussion?

12

Nothing written so far, only oral discussions.

1 Like
13

My concern is that while a new architecture is being designed for thousands of nodes, having a fixed VAT of 1.6 SOL per epoch still creates a high entry barrier for new validators. This effectively protects the current active set and discourages new participants from entering validation.

I’ve seen the response in replies that 1.6 SOL was chosen to mimic the current economics and that this figure will be revisited later.

Still, I wanted to share the thoughts that came to mind while reading the proposal. I’ll revisit them once the 1.6 SOL rate is discussed separately.

I’m not an engineer or an economic expert => just sharing ideas:

1. Pro-rata VAT based on active stake
If we have 1000 validators, the total VAT for all would be 1600 SOL per epoch. That amount would be split among all active validators proportionally to their active stake.

2. Segmentation by stake size
Validators could be grouped by active stake (small/medium/large) with corresponding VAT rates — for example: 0.5 / 1 / 3 SOL per epoch.
Alternatively, VAT could have a minimum and maximum (e.g., 0.5–5 SOL) with a curve to determine the exact cost based on active stake.

Both approaches still offset inflation.

  • The first approach redistributes the cost proportionally and greatly lowers the economic barrier, but it could lead to an unlimited number of validators, so extra measures (like an active set limit or minimum stake) would likely be needed.

  • The second approach is more balanced — a compromise between evenly sharing costs and maintaining an economic threshold.

1 Like
14

Thanks for your suggestions (to be considered in the future, so to speak). They are quite different from anything we ever considered. Your second proposal would be problematic since it’s a step function, so it can be profitable to cut a validator into two (which is something we want to prevent). In the first proposal, stake splitting is “free,” so big validators could just split into many medium size validators and then drive out the small ones by taking all the slots.

From a security point of view it would be best to have n independent validators, all with roughly the same stake, with n in the area of maybe 100. Rather than having more, we would like to have more (geographic) diversity. Having 5,000 validators in close geographic proximity does not make the system more secure.

2 Likes
15

I also wanted to ask about rewards. Many validators currently operate with a 0% staking fee and 0% Jito fee, relying heavily on block rewards.

Has there been any discussion on the economic implications of how the new design — especially with the introduction of new reward types — might impact the reward structure for validators?

16

Summarizing:
Rewards + MEV: No change
Compute/Network Cost: Will be less
Cost for Votes: Replaced by VAT, but only 80%, so less

17

Simplifying consensus and achieving sub-second finality is a big leap - looking forward to it.

2 Likes
18

Introduction

Thanks for putting up the proposal. To me, there are two primary topics of discussion, the Alpenglow governance process mechanics and the decision whether or not to adopt Alpenglow’s votor mechanism.

Governance process mechanics

It goes without saying that Alpenglow represents a major and significant change to all aspects of the Solana protocol, the validators who run the chain and the users who use it.

Because of the immensity of the proposed change, I would suggest the following sequence of steps -

1 - Defining the SIMDs that will be presented to determine whether or not to adopt Alpenglow

From what I’ve read in this proposal, SIMD-0326 is intended to to replace the current voting mechanism with the Alpenglow voting mechanism named Votor. I also infer from this SIMD that a second SIMD will be proposed that would determine to replace the current block dissemination mechanism with the Alpenglow block dissemination mechanism named Rotor.

Am I interpreting this correctly? Are there other SIMDs related to the core Alpenglow protocol contemplated in addition to these?

Assuming there are a sequence of SIMDs, what are the consequences and dependencies of one SIMD on another? For example, I assume if SIMD-0326 was to pass, it would not require the Rotor SIMD to pass, in order for Votor to operate, i.e. they are independent of each other.

2 - Define the scope of each SIMD

The scope of the SIMDs should be clearly defined. For example, the title of SIMD-0326 is quite broad. I had to read and infer from the reading it that SIMD-0326 is focused on replacing the current voting mechanism with the Alpenglow Votor voting mechanism.

The title of each SIMD should clearly state the scope of the SIMD and the body of the SIMD should define that scope in detail. I’d also suggest that potential benefits, risks and their mitigation are listed. Linking or referring to a specific part of the whitepaper, if available, would also be acceptable way to do this.

Clearly state what voters are being asked to vote on in each SIMD. For example, again, I infer that SIMD-0326 is asking voters on whether or not to replace the current voting mechanism with Votor. This should be stated explicitly within the SIMD to avoid confusion.

Whether or not to adopt Alpenglow’s voting mechanism, Votor

This is a much larger discussion. It would be helpful to have it in a single place and here is probably the best place for that discussion. Others will likely share more detailed concerns than I do, however I do plan a second response focusing in a more detailed way on Votor.

In the meantime, at a more meta level, I think any SIMD asking voters to adopt a change to the core Solana protocol should include a testing, deployment and fallback plan. I don’t see any plan listed in this SIMD and without it, would not be comfortable voting in favor of SIMD-0326 in its current form.

Conclusion

I feel that more thought should be given to the SIMD process as it relates to Alpenglow adoption. This means listing which SIMDs will be presented to determine whether to adopt Alpenglow, defining the scope of each SIMD and clearly laying out the decision each SIMD is intended to facilitate.

Alpenglow adoption SIMDs should include a discussion of benefits, risks and their potential mitigations, as well as a testing, deployment and fallback plan.

Alpenglow adoption is a significant and potentially exciting change for the Solana network and its community. A thoughtful SIMD process will increase its chances for successful adoption.

I see this first SIMD as a step in that direction and look forward to the authors’ response and hopefully revisions. I look forward to staying engaged along the way.

3 Likes
19
  1. Could you expand on the future plans for the VAT? As I understand it SIMD-0257 proposed removing vote fees entirely, greatly reducing the fixed cost for validator operators. Is such a thing possible under the VAT scheme?
  2. What is the replacement for blockhash now that PoH is gone? As an ecosystem observer this seems like the biggest double spend attack vector, do we still have the guarantee that transactions cannot be spoofed or resubmitted under the new schema?
  3. Could you expand on Definition 17 from the paper, specifically what is Δtimeout? I see that is is 1Δ + 2Δ, what does this mean in ms? Does Timeout correspond to 400ms as in leader will have less time to build the block? Are there expected changes to Jito auction because of Δtimeout?
  4. What happens to unstaked nodes under Alpenglow? I see in the SIMD you specified that all validators are staked - will unstaked validators still be able to participate to send txs and run RPC queries?
  5. How does section 2.7 work for transactions? “In this case, slices 1,…,t - 1 are ignored for the purpose of execution” - how should I alter my user workflow if this happens? If my user submits a tx and it ends up getting ignored will it be retried? Or should we ask them to resign the tx?
  6. Finally my boomer question, what is the motivation? is it not possible to speed up TowerBFT? Or is there some fundamental flaw in Solana that requires us to switch? I welcome the speedup but this seems like a really risky upgrade that opens us up to a lot of FUD, could you provide some context on why this is necessary - especially now in a bull market with so many eyes on us.
  7. To add on to the previous point, what steps are we taking to test this change? It seems on par with The Merge, will there be a parallel chain or will this take place all at once? Are there any auditors that have signed off on this change? Are there any eyes on loss of funds attacks?
20

We tried to rise this topic multiple times, and we believe there are some points should be assessed more carefully. The main reason around VAT is

however, the way it is presented drastically change the economics.

Indeed, with current framework, each validator pays ~2 SOL per epoch for voting, and half of it is burned. This means that ~1 SOL per validator is paid back to block proposers. This is ~ 1k SOL (with 1k validators) per epoch redistributed to validators. If current proposal pass, we burn entirely the VAT, so we have 0 SOL redistributed to validators.

If, roughly speaking, we say that a 0.2% stake takes 0.2% of this 1k SOL, we have that a 0.2% stake is neutral regarding vote fees now (since per epoch it receives 2 SOL, i.e. what it pays). With this proposal, the economics is drastically changed since now all stake is in loss for voting.

One can argue that we now have freed CU we can use for normal transactions, but the relation is not straightforward (and needs a closer analysis). Further, there is some evidence of a lack of CU usage, which could be for lack of user demands (unlikely) or for an inefficiency of current Agave code (see e.g. here Timing Games on Solana: Validator Incentives, Network Impacts, and Agave's Hidden Inefficiencies ). Since this is not addressed here but highly correlated, we believe the change around VAT is more invasive than what discussed in the SIMD.

We believe that a VAT is mandatory to avoid some attack surfaces (we analysed them here Distilling Information from Alpenglow Consensus ) however we should assess if it makes sense to burn it. Here I don’t see a proper assessment of this issue.

1 Like