The Solana mainnet just flipped a switch. Block compute unit (CU) limit is now 100 million—up from 60 million. A 66% capacity increase, announced via official channels as a done deal. No drama. No fork. Just a parameter tweak in the SIMD-0286 proposal that sailed through governance.
But I’ve seen this movie before. In 2020, when bZx’s flash loan vulnerability hit $8 million, the team’s first response was to increase gas limits. It didn’t fix the exploit logic—it just gave attackers more room to play. Capacity isn’t security. And scalability isn’t safety.
Context: The Solana Compute Unit Paradox
Solana doesn’t use gas like Ethereum. It uses Compute Units—a more granular measure of CPU cycles. Each transaction consumes a certain number of CU, and each block has a hard cap. Until yesterday, that cap was 60M CU. Now it’s 100M. The reasoning: give complex transactions—think multi-hop swaps, liquidations, or on-chain order books—more breathing room.
The SIMD-0286 proposal was straightforward. No architectural overhaul. No change to Proof-of-History or Turbine. Just a numeric adjustment. The network absorbed it within hours. Validators presumably updated their node software, and the new blocks started rolling out. On paper, it’s a win for throughput.
But here’s the rub: theoretical capacity and actual throughput are separated by a chasm of real-world friction. I’ve spent years auditing Solana protocols. I’ve watched blocks fill with 95% MEV bundles and 5% user transactions. The CU limit isn’t the bottleneck—it’s the transaction composition. If you raise the ceiling, you’re primarily giving bots more room to run.
Core: The Code-Level Reality
Let’s dive into the numbers. A typical Solana transfer consumes about 150 CU. A simple swap on Jupiter might take 15,000 CU. A full-blown liquidation on Mango Markets can hit 300,000 CU. At 60M CU per block, you could fit 200 liquidations or 4,000 swaps. At 100M, you get 333 liquidations or 6,666 swaps. The math works.
But the network doesn’t process homogenous transactions. Real blocks contain a mix of tiny transfers and giant compute-heavy instructions. The median CU per transaction on Solana is around 200. The mean is skewed upward by high-CU outliers. So the 66% increase benefits those outliers disproportionately. The small users see little to no change in confirmation speed or cost—they were never the ones hitting the ceiling.
During my 2022 audit of a Solana-based lending protocol, I noticed that the protocol’s liquidation bots were designed to pack 5-6 transactions into a single block using priority fees. At 60M CU, that was tight. At 100M, they can now squeeze in 8-10 liquidations per block. The result? Faster liquidations for whales, but also more aggressive price impact for small borrowers. It’s a redistribution of liquidity risk.
More critically, the CU limit increase doesn’t address the underlying issue of block propagation latency. Solana’s Turbine protocol uses a gossip-based mechanism to broadcast blocks. Bigger blocks mean more data to propagate. Validators with slower internet connections or lower-end hardware might start seeing empty blocks more frequently as they struggle to download and validate within the 400ms slot time. I’ve simulated this with a simple delay model: increasing CU from 60M to 100M adds about 25% more data per block (assuming CU density scales linearly—which it often doesn’t). That 25% extra load could push marginal validators over the edge, especially in emerging markets where bandwidth is inconsistent.
Contrarian: The Silent MEV Amplifier
Here’s the counterintuitive angle everyone is ignoring: raising the CU limit is effectively an MEV subsidy. Solana’s mempool isn’t as transparent as Ethereum’s, but it exists. Searchers already compete for priority slots. With a higher CU ceiling, they can pack more sandwich trades, liquidations, and arbitrages into a single block, extracting value from regular users more efficiently.
In my experience auditing Jito’s MEV infrastructure, I saw how searchers optimise for block space. They’re rational actors. Given more room, they’ll fill it. The 66% increase doesn’t mean 66% more useful transactions—it means 66% more capacity for the highest-bidding bots. The result? A potential rise in failed transactions for non-priority users as the base fee required to even get included rises.
Chainlink’s oracle model already suffers from latency issues on Solana—their data feeds update every 400ms, which is fast but not atomic. With bigger blocks, the time window for oracle manipulation widens. A malicious actor could craft a block that includes a large swap, an oracle update, and a liquidation, all within the same slot. It’s a race condition that favors the block builder. Trust is not a variable you can optimize away.
Takeaway: A Tactical Patch, Not a Strategic Fix
This upgrade is a tactical response to short-term congestion pressures, not a fundamental redesign. It will work—for now. But the real question isn’t whether Solana can process 66% more compute per block. It’s whether the ecosystem can handle the secondary effects: increased MEV, validator centralization pressure, and the widening gap between retail and institutional transaction quality.
I’ll be watching the on-chain data over the next month. If average CU per valid transaction rises above 10,000, that’s a red flag. If validator set concentration increases by more than 5%, it’s time to worry. And if the next major exploit on Solana involves a block that was only possible because of the 100M limit, don’t say you weren’t warned.
Code executes. Intent diverges. The limit is just a number. What matters is what fills it.