Firedancer's Bigger Blocks Start Solana's Multi Client Era

The news: a proposal to uncap Solana’s blocks

On September’s final weekend, Jump Crypto’s Firedancer team filed a proposal to remove Solana’s per-block compute ceiling after the Alpenglow upgrade. The pull request, known as SIMD-0370, would let block producers pack as much work as their hardware and the network can safely handle, instead of stopping at a fixed number. You can read the primary source in the SIMD-0370 pull request.

Today, Solana bounds each block by a maximum number of “compute units.” Think of compute units like fuel in a car. Every on-chain action burns some fuel. A simple transfer uses a bit. A complex trade or game turn uses more. The network has been operating with a 60 million compute unit limit per block. Earlier discussions floated bumping that to 100 million. Firedancer’s idea is simpler: remove the fixed lid once Alpenglow is live and let the protocol self-regulate using Alpenglow’s skip-vote logic.

That single change, combined with a brand-new validator client, would mark Solana’s move into a true multi-client era. More capacity. Lower variance in fees when demand spikes. A sturdier network because there is no single client to bring down the chain if it misbehaves.

Why this matters: client diversity meets bigger blocks

Until now, Solana’s production network has effectively relied on one primary validator client. With Firedancer, Solana gets an independently built, high-performance client written in C++. Client diversity matters for the same reason the internet runs on multiple browsers and operating systems. If one implementation has a bug, the others keep the system humming. Ethereum learned this lesson years ago, as covered in our look at Ethereum’s interop and client diversity. Solana is now catching up, with a twist: Firedancer is not only a second client, it is engineered to push the ceiling on throughput and cut end-to-end latencies when the rest of the protocol allows it.

Bigger blocks are the other half of the story. Fixed block caps make a network behave like a stadium with a hard fire-code capacity. When a hot game drives demand, people still line up at the door. Removing the cap after Alpenglow is closer to opening more gates and moving the line faster, while still respecting safety rules. Validators that cannot process a heavier block in time will signal a skip rather than stalling everyone.

How Alpenglow changes the ground rules

Alpenglow is the largest rewrite of Solana’s consensus since launch. It replaces legacy vote mechanics with direct voting and introduces new building blocks for faster finality. The practical promise is sub-second confirmations and a protocol that naturally tolerates some validators lagging behind. Anza, the team leading Solana core development, has communicated a mainnet target of late 2025 or early 2026. See the details in Anza’s roadmap note on Alpenglow timing.

Here is what changes that matters for bigger blocks and a second client:

• Skip-votes replace stalls. If a leader proposes a block that is late or too heavy for many validators to execute within the slot, validators cast a skip vote and move on. This keeps the chain live during bursty traffic.
• Direct vote aggregation trims network chatter. Less overhead for votes leaves more budget for shreds and transactions.
• A reworked pipeline for block propagation and, later, a new data dissemination layer will help larger blocks reach more nodes in time.

In short: Alpenglow lowers latency and removes the need to “size blocks for the slowest machine.” That is the precondition for letting faster block producers use more of their hardware.

What bigger blocks plus a second client could do to throughput, fees, latency, and reliability

• Throughput. Removing a fixed compute ceiling increases the amount of work that can fit in a block when demand exists. That does not magically multiply transactions per second on a quiet day. It reduces the odds that the network hits a hard wall during surges, like mint frenzies, on-chain games at peak, or volatile market opens.

• Fees. Solana’s fees rise during congestion because users bid to get included. Larger blocks add supply precisely when bids heat up, which can cap or reduce fee spikes. The result is not necessarily lower average fees, but a flatter fee curve during rush hour, fewer failed transactions, and better predictability for market makers and game studios.

• Latency. Alpenglow’s core benefit is confirmation speed measured in hundreds of milliseconds. Bigger blocks do not inherently make confirmations slower because skip-votes turn a late or overloaded slot into a clean skip. The network moves on rather than waiting for stragglers.

• Reliability. A second independent client reduces the single-point-of-failure risk. If one client version has a consensus bug or a performance regression, the other can keep voting and producing. This is not a theoretical nicety. Networks have suffered from client monoculture in the past. Firedancer’s entry pushes Solana toward the safety standard that mature proof-of-stake systems expect.

A helpful mental model: imagine a four-lane freeway where Alpenglow is the synchronized traffic system that keeps lights green, and Firedancer is a car with a more efficient engine. Removing the block cap is lifting the arbitrary 45 mph speed limit when the road is clear. The system still has guardrails. If conditions worsen, the lights force everyone to slow down or the next light turns red and the block is skipped.

What this unlocks in the next 6 to 12 months

With Alpenglow test networks and Firedancer continuing to mature, the most interesting consumer experiences on Solana become practical to ship at scale. Here are three high-impact categories and why they benefit:

• Real-time multiplayer games. Server tick rates of 30 to 60 updates per second and movement plus combat recorded on-chain have been aspirational. Sub-second confirmation with more headroom per block changes the feel. Designers can put more of the game loop on-chain without rubber-banding or failed actions during spikes. Expect lightweight competitive games, spectator markets, and composable item economies to move from prototype to sticky daily usage.

• Fully on-chain orderbook exchanges. Solana already hosts high-performance orderbooks. With bigger blocks, sustained quote updates and cancels during volatile windows are less likely to hit compute ceilings, and more orders land in the block where they belong. Market makers prefer predictable latency and fewer rejects. That translates to tighter spreads, deeper books, and better price discovery for retail users.

• On-chain social with dense activity. Feeds that update in near real time, reactions that settle instantly, and creator actions that trigger smart contract state changes all benefit from sub-second finality and capacity that does not choke during viral moments. Bigger blocks mean less chance that a trending space knocks the whole neighborhood offline.

