Alpenglow on Solana: how the network's consensus will change

When people talk about Alpenglow, Solana's next consensus evolution, it is easy to focus on one figure: a target finality time of around 150 milliseconds.

It is a striking number, but it does not explain the full scope of the change.

Alpenglow redesigns how Solana reaches consensus, how votes are coordinated, and how blocks are propagated across the network. It also introduces new components, including Votor, BLS public keys, and the Validator Admission Ticket (VAT). These are part of a gradual transition, not a single instant upgrade.

More than an isolated speed improvement, Alpenglow prepares a new architecture for a network that already operates at scale.

Alpenglow is the new consensus protocol Solana is preparing to replace the current Proof of History and TowerBFT mechanisms.

Its first phase focuses on Votor, a voting algorithm designed to reduce finality latency and simplify coordination between validators. Under the current model, votes are sent as on-chain transactions. With Votor, validators will exchange vote messages directly and use aggregated cryptographic certificates to prove that consensus has been reached.

The design includes two paths for finalizing blocks:

• a fast path, where a block can be finalized in one round when it reaches the required participation threshold;
• a second round for cases where that threshold is not reached initially.

Solana has set a target finality time of around 150 ms, compared with current pre-confirmation latency of roughly 400 ms and TowerBFT finality of around 12.8 seconds.

This should not be understood as performance already available on mainnet. It is the target of a consensus change that is still being rolled out and validated.

The central change in Alpenglow is Votor.

Instead of turning every validator vote into an on-chain transaction, Votor allows votes to be sent directly between participants. Those votes are then aggregated into certificates representing the state of consensus: notarization, finalization, or a decision to skip a block.

This approach is intended to reduce part of the network load associated with vote transactions and enable faster finality.

The protocol also introduces a resilience model known as 20+20. It is designed to maintain liveness even if up to 20% of stake behaves adversarially and another 20% is offline.

This is not only about processing transactions faster. It is about redesigning how a large validator network coordinates itself.

Alpenglow does not stop at voting.

A later phase called Rotor is expected to progressively replace Turbine, Solana's current block-propagation system. Rotor will retain the use of erasure coding but move from a tree-based distribution model to a single relay layer.

The goal is to reduce latency in data distribution between nodes.

The distinction matters: Votor and Rotor belong to the same technical direction, but they will not be deployed at the same time. The initial transition focuses on voting and finality logic, while Rotor will follow later.

For Votor to aggregate multiple signatures into a single certificate, Solana needs a different signature scheme from the one currently used in vote accounts.

This is where BLS public keys come in.

BLS signatures can combine many signatures over the same message into one verifiable proof. This makes it possible for consensus certificates to represent participation from many validators without verifying every signature individually.

BLS public-key management is already active on mainnet. Each validator needs an additional BLS public key to prepare for the new model. It does not replace the existing ed25519 vote-account identity, but adds a cryptographic layer specifically for Alpenglow.

It is an important technical prerequisite, but registering a BLS public key does not activate Alpenglow by itself.

The Validator Admission Ticket, known as VAT, is a separate feature gate that defines who can join the admitted validator set participating in consensus.

Once active on mainnet, VAT will require two main conditions:

• a registered BLS public key;
• a position among the top 2,000 validators by stake in each epoch.

A validator that does not meet these conditions is excluded from the admitted set, stops voting, and stops receiving inflation rewards while it remains outside that set.

VAT should not be confused with slashing. It is not a penalty for malicious behaviour or an operational incident. It is an admission mechanism that prepares the network for Alpenglow's consensus model.

It is also important to separate VAT from the full Votor activation:

BLS prepares the keys. VAT controls admission. Alpenglow changes consensus.

The consensus change also modifies how certain network operating costs are structured.

Under TowerBFT, validators send vote transactions on-chain. Solana estimates these costs at around 2 SOL per epoch for an actively participating validator.

With Alpenglow, votes will no longer be published as on-chain transactions. Instead, admitted validators will pay a fixed 1.6 SOL per epoch fee through VAT.

This fee will be burned rather than redistributed as a fee to block producers.

The initial intention is to maintain an economic barrier comparable to current voting costs within a different architecture. It does not mean rewards will automatically move in a specific direction. The final economics of each operation will still depend on stake, network rewards, fees, infrastructure costs, and effective performance.

A consensus change also changes which metrics matter and how they should be interpreted.

Until now, a significant part of Solana validator visibility has come from on-chain vote transactions, vote credits, and related activity. With Votor, votes will no longer follow that same flow.

Certificates and aggregates will still provide evidence of consensus activity, but monitoring tools will need to account for the new context so that metrics remain useful and comparable.

At Stakely, we already work on making Solana operations more visible through the Solana TVC Live Tracker, an open-source tool for tracking validator voting status, credits, and activity under the current model.

Alpenglow reinforces why that observability matters: it is not enough for a network to be fast. Its operation also needs to be understandable.

Alpenglow will be deployed in phases. BLS public keys already prepare validators for the new model, VAT will establish admission conditions, and Votor will change how Solana reaches finality. Rotor will later extend this evolution to block propagation.

The relevant point is not to predict a fixed date or assume a performance outcome before the rollout is complete.

Alpenglow represents a deep change in how Solana coordinates consensus: less reliance on on-chain vote transactions, aggregated cryptographic certificates, a much faster finality target, and a new admission and cost structure for the network.

At Stakely, we will continue following this transition through our experience operating infrastructure on Solana. You can stake SOL with Stakely directly from your own wallet while retaining control of your assets.