Pier Two is proud to support Solana as a major consensus partner and source of institutional adoption.
Solana will soon transition to Alpenglow, a consensus rewrite that increases the speed of finality by 32x, opening the network to a much broader category of applications. Faster finality reduces risk and allows capital to move more freely. Alpenglow achieves this by replacing significant components of Solana's consensus layer with a new streamlined system.
By the end of this blog, you will understand what Alpenglow is, why it's important, and it's implications for developers, validators and industry.
Real-world experience has exposed some challenges for typical Byzantine Fault Tolerance (BFT) consensus systems. While Solana produces blocks every 400ms, true finality (the point where a transaction becomes irreversible) takes an average of 12.8 seconds. Most applications work around this by relying on "optimistic confirmations", which is effectively to bet that a block won't be reversed after 1-2 subsequent blocks. This creates a risk. Apps can never be sure whether their transactions are confirmed or not for 12.8 seconds.
For a global trading system—as Solana positions itself—12-second finality times can be problematic. Price shocks can do a lot of damage in 12 seconds. Traders and applications bake this uncertainty into their spreads and/or fees. Funds that are “being confirmed” are also effectively taken out of the market and can’t otherwise be used productively.
Faster finality provides better guarantees to market participants, improves capital efficiency and tightens spreads, making it far more tenable for global finance.
In addition to reduced finality, Alpenglow also aims to solve the following pain points:
Solana's current consensus is a three-part system that has been instrumental in getting itself this far. Before diving into Alpenglow, lets understand how Proof of History, Tower BFT, and Turbine currently work.
Proof of History (PoH) acts as a built-in clock used by validators to timestamp transactions. It allows validators to send and receive information efficiently by running a continuous chain of computations called a verifiable delay function (VDF). Each step in this chain produces a timestamped hash that depends on the previous one, creating an unbroken sequence of events.
When a validator embeds a transaction into this hash chain, its exact position in the sequence serves as proof of when it occurred. Other validators can quickly recompute and check the same steps to confirm the order and timing of each transaction. The benefit is that validators don't need to perform additional handshakes to agree on timing and stay in sync.
This feature has allowed Solana to avoid the coordination overhead that plagues other blockchains, enabling extremely fast block production (~400ms).
Tower BFT is Solana's custom BFT consensus mechanism that provides validators with a shared, on-chain voting system. Inspired by Tendermint's Practical BFT consensus (PBFT), Tower BFT puts proposed blocks through a continuous voting process.
Here's how it works:
In practice, Solana treats a block as finalised once it has gathered around 32 consecutive votes from validators, which equates to roughly 12.8 seconds. Alpenglow’s proposed 400ms finality makes it 32 times faster than Tower BFT.
Turbine is Solana's decentralised, peer-to-peer information sharing protocol that keeps every validator synchronised. When a leader produces a block, it breaks the block data into small packets called "shreds" and sends them to randomly selected validators. Each validator uses those shreds to reconstruct the block, casts its vote, and then relays both the block packets and vote to another random subset of peers. This process repeats across the network in a tree-like structure, ensuring all validators eventually receive the same information.
Alpenglow addresses every one of these issues through a fundamental architectural change. Instead of incremental improvements, Alpenglow replaces the entire consensus stack with two new components: Votor, and Rotor.
Votor abandons Tower BFT's complex, time-locked voting system in favour of a streamlined approach. The key innovation is concurrent two-path voting that usually achieves finality in a single network round-trip.
Here's how it works:
Votor gets all of the voting done and dusted in 1 or 2 rounds, as opposed to the existing 32 rounds required by Tower BFT. But the clever part is in the concurrency of the 2 rounds; Validators don't wait to see if the 80% fast path succeeds, they start the fallback path as soon as they see 60% support. Whichever path completes first finalises the block.
Rotor reimagines how block data spreads across the network. Instead of Turbine's multi-hop tree (typically 3-4 hops to reach all validators), Rotor uses a single-layer relay design that puts larger staked validators to work.
When a leader creates a block:
This process allows validators on the receiving end (in 3) to reconstruct the block with as little as ~67% of the data. Even if some relays fail or network links drop packets, the block can still be assembled.
The breakthrough is bandwidth multiplication. Instead of the leader's 10 Gbps connection being the bottleneck, Rotor harnesses the combined bandwidth of many validators. If 32 relays each contribute their full bandwidth, you effectively get 32× the data transmission capacity.
This approach uses what the whitepaper calls "asymptotically optimal" bandwidth utilisation. Essentially, it's maximising the network's bandwidth capabilities.
For Application Developers real finality in hundreds of milliseconds unlocks application categories that weren't previously viable on any blockchain:
Developer Experience Improvements
Eliminating PoH computations removes a significant CPU and power requirement. The continuous SHA-256 hashing that currently runs on every validator becomes unnecessary.
Bandwidth and latency become the critical resources. High-stake validators will need:
Under Rotor, a validator's data relay duties scale with their stake. Large validators become critical infrastructure for network data distribution, while smaller validators focus on consensus participation.
Alpenglow positions Solana as the clear choice for applications where finality speed matters. While Ethereum maintains advantages in ecosystem maturity and liquidity, the 100× finality improvement is significant for many use cases.
The update puts Solana ahead of most competitors in raw performance metrics, potentially attracting developers who prioritise speed above all else. Sub-second finality addresses one of the key concerns institutional users have about blockchain infrastructure: settlement speed comparable to traditional financial systems.
To achieve fast finality speed, Alpenglow makes a calculated security trade-off. Blockchains are generally quite good at preventing malicious actors from tampering with consensus. To date, there have been no recorded adversarial attacks on the consensus layer of Solana or any of the major networks discussed in this article. Traditional Byzantine Fault Tolerance systems (like Ethereum's Gasper) typically require a coordinated entity to control more than 51% of the network stake (or hash power, in Bitcoin's case) to double-spend funds or re-order blocks. But the cost of doing so is economically impractical. In practice, liveness issues are far more common and more important to mitigate. If more than 33.33% of a Proof of Stake network goes offline, the network grinds to a halt. Solana has had its fair share of liveness failures. Alpenglow offers stronger protection against these failures than traditional Byzantine Fault Tolerant (BFT) systems, making the network more resilient than before, and theoretically more resilient than its competition.
Here's the new math:
A Simple Analogy: Imagine a boardroom with 10 directors: In a typical BFT system, at least 7 of those board members need to attend the vote for the company to continue operating. With Alpenglow, the system can still proceed securely with only 6.
As we discussed above, Alpenglow allows Solana to reach consensus extremely fast. These performance gains bring the same speed and security guarantees offered by many compliant Web2 applications, but network-wide by default on Solana's shared global state.
There is also a compelling argument to be make about reducing the tolerance for malicious stake from 33% to 20% in exchange for these improvements.
Anatoly Yakovenko summarises the reasoning: "threats only arise if actors collude with over 40% of the stake." Given that:
In any case, adversarial actors are still priced out of gaining enough stake to double spend or re-order blocks. Yes, it's cheaper to do so with Alpenglow in relative terms, but the economic cost is still impractical even at the new 20% threshold. The trade-off intentionally prioritises the more common real-world problems (network partitions, validator downtime) over theoretical attack vectors.
The Alpenglow update represents the largest protocol change in Solana's history. Key considerations include:
The Solana Alpenglow update represents more than just a technical upgrade. It's a statement about the future of blockchain infrastructure. By trading a small degree of theoretical security for massive practical improvements, Solana is betting that real-world usability trumps perfect Byzantine fault tolerance.
For developers building the next generation of decentralised applications, Alpenglow removes one of the last barriers between blockchain and Web2 performance.
The blockchain industry has long promised to match traditional financial infrastructure in terms of speed and reliability. With Alpenglow, Solana might be the first to actually deliver on that promise.