Anza CEO Brennan Watt Proposes Raising Solana's Block Compute Limit From 50M Back to 100M CUs

Anza CEO Brennan Watt opened a discussion in the Solana SOL$109.73-0.4% improvement-documents repository on October 10, 2026, proposing to raise Solana's block compute limit from 50 million compute units (CUs) to 100 million. The post, titled "Increase Block Limits Again", appeared a day after 200ms slots went live on mainnet at epoch 1053. It is a discussion thread at the idea stage. No Solana Improvement Document (SIMD) pull request had been opened for it when we checked the repository on October 10, and the post names no activation date, feature gate address or validator client release.

Why Solana's block compute limit is 50M CUs at 200ms slots

A compute unit measures the processing work a transaction uses, and the block compute limit caps how much of that work fits in one block. SIMD-0286 raised the cap from 60M to 100M CUs on July 29, 2026, a change we covered when it activated at epoch 1009.

SIMD-0525, which Watt authored, then cut Solana's slot time from 400ms to 200ms in four steps between August 21 and October 9. Each step shrank the per-block limits in proportion, so that the work validators do per second stayed about the same. The SIMD-0525 text lists the resulting block limit at 200ms as 50,000,000 CUs once SIMD-0286 is counted, and Watt's post calls 50M the "baseline".

By our arithmetic, a 100M CU block every 400ms and a 50M CU block every 200ms both allow 250M CUs per second. A 100M CU block every 200ms would allow 500M CUs per second, twice the ceiling Solana had before the slot-time cuts began.

Average use sits below today's ceiling. Solana Compass network data shows transactions consumed between about 6.8 trillion and 8.5 trillion CUs a day from September 27 to October 9, 2026, which works out to roughly 78M to 99M CUs per second. The limit applies block by block, so a daily average says little about how often individual blocks fill during bursts of activity.

What Brennan Watt's proposal changes and what stays fixed

Watt's post asks for one change. "I propose only increasing the block CU limit while keeping other related params constant," he wrote, naming the shred limit and the single account CU limit as values that "do not increase". Shreds are the small packets a block is split into for transmission between validators.

He gave three reasons. Validators have "a lot of overall replay execution headroom", meaning spare capacity to re-execute blocks produced by others. There is less "linearized execution headroom", which he put at "20M CUs linearized for 200ms slots". And it is "not clear how much network bandwidth headroom we have before some NICs start redlining", a reference to validators' network cards.

The 20M figure matches the per-account write limit that the SIMD-0525 text lists for 200ms slots. Transactions that write to the same account cannot run in parallel, so that cap bounds how much work one busy account can take up in a block. Under the proposal a block could carry more work in total, while the share any single account can absorb would stay where it is.

Watt opened the post by saying that "skip rates look good, and slot times are reasonable" and that it is "time to run CUs back to 100M turbo speed". The post gives no skip-rate figure. Solana's upgrade page for the slot-time reduction says that block skip rate was the gating criterion for each of the four steps.

Five feature gates from 60M to 100M CUs

Watt proposes "a ladder of 5 feature gates" and lists six values: a "50M CU baseline", then 60M, 70M, 80M, 90M and 100M. Our reading is that 50M is the limit already in force and the five new gates are the 10M steps above it. Watt listed the same five numbers in a reply on X: "60, 70, 80, 90, 100".

A feature gate is a protocol change that validators switch on together at an epoch boundary. SIMD-0525 used four of them to step slot times down, and notes that epochs last about one day at 200ms slots. Watt's post does not say how far apart the five gates would be, or whether a skip-rate or other test would decide when the next one activates.

What has to happen before a 100M CU block limit

The thread sits in the repository's "SIMD Discussions" category. A change of this kind would still need a written SIMD, review and implementation in validator clients before any feature gate could activate. Watt's post does not mention a testnet plan, a client version or how the increase would be sequenced with Alpenglow, Solana's planned consensus upgrade.

Reaction so far is brief. At the time of writing on October 10 the discussion had one comment, "Ship it", from GitHub user topointon-jump. Jacob Creech, who works in developer relations at the Solana Foundation, wrote on X that "We halved the latency on Solana" and "Now it's time to double the capacity".