150 milliseconds of ambition: Solana aims to make "finality" faster.

Written by: KarenZ, Foresight News

Solana has already become one of the fastest public chains in the crypto industry, but there is still one thing that is not fast enough: stamping transactions with final confirmation.

On Solana, a transaction can receive initial confirmation in just a few hundred milliseconds, but waiting for the network to determine that the transaction is final and cannot be reversed through the normal consensus process typically takes over ten seconds.

For ordinary users, this waiting time may not be obvious. However, for high-frequency trading, on-chain payments, stablecoin settlements, and an increasing number of transactions initiated automatically by AI agents, quickly processing transactions and obtaining finality are two different matters.

Now, Solana is ready to undertake a major upgrade to tackle this issue.

On October 13, the Solana core development team Anza announced the mainnet activation schedule for the Alpenglow upgrade (SIMD-0326), planning to switch the consensus protocol of the Solana mainnet from TowerBFT to Alpenglow on October 21. The core goal of this upgrade is to reduce the previously measured block finality time from seconds to approximately 150 milliseconds.

This is not simply about increasing TPS (transactions per second) or a routine performance optimization. Solana will replace the core consensus protocol that has been in use since its inception and redesign how validators vote, how consensus is reached on blocks, and how to continue operating during network failures.

What is particularly noteworthy is that this upgrade, which has been in the works for over a year, is expected to complete the key switch within a single block slot.

Solana is already fast enough; why is Alpenglow still needed?

To understand Alpenglow, one must first grasp the concept of "finality."

In simple terms, finality means that under the premise of the protocol's security assumptions, a block that has been confirmed will not be replaced by subsequent consensus.

Solana previously adopted a consensus mechanism based on Proof of History (PoH) and TowerBFT. PoH provides verifiable event ordering, while TowerBFT uses validator voting to gradually reach consensus on the validity and final state of blocks.

Under the original TowerBFT mechanism, confirmed and finalized correspond to different levels of confirmation; after Alpenglow is enabled, in terms of consensus semantics, confirmed and finalized will trend toward equivalence.

The roughly 150 milliseconds proposed by the officials describes the finality target under normal network conditions.

The v1.2 white paper further explains the origin of the performance figures: in a simulation where block producers are randomly selected based on staking weight, the median finality time is approximately 130 milliseconds. The simulation uses specific staking distributions, inter-node network latency, and bandwidth assumptions and does not account for block execution time. Since the first phase of the mainnet upgrade does not include Rotor, the 130 milliseconds cannot be directly seen as the post-upgrade mainnet performance.

Votor: No longer waiting for 32 slots, two voting paths compete simultaneously

One of the core innovations of Alpenglow is a voting mechanism called Votor.

Its design idea is not complex: instead of allowing a new block to wait for multiple subsequent blocks to gradually accumulate final confirmation, validators can vote directly, and once enough staking weight agrees, the final confirmation is completed immediately.

You can think of the overall staking weight of the network as 100 shares of voting power. Votor runs two paths to finality simultaneously:

• Single round path: A quick finality certificate can be formed once a first round of voting representing at least 80 shares of weight supporting the same block is received.
• Two-round path: When the first round of voting supporting the same block reaches 60% of staking weight, a second round of voting is entered; if the second round also reaches the 60% staking weight threshold, that block can obtain final confirmation.

Both paths run in parallel, and the one that completes valid final confirmation first takes effect. The percentages refer to the staking weight participating in the vote, not the number of validators.

The cleverness of this design lies in the fact that fewer rounds do not always mean faster completion compared to multiple rounds. If nodes representing 60% weight communicate quickly, they may complete two rounds of voting faster than waiting for a more distant 80% weight to complete a single round. Votor allows nodes to adopt the effective path that finishes first, thus adapting to different network locations and communication conditions.

In addition to shortening the finality time, Votor also changes the way validators vote.

Under the previous TowerBFT mechanism, Solana validators submitted votes through on-chain transactions, which required occupying on-chain data and transaction processing resources. After Alpenglow is enabled, participating validators will directly exchange voting messages with BLS signatures; after collecting votes that meet the corresponding staking weight threshold, nodes can form concise, verifiable certificates through signature aggregation. In this way, consensus voting no longer needs to be written as transactions into blocks one by one, thereby reducing the data and processing overhead brought by on-chain voting.

