Jump’s Firedancer Team Proposes SIMD-0370 to Remove Solana’s Fixed Block Compute Limit

Summary

A new proposal, SIMD-0370, submitted by Jump Crypto’s Firedancer team, aims to eliminate Solana’s fixed compute unit (CU) block limits following the Alpenglow upgrade. Under the design, block producers would⁴ pack blocks to full capacity while slower validators would skip blocks. Over time, well-resourced validators gain rewards and compel upgrades by laggards, allowing the network throughput to scale with validator power instead of a static cap. The proposal follows Solana’s ongoing timeline of block limit increases, such as SIMD-0286 which raises the CU ceiling from 60 million to 100 million.

What Is Proposed in SIMD-0370 & Motivation

• Removal of fixed block CU limits
  Instead of a hard ceiling (currently 60M CUs, rising to 100M in SIMD-0286) per block, the new model would allow block producers to include as many transactions as their hardware can process. Validators that fall behind would temporarily skip blocks. This dynamic approach would let throughput scale with validator capacity. (Source: Solana devs X post)
• Incentive mechanism
  Blocks packed by high-performance validators earn more fee rewards. Validators that fail to keep pace lose block production chances, which motivates them to upgrade hardware and performance. Over time, this could drive a positive feedback loop where network capacity organically increases.
• Alignment with recent capacity proposals
  Solana has already been discussing SIMD-0286, which would increase the block CU limit from 60M to 100M (a ~66 % increase). That change is meant to accommodate heavier compute demand in DeFi, MEV, and parallelizable workloads.
  The SIMD-0370 concept pushes beyond that by making the limit adaptive rather than fixed.
• Technical and economic trade-offs
  The proposal implicitly accepts that hardware disparity among validators will lead to a performance hierarchy. But proponents argue that competitive pressure will shrink performance gaps over time, raising overall blockspace capacity.

Why This Is Important for Solana’s Scalability

1. Throughput no longer bounded by static limits
   The current block limit is a trade-off to ensure validators of varied performance can keep up. But as demand grows and hardware improves, fixed ceilings become bottlenecks. SIMD-0370 would allow block capacity to reflect real compute availability.
2. Incentive alignment for validator upgrades
   Validators that don’t upgrade risk losing rewards and block production chances. Over time, that fosters a stronger, more performant validator set.
3. Future-proofing for heavy workloads
   More complex applications, advanced DeFi strategies, multi-step transactions, MEV, and novel on-chain logic benefit from headroom. The removal of arbitrary caps could better support evolving use cases.
4. Risks and centralization pressure
   Validators with superior hardware will gain an edge. If too many weaker validators fall behind, the network may centralize around a few top operators. Ensuring a minimum baseline of hardware and promoting validator competition will be crucial.

What Is Verified & What Remains Speculative

Verified / Documented:

• Solana currently has fixed block CU limits; the network is in the process of upgrading from 60M CUs toward 100M CUs via SIMD-0286.
• The SIMD-0286 proposal is openly discussed in Solana development^q circles, as a method to increase block capacity.
• A social media post from Solana devs references SIMD-0370 by Jump’s Firedancer team proposing to remove fixed limits after Alpenglow.

Speculative / Unverified:

• The detailed mechanics in your prompt (i.e. slower validators skipping blocks, producers packing blocks, endogenous incentive loop) are not confirmed in any public specification I found.
• There’s no published formal “SIMD-0370” document in official Solana Improvement⁶ Documents (SIDs) repositories (at least not discoverable in this search).
• The timing, implementation feasibility, risk mitigation, and adoption path of this adaptive model remain speculative.

Challenges & Risks in Adoption

Risk	Details / Concern
Validator hardware disparity	Faster operators may dominate, leading to centralization if others drop out.
Block propagation & network performance	Very large, compute-intense blocks may slow propagation, increasing latency or risk of fork conditions.
Consensus & coordination	Adopting a non-uniform block limit requires strong coordination, versioned upgrades, and consensus support.
Fairness & predictability	Users expect predictable behavior; variable limits might introduce uncertainty in fees or inclusion.
Security & denial-of-service risk	Without limits, malicious actors could attempt to overload blocks; some metering or protection may still be necessary.

Outlook & Next Steps

• Formal specification and review: If Jump’s team publishes a full SIMD-0370 design, the broader Solana community will need to audit, simulate, and stress-test it.
• Testnet deployments: Trials on devnets or feature-gated environments to validate performance, lag behavior, and stability.
• Validator feedback & consensus building: Convincing validators to adopt the new regime will require demonstrating net benefit and manageable risk.
• Incremental rollouts: The network could phase in flexible mode after fixed limit increases (e.g. after 100M CU is stable) to reduce transition risk.
• Monitoring centralization metrics: As the model is tried, tracking block share dispersion, orphan rates, and validator dropout will be key to assessing health.

WE8OVNVI