Firedancer Team Floats Plan to Drop Solana Block Limit

A new technical proposal from the Firedancer developers suggests removing Solana’s fixed “compute units per block” limit — an aggressive change aimed at letting the network scale with validator performance rather than an artificial cap.

Listen to This Article

Prefer to listen? Hit play below to hear the narrated version.

Key Takeaways

Firedancer devs proposed removing Solana’s per-block compute cap so throughput scales with validator performance.
Supporters expect denser blocks, fewer congestion failures, and better fee efficiency; skeptics flag networking/centralization risks if blocks grow too large.
The idea is in community review and testing; Anza amplified the discussion on X inviting feedback.

The idea, published as a Solana Improvement Document (SIMD), would allow block capacity to rise naturally as validators run faster hardware and clients pack transactions more efficiently.

Backers say the current ceiling slows Solana during peak demand by forcing leaders to stop adding transactions once a block hits its compute quota.

Scrapping that quota could create a performance flywheel: leaders that can safely schedule more work earn more fees, while other validators are nudged to upgrade to keep pace. In theory, this aligns incentives around real throughput instead of fixed thresholds.

The Firedancer team — best known for building a high-performance, independent Solana validator client — frames the change as a step toward unlocking the network’s headroom revealed in recent testing. Firedancer has already shown stronger block packing and execution in controlled environments; protocol-level limits are now a primary bottleneck, developers argue.

Anza, a core Solana engineering shop, flagged the proposal publicly and pointed the community to the discussion thread on X, inviting feedback from validators, client teams, and builders.

There are trade-offs to weigh. Bigger blocks can stress networking and propagation if they grow faster than the peer-to-peer layer can deliver them, raising the risk of temporary forks or missed votes.

Critics also worry a pure “hardware wins” model could tilt the validator set toward operators with deeper pockets, if the protocol doesn’t pair higher capacity with safeguards that preserve broad participation.

Proponents counter that Solana’s existing timeouts and block-skipping behavior provide a natural safety valve — validators that can’t keep up simply skip a block rather than stalling the chain — and that clients can tune enforcement without changing consensus.

The debate comes after a series of incremental increases to Solana’s compute budget over the past year and separate proposals to lift the cap further. Removing the cap entirely would be the most radical option on the table, shifting the protocol from fixed ceilings to market-driven block sizing moderated by slot time and client heuristics.

Next steps: client authors and validators will test the approach, stress the networking layer, and model edge cases (like sudden volume spikes and leader misbehavior) before any mainnet change. For application teams, the outcome matters: higher effective capacity could mean fewer failed transactions during mints, smoother DeFi liquidations, and room for more complex on-chain programs — provided the network can propagate larger blocks reliably at scale.