Solana Gets Faster: Bigger Blocks, Shorter Slots, and the Road to Alpenglow

Solana’s performance roadmap is moving on several tracks at once. In July 2026, the network activated a larger block limit. A separate proposal lays out a staged reduction in slot time. Meanwhile, Alpenglow is preparing to replace the current consensus protocol. These changes are related, but they are not the same upgrade and they are not all live.

The distinction matters. Larger blocks increase the maximum work available in each slot. Shorter slots aim to reduce wall-clock latency. Alpenglow changes how validators vote and finalize blocks. Each can improve user experience, yet each also changes the operating envelope for validators, RPC providers, indexers, wallets, and application developers.

Bigger blocks are already live

The Solana Foundation reported that mainnet activated a 100 million compute-unit block limit on July 29, 2026. That increased maximum block capacity from 60 million compute units, a 66% rise. The per-block limit for a single writable account remained unchanged at 12 million compute units.

That detail is important. The upgrade expands aggregate capacity without giving one heavily used writable account a matching increase. The design encourages parallel work across different accounts rather than letting a single hotspot consume the entire additional budget.

More block capacity can allow more non-vote transactions into a block, but it also raises replay and propagation demands. The original improvement proposal notes that larger blocks may take longer to execute and can expose infrastructure that has not upgraded. Capacity is therefore a ceiling, not a promise that every application will see identical throughput or latency.

Shorter slots are a staged proposal

SIMD-0525 proposes reducing the target slot time from 400 milliseconds to 200 milliseconds in four feature-gated steps: 350, 300, 250, and 200 milliseconds. The staged approach is designed to uncover timing and operational problems before the network reaches the final target.

The proposal keeps four slots per leader window, which would shrink a nominal 1.6-second leader span to 800 milliseconds at the 200-millisecond stage. Shorter slots could reduce confirmation and finalization latency and give applications a finer-grained notion of onchain time.

However, the plan does not simply double work. It scales per-slot limits in proportion to the shorter duration so the wall-clock workload remains approximately stable. When composed with the 100 million compute-unit baseline, the proposal shows lower per-slot limits at each faster stage. Developers should therefore avoid interpreting shorter slots as an automatic doubling of total compute capacity.

The proposal remains marked as a draft. It includes feature gates and an activation delay so validators receive notice before new timing and shred limits take effect. That makes it a roadmap item to test, not a current mainnet guarantee.

Alpenglow changes consensus itself

Alpenglow is the deeper transition. The Solana Foundation describes its first phase, Votor, as an in-development replacement for TowerBFT with a target of roughly 150-millisecond finality. Votes move off ordinary vote transactions and travel directly between validators, where they are aggregated into certificates.

The fast path can finalize after one round when at least 80% of stake votes to notarize. If that threshold is not reached, a second-round path uses 60% thresholds for notarization, finalization, or skipping. The fault model is designed around 20% adversarial stake plus 20% offline stake.

As of August 30, 2026, the official upgrade page still labeled Alpenglow “In Development,” with Votor expected in Q3 2026 and activation tied to Agave 4.3. Preparatory changes had already reached mainnet: BLS public-key management activated July 8, and the Validator Admission Ticket activated July 22. Those steps prepare validator participation but do not themselves turn on Alpenglow consensus.

Why the three tracks must be tested together

Capacity, timing, and consensus interact. A larger block can take longer to propagate and replay. A shorter slot gives validators less wall-clock time. A new consensus protocol changes how late or missing blocks are treated. Testing each feature in isolation is useful, but operators also need combined load, geographic latency, recovery, and mixed-client scenarios.

Application developers should review blockhash freshness assumptions, timeout logic, commitment handling, and transaction retry strategies. Infrastructure teams should monitor replay time, skipped slots, RPC behavior, and indexer lag as test environments adopt new settings. Users should expect improvements to arrive in stages rather than as one instant speed switch.

Key takeaways

• The 100 million compute-unit block limit is live on mainnet.
• The move from 400-millisecond to 200-millisecond slots is a staged draft proposal.
• Alpenglow is an in-development consensus replacement, not merely a speed setting.
• Real performance depends on capacity, propagation, replay, and consensus working together.