Solana: 100M CU blocks — and why your hot account still hits 12M

Solana: 100M CU blocks are live — and your hot account still hits 12M. That is not a contradiction. It is the whole point of the upgrade.

On 29 July 2026 (epoch 1009), mainnet activated SIMD-0286: maximum block compute units moved from 60M → 100M. Official write-up: solana.com/upgrades/100m-cu-blocks. No program rebuild. No indexer migration. The interesting builder question is what actually got looser — and what is still your bottleneck.

Click to zoom

Compute units in one paragraph

A compute unit (CU) is how Solana meters work inside a transaction. Every block has a budget. The leader fills it; once the budget is gone, remaining transactions wait for a later slot (~400ms cadence today). Raise the budget and the same slot can admit more work — if the network can propagate and replay the heavier block.

That last clause matters. Capacity increases are not free marketing knobs. They ride on validator client performance and, for this jump, on networking.

What changed

Limit                              Before    After (SIMD-0286)
─────────────────────────────────────────────────────────────
Max block compute units            60M       100M   ← only this moved
Max writable account CUs           12M       12M
Max vote compute units             36M       36M
Max block accounts data size Δ     100MB     100MB

Breaking change for apps/wallets/indexers?  No
Mainnet activation:  2026-07-29 · epoch 1009
Feature gate:        P1BCUMpAC7V2GRBRiJCNUgpMyWZhoqt3LKo712ePqsz
Author (SIMD):       Jito Labs

Path to here: SIMD-0256 took the ceiling from 50M → 60M (mainnet since July 2025). SIMD-0286 skips a timid 80M stop and goes straight to 100M after a year of client gains.

Why now (demand + XDP)

Foundation numbers: between the 60M activation and this week, 11.2% of blocks used ≥56M CUs — roughly one block in nine sitting inside ~7% of the old cap. Demand arrives in spikes (volatile markets), exactly when traders care most about landing.

The hold-up was not “nobody wants more CUs.” It was getting bigger blocks across the validator set in the same slot window. That is where XDP comes in: kernel-bypass packet path so nodes spend less time in the normal Linux network stack. More than 70% of mainnet stake had XDP on before activation; Firedancer already defaulted it; Agave v4.2 turns it on by default going forward.

Within minutes of the flip, real leaders used the room — Jupiter’s validator pushed past the old 60M line; Staking Facilities nearly filled the new 100M budget. Track live CU packing on ultrasoundsol.com.

The part most headlines skip: 12M writable account CUs

Block CU is a global budget. Writable account CU is a per-account budget: the most compute that can write any single account in one block.

That second number is still 12M.

• At 60M block CUs, one hot account could eat up to ~20% of the block.
• At 100M block CUs, the same 12M is only ~12% of the block.

So the new headroom is mostly parallel capacity: more transactions that touch different accounts can land beside your congested pool. A busy AMM, a widely written config, a contested vault — still chokes at 12M write CUs on that account. The rest of the chain just stops getting collateral damage as hard.

If your app’s pain is “everyone is fighting one account,” 100M blocks help your neighbors more than they help you. If your pain is “the block is full of unrelated spam/traffic,” you just got relief.

What builders should (and should not) do

Do nothing mandatory. Existing programs inherit the ceiling. Priority fees should ease at the margin for the same demand spike, because supply of block work went up ~two-thirds on the global budget.

Do re-check assumptions if you operate infra:

• RPCs, indexers, and exchanges should confirm they handle sustained heavier blocks (formats unchanged; volume/latency profiles shift).
• Validator ops: stay on current Agave/Firedancer with XDP; lagging networking is how you lose on larger blocks.

Do design for account contention the way you always should: shard state when you can, avoid single global writable counters on the hot path, watch write locks. The 12M wall is still the local speed limit.

What comes next: SIMD-0306

SIMD-0306 (Brennan Watt / Anza, status Review) targets the writable account limit directly. The design sets max writable account CUs to 40% of max block CUs — so at a 100M block that is 40M account write CUs (up from a static 12M).

If SIMD-0306 ships as written (40% of block CUs):

Block max CUs     Writable account max CUs
50M               20M
60M               24M
100M              40M   ← the interesting row for mainnet today

Motivation in the SIMD: the network is already bumping the 12M per-account ceiling in practice; unlocking it is how hot markets absorb more economic activity after client performance improvements. Until that lands, treat 100M blocks as the parallel scale-up and 12M as the serial hot-spot cap.

Mental model

                    ┌─────────────────────────────┐
   one block        │  100M CU global budget       │
                    │                             │
   parallel OK  ───►│  many accounts, many txs    │
                    │                             │
   still capped ───►│  any ONE writable account   │
                    │  ≤ 12M CU writes            │
                    └─────────────────────────────┘

100M helps:  breadth (more independent work per slot)
12M gates:   depth (how hard you can hit one account)

Quick FAQ

Do I redeploy programs? No.

Will my priority fees drop? Often, for the same burst, yes at the margin — more supply. Not a promise for every slot.

Why did my AMM still feel congested? Check whether you were account-bound (12M) rather than block-bound (now 100M).

Where do I watch packing? ultrasoundsol; RPC side-by-side latency at solana.com/data.

Resources

• Foundation upgrade page — 100M CU blocks
• SIMD-0286 · SIMD-0256 · SIMD-0306
• XDP on Solana
• ultrasoundsol — block CU usage
• Colosseum Codex roundup (context)
• Agave / Anza · Stake program ops

Bottom line

100M CU blocks are a real throughput unlock — about two-thirds more global work per slot, bought with client performance and XDP, free for application code. They are not a free pass for single-account congestion. Design and monitor against the 12M writable account wall until SIMD-0306 (or something like it) moves that line. Ask one question when the chain feels “full”: full block, or full account? The answer decides whether this upgrade already fixed your week — or whether you are waiting on the next SIMD.