At the same time, Votor introduces a clear skip mechanism. If the block producer fails to provide a valid block in a timely manner, validators can vote to skip the corresponding slot to avoid the network waiting continuously.

In conjunction with this, Alpenglow no longer relies on Proof of History (PoH) to advance the original consensus process; instead, it coordinates consensus through the validators' local timers, voting messages, and related certificates.

Rotor: Solana also wants to break the bandwidth bottleneck of block propagation

If Votor addresses how blocks can achieve final confirmation faster, then another design of Alpenglow, Rotor, attempts to solve how blocks can be propagated more efficiently to global validators.

The complete design of Alpenglow involves multiple components, but the focus of the first-phase deployment is Votor. The Turbine responsible for propagating block data remains temporarily; the new propagation scheme Rotor in the white paper will be deployed separately.

Solana currently uses the Turbine protocol to propagate block data. Turbine divides data into smaller segments and forwards them through multiple layers of nodes, avoiding the need for block producers to send the complete block to all validators alone.

Rotor continues the approach of data slicing and erasure coding but further adjusts the propagation method.

According to the design in the white paper, block producers will encode the data into multiple segments, send them to different relay nodes, which will then forward them to other nodes in the network. Compared to the multi-layer propagation tree of Turbine, Rotor aims to utilize the upload bandwidth of the entire validator network more fully by using single-layer relay propagation and assigning forwarding tasks based on staking weight.

Moreover, Rotor uses erasure coding, so even if some data segments fail to arrive successfully, the receiver has the opportunity to reconstruct complete data with a sufficient number of other segments.

From a design perspective, this helps to improve the efficiency and fault tolerance of block propagation, and can also alleviate the limitations posed by a single block producer's upload bandwidth. The greater significance of Rotor is to create conditions for Solana to subsequently increase block data throughput capability.

The "20+20" fault tolerance model: Solana is redefining fault tolerance boundaries

Apart from speed improvements, Alpenglow also makes important adjustments to Solana's consensus security model.

In blockchain networks, validators may not always be honest or online. Some nodes may stop working due to power outages, server failures, or network disruptions, and some nodes may deliberately send incorrect information or even collude to attack the network.

Therefore, a consensus protocol must not only consider how to quickly confirm transactions under normal conditions but also answer a question: when some validators experience failures or engage in malicious actions, can the network still operate securely?

Traditional Byzantine Fault Tolerant (BFT) consensus usually has a safety boundary of less than one-third of node weight existing with any malicious behavior. Alpenglow adopts a different design, proposing the so-called "20+20" fault tolerance model.

The two 20% thresholds correspond to different types of failures.

The first 20% means that as long as the staking weight controlled by malicious validators is less than 20%, Alpenglow can maintain consensus security under its established model. Even if malicious participants attempt to disrupt communication or the network experiences prolonged delays, it will not cause honest nodes to ultimately confirm conflicting blocks.

The second 20% refers to additional node outages or offline failures. Under stronger network assumptions, in addition to less than 20% of malicious staking weight, Alpenglow can also tolerate additional staking weight offline of up to about 20%.

The reasoning behind this is that in a proof-of-stake network with a large number of validators, failures may not necessarily come from organized attacks; they may also arise from software bugs, hardware issues, or infrastructure disruptions.

However, this represents a trade-off that must be faced: Alpenglow is not necessarily more secure than traditional BFT in all failure scenarios, but it chooses a different safety boundary in exchange for faster finality.

On October 21, Solana will undergo a true consensus switch

The Alpenglow upgrade plan is not something that has been proposed recently. In 2025, Alpenglow, as SIMD-0326, was submitted to the Solana community and passed in the governance vote that year.

Since then, Anza has continued to advance protocol development, testing, and validator preparation work. On September 24, 2026, Alpenglow completed its switch in the Solana Testnet; the next day, it completed the corresponding migration in the Devnet. Now, the upgrade is about to enter the mainnet phase.

For Solana, the significance of Alpenglow lies not only in compressing the final confirmation time from over ten seconds to about 150 milliseconds.

In the past, Solana has built advantages in meme coins, DeFi, and on-chain transactions by relying on high throughput and lower transaction costs. However, for financial scenarios that require quick and reliable settlements, block finality remains a problem that must be addressed.

Alpenglow is attempting to fill this gap.