Solana boosted block capacity 66%, but traders still hit the same wall

Solana block capacity rose from 60 million to 100 million compute units on July 29, a 66.7% increase that gives unrelated transactions more room without changing the separate cap governing its busiest accounts.

Compute units, or CUs, measure computational work performed by transactions. The block limit caps the aggregate CUs a leader can include before the block is full.

The on-chain feature account identifies SIMD-0286 as active at slot 435,888,000, at the start of epoch 1009, while the activation block timestamps that slot to July 29. The change raised the block limit by 66.7% mathematically, which the Solana Foundation presents as 66%.

The Solana Foundation said 11.2% of blocks produced between the July 22, 2025 activation of the 60 million-CU limit and the latest increase used at least 56 million CUs.

Why Solana block capacity still leaves a hot-account bottleneck

SIMD-0286 changed only the overall block limit. The maximum compute that can write to any single account within a block remains 12 million CUs, while the maximum block accounts-data size delta remains 100MB. In this context, a hot account is shared writable state that many transactions try to update, not necessarily one trader’s wallet.

The capacity increase creates more room for parallel activity. Transactions touching unrelated accounts can use the additional 40 million CUs, allowing a busy account to crowd out less of the rest of the block. Under the former ceiling, one account’s 12 million-CU allowance represented 20% of the block. It now represents 12%.

The same math does not give a congested market more capacity. If many trades need to write to the same account, they still compete within the 12 million-CU allowance. A state-heavy workload can also encounter the separate 100MB data-delta limit even when block compute remains available.

The Solana block capacity increase does not directly resolve fee pressure. Solana’s fee documentation says an optional prioritization fee depends on a transaction’s requested CU limit and CU price and raises its likelihood of being scheduled. The higher block ceiling alone does not show that priority fees fell for transactions targeting the same hot state.

More capacity also does not equal measured performance. The technical proposal warns that larger blocks can take longer to execute, slow network progress and validator catch-up, and may cause unforeseen issues for infrastructure beyond validators. Those are design risks, not reports of a current incident.

One Aug. 2 block recorded 25,373,012 consumed CUs, 1,328 processed transactions, and 1,069 successful transactions. One block cannot establish network-wide outcomes or a before-and-after change.

The official upgrade materials offer no post-activation before-and-after measurements for transaction inclusion, fees, block propagation, or replay. The upgrade therefore establishes a higher theoretical ceiling for aggregate work. It does not, by itself, demonstrate 66% more observed throughput or eliminate the local bottleneck that traders encounter when demand converges on the same account.