Solana Alpenglow: how Votor replaces TowerBFT

The problem with “fast enough”

Solana processes more transactions per second than any other live blockchain, with 400ms slot times and fees that are effectively negligible. But throughput and finality are different things, and Solana has always had a gap between them.

A transaction can land in a block in under a second and still take 12.8 seconds to reach deterministic finality. That window comes from TowerBFT, the consensus mechanism Solana has run since launch. To finalize a block, validators must vote on it across 32 successive slots, each vote adding an exponential lockout that makes reorganizing the chain increasingly expensive. It works, but it means every app on Solana is building around a finality delay that its raw throughput numbers never implied.

Proof of History compounded this by acting as a cryptographic clock baked into consensus itself, tying ordering and timing together in a way that made sense when the network needed to prove it could run at all. That tradeoff is now the ceiling. Alpenglow is the attempt to remove it.

What Alpenglow actually is (and isn’t)

Alpenglow is the name for a full redesign of how Solana reaches consensus. It has two parts, and only one of them is actually shipping right now.

Votor is the voting and finalization engine that replaces TowerBFT. It is the core of Alpenglow, the part that governance approved as SIMD-0326 with 98.27% of participating validator votes in favor, and the part that is currently running on the dedicated community test cluster. Rotor, the block propagation layer that will eventually replace Turbine entirely, is explicitly deferred to its own separate SIMD process. At activation, Turbine stays in place, which means the breaking changes on day one are confined entirely to the consensus layer.

The 98.27% approval figure is worth pausing on. Validator governance on Solana rarely produces that kind of unanimity. It signals that the economic and technical case for Alpenglow was not seriously contested among active validators, which matters for how confidently infrastructure teams can plan around it.

Where Alpenglow stands right now

The upgrade has moved faster than most Solana protocol changes, but it is not on mainnet yet. Here is where things stand:

• September 2025: SIMD-0326 passed validator governance with 98.27% approval
• December 2025: Alpenglow demonstrated publicly at Breakpoint
• May 11, 2026: went live on the dedicated Anza community test cluster, including a live “Alpenswitch” migration from TowerBFT
• H2 2026: mainnet target via the Agave 4.1 client release, with community testing expected to run through Q3 and into Q4, gated on public testnet activation and security audits

The most concrete near-term signal to watch is SIMD-0387, the BLS key management prerequisite, landing on public testnet. That is the clearest indicator the upgrade has moved from a private cluster to a public network. Firedancer has endorsed the design but has no production Votor implementation on any cluster yet, making multi-client parity the other key variable before mainnet activation.

Teams behind Alpenglow

Alpenglow is the work of Anza’s research division, led by Professor Roger Wattenhofer of ETH Zurich, one of the world’s top-ranked institutions for distributed systems research. Wattenhofer is joined at Anza by his former PhD students, Kobi Sliwinski and Quentin Kniep. The academic roots matter here: Wattenhofer previously co-authored the 2024 paper “Halting the Solana Blockchain with Epsilon Stake,” which uncovered liveness vulnerabilities in Solana’s existing consensus protocol. The team that found the holes in TowerBFT is the same team that designed its replacement.

Anza itself was spun out from Solana Labs and comprises the entire core protocol development team. They are best known for building the Agave client, the software that powers the vast majority of Solana’s network.

On the client diversity side, Jump Crypto’s Firedancer team is collaborating on multi-client compatibility. Their involvement is significant for network resilience, though as covered in the conclusion, a production Votor implementation from Firedancer is still pending.

How Votor works

Under TowerBFT, validators cast their votes as on-chain transactions. Every vote was a real transaction, processed and stored like any other, which is why validator votes make up roughly 75% of all Solana transactions today. Votor removes that entirely.

Instead, validators broadcast lightweight vote messages directly to each other. Any node can collect those messages and aggregate them into a BLS12-381 certificate once enough stake weight has been signed. That certificate, roughly 1,000 bytes, is the only thing that touches the chain. The individual votes never do.

Two finalization paths run at the same time. The fast path finalizes a block in a single round when at least 80% of stake has voted. The slow path finalizes after two rounds, requiring a notarization certificate at 60% stake followed by a finalization certificate at 60% stake. Whichever path crosses its threshold first finalizes the block. Running both concurrently means the protocol does not have to choose between speed and resilience upfront. It takes whichever outcome arrives first.

Before vs. after comparison

	Before (TowerBFT + PoH)	After (Alpenglow + Votor)
Finality time	~ 12.8 seconds	~ 100–150ms
Voting mechanism	On-chain vote transactions	Off-chain BLS messages
What touches the chain	Every individual vote	One ~1,000-byte certificate
Proof of History	Core part of consensus	Removed from consensus
Vote transaction volume	~75% of all Solana transactions	Eliminated
Validator vote cost	~1 SOL per day in fees	VAT: ~0.8 SOL per day, burned
Byzantine fault tolerance	33%	20% adversarial + 20% crash
Block propagation	Turbine	Turbine (unchanged for now)

Vote transactions: 75% of Solana, gone

When vote transactions disappear, two things happen at once. Block space opens up dramatically, with roughly 75% of all Solana transactions gone overnight, leaving room for user transactions that were previously competing with validator housekeeping. But that same disappearance creates a problem: vote transactions were generating fees, and those fees were being burned. Remove them and you remove a significant share of the deflationary pressure that SOL’s tokenomics depend on.