Other segments to watch: payment rails that credit deposits faster, prediction markets with dense order flow around news, and decentralized physical infrastructure networks that batch proofs and rewards more smoothly during daily peaks. For broader context on Solana’s growing profile, see SOL’s mainstream finance narrative.

The risks you should care about

Bigger blocks are not free. The proposal explicitly pushes performance to the edge of what the median validator can handle. That carries risks.

• Hardware centralization. If producing or validating heavier blocks requires premium CPUs, higher memory bandwidth, and faster disks, smaller operators could skip more often and earn less. Over time, stake may consolidate with operators who can afford serious machines and low-latency connectivity. The counterbalance is that Alpenglow pays the same rewards for skip votes as for regular votes, and smaller validators can still participate even if they skip some oversized blocks. The network must watch whether the top operators’ share of stake creeps up and whether skip rates disproportionately hit long-tail validators.

• Bandwidth and propagation. Large blocks must reach a supermajority quickly. If a subset of nodes cannot ingest or forward shreds fast enough, the skip rate rises and effective capacity falls. Operators should plan for higher baseline bandwidth and observe whether link saturation appears during bursts. Any move to specialized relay networks must avoid recreating private fast lanes that undermine fairness.

• MEV dynamics. More capacity shifts where the bottlenecks sit. Builders will watch whether concentrated block production, searcher tooling, and priority fee markets increase extractable value from users. The more programmable the block, the more tactics exist to reorder or bundle transactions. Solana already has incentives for builders to run fair ordering, but bigger blocks and new clients may change the balance. For deeper background, review ePBS and fair ordering designs.

• Software divergence. Multi-client networks must manage edge-case differences in how clients interpret the rules. Thorough conformance testing and coordinated releases reduce the risk of client splits. Firedancer and the Rust client need to converge on tricky corners before high stake shares run mixed software in production.

Concrete milestones to track

Builders and investors do not need to guess. The next year has measurable checkpoints that reveal whether the big-block vision is becoming reality.

• Governance and specification

  • Watch SIMD-0370’s path from discussion to a merged improvement document. Note any changes to safety guardrails, such as maximum shred size or slice limits that remain even without a compute cap.
  • Track subsequent client releases that implement the new rules behind a feature flag, then on a canary subnet, then on public testnet.

• Alpenglow rollout

  • Alpenglow on public testnet and test results for confirmation time under load: median and tail latencies, skip-vote rates, and orphaned leader windows.
  • Mainnet activation window. Anza has signaled late 2025 or early 2026 as the target. Expect a phased rollout that starts with a small stake running the new consensus and ramps over epochs.

• Firedancer adoption

  • Count validators and stake weight running Firedancer in production. The goal is not 100 percent. A healthy mix is the target. A common yardstick is double-digit percentage of stake on an independent client without incident.
  • Stability metrics. Uptime across epochs, number of blocks produced and voted by Firedancer validators, and discrepancies between clients discovered and resolved.

• Capacity in practice

  • Effective compute per block at the 50th and 95th percentiles during high-demand windows.
  • Fee behavior under stress. Compare median user fees and failure rates during mints or volatile market hours before and after deployment.
  • Network propagation health. Shred relay times, bandwidth utilization on representative nodes, and skip-vote frequency when block load increases.

What builders should do now

• Budget for bursts. Assume the median block gets heavier. Audit your programs for compute spikes and memory access patterns. Use parallelization where possible and avoid hotspots that serialize the block.

• Design for sub-second UX. If confirmations arrive in hundreds of milliseconds, your interface and back end should be ready. Debounce appropriately, show optimistic states, and reconcile with fast finality.

• Instrument for truth. Add telemetry to record your own view of inclusion time, fee bids, and failure causes during surges. Use that data to choose fee bidding strategies and retry logic.

• Prepare for fair ordering changes. If you rely on temporal priority in the block, build monitoring to detect reordering or bundling patterns that affect your users and consider sending critical transactions through reputable builders or relays that publicly commit to fairness policies.

What validators and infra providers should prepare for

• Hardware planning. Model the cost of upgrading CPUs, memory bandwidth, and network adapters. Track the ratio of skipped to included votes as a function of block load. If your skip rate climbs, you need more headroom.

• Network hygiene. Packet loss and jitter matter more when slots tighten. Measure end-to-end latency to major peers, tune kernel and QUIC parameters, and set up alerting on sustained retransmissions.

• Client mixing. Run canaries of both clients in non-critical setups. Report issues early, especially any execution or consensus inconsistencies across clients.

What investors should watch to separate signal from hype

• Real usage lift, not just benchmarks. Look for sticky daily active users in games and social, plus sustained depth and tighter spreads on orderbook venues during volatility.

• Fee volatility during peaks. Healthier capacity should flatten fee spikes. If median fees and failure rates during surges do not improve, something else is the bottleneck.

• Stake concentration. If the top handful of operators grow their share materially, revisit your assumptions about decentralization risk.

• Roadmap credibility. Did the network hit the testnet and mainnet windows for Alpenglow? Did Firedancer publish clear release notes and a stable upgrade cadence?

The bottom line

SIMD-0370 is not just a knob turn. It pairs with Alpenglow to change how Solana breathes under load. Bigger blocks become safe to attempt because late or overloaded slots can be skipped without stalling the network. A second validator client adds the resilience that modern proof-of-stake networks require. If the next six to twelve months deliver on the roadmap, Solana’s user experience will feel different: faster, smoother at the edges, and more resilient when attention spikes. The prize is not a higher theoretical transactions per second number. It is the ability to run real applications that keep working when everyone shows up at once. That is what builders need, what users notice, and what long-term value depends on.