Skip to main content
Technical proposal SIMD-0207 Accepted

Raise Block Limits to 50M CUs

  1. Idea
  2. Draft
  3. Review
  4. Accept
  5. Implement
  6. Active

Decision brief

Why this proposal matters

Raise the block limit from 48M to 50M CUs.

Source-backed reading aid · source language: EN

Proposal at a glance

What changes

  • Max Block Units - The maximum number of CUs that can be included in a block.
  • Max Writable Account Units - The maximum number of CUs that can be used to write any given account in a block.
  • Max Vote Units - The maximum number of CUs that can be used by simple votes in a block.

Stakeholder map

Who is affected

Builders & client teams Impact unknown

No proposal-specific evidence was found for this group.

Action requirement unknown
Validators & operators Medium impact

This proposal only changes the Max Block Units limit. The purpose is to increase capacity for non-vote transactions. The Max Writable Account Units is left unchanged since there is no specific push to increase the capacity for individual accounts at this time.…

Action requirement unknown
Users & stakers Medium impact

More transactions can be included per block.

Action requirement unknown
Governance & ecosystem Impact unknown

No proposal-specific evidence was found for this group.

Action requirement unknown

Exact source revision

Full proposal document

Source-language document. Technical identifiers and evidence remain unchanged. 0616093b2952

Summary

Raise the block limit from 48M to 50M CUs.

Motivation

Current block limits are set to 48M CUs. Block limits's primary purpose is to make sure that the vast majority of network participants are able to keep up with the network, by restricting the amount of work a leader is allowed to pack into a block. However, current main net beta traffic is largely not constrained by large block execution times. This proposal aims a modest increase in block limits to 50M CUs, in order to give some additional capacity to the network, and client implementations ready for future increases as the performance of the network improves.

New Terminology

No new terms, but the following definitions are given for clarity:

  • Max Block Units - The maximum number of CUs that can be included in a block.
  • Max Writable Account Units - The maximum number of CUs that can be used to write any given account in a block.
  • Max Vote Units - The maximum number of CUs that can be used by simple votes in a block.
  • Max Block Accounts Data Size Delta - The maximum size of the accounts data size delta in a block.

Detailed Design

The following table shows the current block limits and the proposed block limits:

TypeCurrent Block LimitProposed Block Limit
Max Block Units48M50M
Max Writable Account Units12M12M
Max Vote Units36M36M
Max Block Accounts Data Size Delta100MB100MB

This proposal only changes the Max Block Units limit. The purpose is to increase capacity for non-vote transactions. The Max Writable Account Units is left unchanged since there is no specific push to increase the capacity for individual accounts at this time. Keeping Max Writeable Account Units unchanged while raising the Max Block Units , allows for additional parallel capacity.

Alternatives Considered

  • Leave the block limits as they are
    • This leaves capacity on the table, we want to get ready for future increases.
  • Double limit to 96M CUs
    • Viewed as too aggressive at this time, and may cause unforeseen issues particularly in infrastructure supporting the network users.
    • We instead plan to increase the limits incrementally as the network performance improves.

Impact

  • More transactions can be included per block.

Security Considerations

  • Blocks may take longer to execute, slowing down network progress.

Drawbacks

  • Larger blocks may cause unforseen issues in infrastructure beyond the validators.

Backwards Compatibility

  • All previously valid blocks are still valid, since limits are only increasing.
  • Blocks produced after the change may be rejected by previous versions that do not support the new limits.

Evidence graph

Related proposals and rollout

One or more sources are unavailable.

Upstream review record

Upstream discussion & review

GitHub review is editorial context, not evidence of on-chain support, voting, or outcome.

PR #207 · merged SIMD-0207: Raise Block Limits to 50M 16 comments and reviews · Jan 19, 2026
@7layermagik

How about making it so the block limit cu increases are contingent on cluster vote latency being within a good enough range? That'll add many months though. The SIMD process seems to take forever -- might as well make the proposal a more thorough one. 2mil more cu's isn't going to stress things much at all either I imagine -- idk what value there is increasing it only that much

GitHub ↗
@godmodegalactus

What does increasing Block Accounts Data Size Delta affect ?

GitHub ↗
@godmodegalactus

What is the Block limit for non-vote transaction after this increase ?

GitHub ↗
@apfitzge

50M for all transactions, it's in the table

GitHub ↗
@apfitzge

That'll add many months though. The SIMD process seems to take forever -- might as well make the proposal a more thorough one. 2mil more cu's isn't going to stress things much at all either I imagine -- idk what value there is increasing it only that much Goal with this is kind of a "foot in the door" from my perspective. With this simd, we set up system so we can easily add features for block-limits. I'm hoping to backport this. Future SIMDs adjusting limits can just be backported and activated more quickly. Regular procedure of taking eons to activate be damned.

GitHub ↗
@apfitzge

We're not increasing it. It limits overall state growth.

GitHub ↗
@blockiosaurus

Is the feature gate actual required? It would be nice to have automatic progression and so long as you use a static calculation based off of numbers already under consensus (e.g. Epoch or Slot) the validators should be able to easily calculate the current block limit.

GitHub ↗
@steviez

The feature gate gives us the ability to raise the limit at a time when we feel the cluster is healthy and can handle the additional load that the higher limit could introduce. Adding in "raise limit at epoch N" adds unknowns; what if the cluster is struggling when epoch N comes up or what if the entire validator set hasn't adopted a new enough version by the time epoch N rolls around. It would be nice to have automatic progression This is somewhat similar to what 7layermagik mentioned here(https://github.com/solana-foundation/solana-improvement-documents/pull/207issuecomment-2521143758). But to quote Andrew from here(https://github.com/solana-foundation/solana-improvement-documents/pull/207

GitHub ↗

simd.watch community discussion · SIMD-0207

Powered by Giscus · Sign in with GitHub to comment

Community comments load when this section approaches the viewport.

Provenance

Evidence & technical details

Rollout or chain data, source revisions, freshness and integrity.
2

SIMD

Deployment Status

Document lifecycleAccepted
CategoryCore protocol
Devnetactive Epoch 857
Testnetactive Epoch 764
Mainnet-Betaactive Epoch 770
5oMCU3JPaFLr8Zr4ct7yFA7jdk6Mw1RmB8K4u9ZbS42z

Exact source revision

Sources & integrity

  • Proposal document pinned_commit_blob
    0616093b2952ed6de52c4a27d66aadd11d48d4f9
  • simd-document document · stale · Sep 10, 2026
    0616093b2952ed6de52c4a27d66aadd11d48d4f9

One or more sources are unavailable.