The Validator Admission Ticket is how Solana solves that. Rather than paying per-vote transaction fees, validators pay a flat admission ticket — initially 1.6 SOL per epoch, roughly 0.8 SOL per day — to be admitted into the active set for that epoch. That fee is burned, preserving the burn mechanic that vote transactions were inadvertently providing. It is not a discount on validator operating costs so much as a structural replacement for the fee flow that disappears when votes go off-chain.

Why Alpenglow bets on a tighter safety margin

Classic Byzantine fault tolerant protocols tolerate up to 33% of stake acting maliciously before safety breaks. Alpenglow drops that to 20%, which on the surface looks like a regression. In practice it is a deliberate trade: by tightening the Byzantine threshold, Votor can finalize blocks in a single round rather than two, which is what makes the 100-150ms finality target possible. The protocol also separately tolerates up to an additional 20% of stake being offline or crashed, so the total non-responsive stake it can handle sits around 40%.

The more significant change is not the number itself but how it is justified. TowerBFT was never formally proven safe. Its correctness was established the way most early blockchain consensus mechanisms were: through simulation, game-theoretic reasoning, and years of running on a live network with real economic stakes. That is a legitimate form of validation, but it is not the same as a mathematical proof.

Alpenglow ships with formal safety proofs. The protocol’s behavior under adversarial conditions is not argued by analogy or stress-tested into confidence; it is derived. For a network handling the transaction volume Solana does, that is a meaningful maturity leap, and it changes the conversation around Solana from a network that has survived to one that can be reasoned about.

What this means for builders and infrastructure

Commitment levels and streaming pipelines

Solana currently exposes three commitment levels: processed, confirmed, and finalized. A lot of application code is built around the gap between confirmed and finalized, either defaulting to confirmed for speed while accepting some rollback risk, or polling for finalized as the slow but safe option. Under Alpenglow that gap effectively disappears. Both levels converge into a single deterministic certificate that arrives in roughly 100-150ms, which means the trade-off your code was making no longer exists in the same form.

The shift this forces is straightforward:

• Replace polling loops with signatureSubscribe for push-based finality detection
• Shorten cache TTLs to under 250ms or add certificate-aware invalidation
• Audit any code that treats confirmed and finalized as meaningfully different states

For Geyser and Yellowstone gRPC consumers, the change is more structural. Vote transactions make up roughly 75% of current Solana transaction volume and they vanish at activation. Pipelines that are sized, filtered, or instrumented around that volume need to be reworked before mainnet, not after. Specifically:

• Transaction volume drops ~75% overnight, so any consumer sized around current throughput will be over-provisioned
• Slot-status logic that treats finalized as a slow trailing event needs review against the new certificate-based model

Validator prerequisites

Before Alpenglow activates on any public network, validators must register a BLS public key on their vote account per SIMD-0387. A vote account without a registered BLS key will behave as unstaked once Alpenglow is live. Tracking SIMD-0387 landing on public testnet is the clearest signal that the upgrade is moving from a private cluster to a public network. Chainstack Solana RPC endpoints are the right place to test your integration as those testnet builds become available.

What could delay mainnet

The most concrete gate is SIMD-0387, the BLS key registration prerequisite, landing on public testnet with enough runway for validators to register before activation. If that slips, everything downstream slips with it. Security audits are a separate formal requirement, and any findings that require meaningful changes to the implementation reset that process entirely.

The harder variable to predict is multi-client parity. Activating Alpenglow with Firedancer holding no production Votor implementation means the vast majority of stake runs on a single client through the transition. That is a risk the community will need to weigh, and waiting for Firedancer to catch up could push activation into 2027. The 100-150ms finality figures are also still simulation-derived, and public testnet at full validator scale may surface edge cases the community cluster did not.

Conclusion

Alpenglow passed governance under SIMD-0326 with 98.27% validator approval and went live on the community test cluster on May 11, 2026. Anza and Anatoly Yakovenko have confirmed a late Q3 or early Q4 2026 mainnet target via the Agave 4.1 client release.

The variable most teams are underweighting is client diversity. Firedancer has engaged seriously with the roadmap, proposing SIMD-0370 to lift block compute limits on the basis that Alpenglow makes higher hardware scaling safe. But without a production Votor implementation on any live cluster, multi-client parity remains an open question that could affect the mainnet timeline.

FAQ

Additional resources

• SIMD-0326: Alpenglow — the governance proposal that defines Votor, the VAT, and the 20+20 security model. The first place to go for any technical question about what is actually shipping.
• SIMD-0387: BLS Pubkey Management in Vote Account — the validator prerequisite. Landing on public testnet is the concrete signal that Alpenglow is moving toward mainnet.
• Alpenglow Whitepaper v1.1 — the full academic paper from Kniep, Sliwinski, and Wattenhofer, including the formal safety proofs and the Rotor design that ships separately.
• Anza Research: A New Chapter for Solana’s Protocol — Anza’s own introduction to the research team and the protocol’s academic lineage.
• Chainstack Solana RPC — the place to test your integration against testnet builds as SIMD-0387 reaches public testnet.
• Chainstack docs: Solana Alpenglow consensus explained — the operator-facing companion to this post, with the readiness checklist for RPC and node teams.