Alpenglow retires Proof of History and Tower BFT. Solana's honest TPS target is 100k.
Anza is rewriting Solana's consensus layer from scratch, and the 1M TPS headline undersells the more interesting engineering question.

CryptoVibe Desk · solana · consensus · layer-1

- →Anza, the Solana Labs spinoff, is building Alpenglow, a consensus replacement that retires Proof of History and Tower BFT and targets 1M TPS.
- →Retiring PoH removes Solana's most contested architectural assumption, and if Alpenglow ships, it answers years of decentralization criticism with code rather than a whitepaper.
- →Watch for Alpenglow on public testnet by end of 2026; 100k TPS sustained alongside Firedancer in production is the validation signal, not the benchmark number.
- Proof of History (PoH) → A cryptographic mechanism Solana uses as a shared clock, letting validators agree on the order of transactions without needing a communication round-trip.
- Tower BFT → Solana's consensus algorithm, which runs on top of Proof of History and lets validators vote on which version of the chain is canonical.
- Firedancer → An independent Solana validator client built by Jump Crypto, rewritten in C to eliminate the processing bottlenecks in the original Rust implementation.
- Anza → The engineering company that spun out of Solana Labs in 2024 to own development of Solana's core protocol client.
Alpenglow replaces two components Solana has run since mainnet launch: Proof of History, a cryptographic clock that lets validators agree on transaction ordering without a communication round-trip, and Tower BFT, the consensus protocol built on top of it. The 1M TPS target attached to Alpenglow is real. The more defensible number for 2026, and the one that matters for production planning, is 100k.
Anza, the engineering company that spun out of Solana Labs in 2024, is building the replacement. The proposed design separates data dissemination from finality: Rotor handles getting block data to validators quickly; Votor handles the voting round that produces finality. That separation matters because Tower BFT entangles those two steps, which is part of why raising Solana's throughput ceiling requires touching consensus at all.
The code does what the announcement says, plus one thing worth naming explicitly: Alpenglow changes how leader-scheduled block production interacts with validator voting. Tower BFT's fork-choice rules give the current block leader meaningful unilateral control over short time windows. Whether Votor changes that calculus is the protocol question to track once testnet is live. The architecture looks cleaner on paper; production will tell you if it holds.
The 1M TPS figure comes from stacking two separate engineering bets. Alpenglow reduces consensus overhead by cutting the communication rounds needed before finality. Firedancer, Jump Crypto's independently built Solana validator client, rewrites the node in C and targets the single-threaded execution bottlenecks the current Rust client runs into. In benchmarks, the combination reaches 1M TPS. In production, the realistic estimate is around 100k TPS sustained.
The gap between those numbers is not a failure. It's the difference between a pipeline at theoretical capacity and a pipeline under real conditions: adversarial network topology, geographic validator spread, irregular block sizes, and occasional partitions.
Any distributed system that consistently hits its benchmark ceiling under production load is a system you should distrust. The ceiling tells you the architecture has headroom. The production number tells you what actually ships.
A sustained 100k TPS on a general-purpose L1 would still be the highest production throughput in the category. The comparison against Ethereum isn't really fair, since the two chains optimize for different things, but the directional point stands: Solana's architectural bets point toward a different performance envelope on purpose, and Alpenglow is the mechanism that makes the math work.
The tradeoffs Anza is accepting: PoH has a production track record, however contested its decentralization assumptions. Replacing it on a live chain is a different risk profile than replacing it before launch.
Tower BFT's failure modes are known from years of mainnet operation. Votor's are not yet known. The testnet will surface some of them. Others will only appear under production load.
For engineers watching this: the implementation details to track are how Votor handles clock drift across geographically dispersed validators, and whether Alpenglow's leader-scheduling logic carries over cleanly from Tower BFT. Those two things will determine whether Alpenglow's finality guarantees hold in the edge cases PoH used to smooth over with its clock. Read the testnet validator logs. Not the thread.
Anza is right to retire PoH and Tower BFT together rather than patching either separately: the two components are entangled enough that fixing one while leaving the other produces a system whose novel failure modes nobody has mapped yet.
Alpenglow reaching public testnet by Q4 2026, and specifically whether it breaks any of Firedancer's current coordination assumptions; if it doesn't, the 100k TPS production case becomes credible.
Primary links and supporting reads used by the desk for this story.
Forward this.











