100M CUs, 12M Hotspots: Solana’s Capacity Upgrade Is a Parallelism Upgrade

A bigger block, not a bigger transaction

On July 29, 2026, at the start of epoch 1009, Solana activated SIMD-0286 and raised the maximum compute units permitted in a block from 60 million to 100 million—a 66% capacity increase. It is a mainnet upgrade, not a proposal waiting to ship, and Solana describes it as non-breaking with no indexing changes required.

The developer takeaway is easy to miss: this is a block-level change. It expands the total work a leader can include in a block. It does not make a single transaction 66% larger, nor does it raise every other resource limit around that transaction.

The important non-change: hot accounts still stop at 12M

SIMD-0286 changes only the maximum block compute limit. The maximum writable-account compute limit remains 12M CUs, and the maximum block accounts-data-size delta remains 100 MB.

Limit	Before	After	Practical meaning
Maximum block compute	60M CUs	100M CUs	More aggregate work can fit in a block.
Maximum writable-account compute	12M CUs	12M CUs	One heavily written account still has the same per-block ceiling.
Block accounts-data-size delta	100 MB	100 MB	The upgrade does not enlarge this state-growth limit.

That is why the upgrade is chiefly about parallel capacity. Under the old ceiling, a single 12M-CU hot account could represent up to 20% of a full block; at 100M CUs, it represents 12%. If that account reaches its limit, the remaining theoretical space for unrelated activity rises from 48M to 88M CUs. That arithmetic is not a latency guarantee, but it captures the design intent: one crowded account should consume less of the block available to unrelated accounts.

What application teams should do

1. Do not plan a transaction-budget increase. Keep measuring and simulating transaction compute as usual. The upgrade gives blocks more aggregate room; it is not a reason to inflate the compute requested by an existing transaction.

2. Profile write concentration. A program whose peak activity repeatedly writes one pool, vault, market, mint, or global state account can still encounter the unchanged 12M-CU ceiling. Capacity gains will be most visible when work can proceed across independent writable accounts.

3. Consider sharding only where the application’s semantics allow it. Partitioning independent markets, users, or buckets can reduce a genuine write hotspot. But do not split state merely to chase throughput if the application requires atomic global ordering or shared invariants; correctness comes first.

4. Load-test read and data pipelines. Solana says RPC providers, indexers, and exchanges should verify their systems against sustained 100M-CU blocks, even though block data formats do not change. Teams that replay blocks, ingest transactions, or build slot-based batch jobs should test their throughput and catch-up behavior accordingly.

5. Treat capacity as headroom, not a service-level promise. The Solana Foundation reports that, between the 60M activation on July 22, 2025 and this increase, 11.2% of blocks used at least 56M CUs. The new limit is therefore relevant during real demand spikes, but an individual transaction can still be constrained by its own compute use and by contention on the accounts it needs to write.

The architectural shift to make

For developers, the useful mental model is not “my program got 66% more power.” It is “the network can accommodate more independent work beside my program.” A congested shared account remains a bottleneck; a workload spread safely across distinct accounts has more room to land during busy periods.

That makes state topology a first-class performance decision. Keep shared writable state deliberately small, identify the accounts that attract peak traffic, and design independent flows so they can remain independent. Solana’s 100M-CU upgrade rewards that discipline while preserving the safeguards intended to keep a single account from monopolizing an entire block.