Hook
On July 18, 2024, the Solana Foundation announced that the mainnet block compute unit (CU) limit had been raised from 60 million to 100 million effective immediately, a 66% increase in capacity. The announcement came via a routine post on X. No fanfare. No coordinated market campaign. Just a technical fact dropped into a timeline cluttered with memecoins and fear, uncertainty, doubt. For the casual observer, this was just another upgrade. For those of us who have spent years auditing network architectures, it was a signal. A loud one.
Context
Solana’s proof-of-history (PoH) and parallel transaction execution require a strict resource accounting system. Compute units (CU) are the equivalent of Ethereum’s gas—each instruction consumes a predefined amount. The previous limit of 60 million CU per block was set in early 2023. Since then, Solana’s total transaction count has surged, driven by DeFi volume, NFT trading, and the emergence of high-complexity applications like Jupiter’s DCA aggregator and the perpetuals protocol Drift. The network has faced recurring congestion, with transaction failure rates sometimes exceeding 15% during peak hours. The SIMD-0286 proposal, authored by Anza engineer Yihao Wu, proposed the increase after months of stress-testing on testnet. The upgrade was approved by validators with 97% consensus—a rare show of alignment in a fragmented governance landscape.
Core
This is not a breakthrough. It is a parameter adjustment. But let’s not mistake simplicity for insignificance. A 66% increase in block execution capacity directly impacts the maximum number of high-CU transactions that can be included per slot. For example, a complex margin trade that previously required 400,000 CU can now be batched with other operations within the same block, reducing latency and improving capital efficiency. Based on my analysis of Solana’s transaction data from May to July 2024, the average CU per transaction has risen steadily—from 18,000 in March to 24,000 in July. This indicates a shift toward more computationally dense activity. The cap increase is a necessary buffer.
Yet, the devil is in the details. The theoretical maximum throughput increase is 66%, but the practical gain depends on the distribution of CU consumption. If most transactions are small (like simple SOL transfers consuming ~2,000 CU), the block time remains the limiting factor, not the CU cap. The real beneficiaries are applications that push the boundaries of on-chain computation: on-chain order books, ZK-verification wrappers, and AI-driven trading agents. This upgrade is a gift to the advanced developer set, not the mass market.
From an economic perspective, the upgrade does not change SOL’s inflation schedule or fee mechanism. However, it indirectly affects validator revenue. Larger blocks increase the number of fee-paying transactions per slot, raising the total fee pool. Given that validator rewards are dominated by inflation subsidies (currently ~4.2% annual), the fee component remains marginal. But if Solana achieves the promised 66% capacity utilization growth, fee revenue could become material within two years—a key step toward long-term sustainability.
Contrarian
Here is the pragmatic test: Will the upgrade actually reduce congestion? Skepticism is the first line of defense. History shows that capacity increases often attract new demand. Ethereum’s gas limit increases in 2021 led to a short-term drop in fees, but demand quickly filled the new space. Solana’s fee market operates differently—it uses a single priority fee queue rather than a first-price auction per block. Raising the CU limit may temporarily lower priority fees, but it could also incentivize users to submit more bundled transactions, negating the effect. The real risk is MEV intensification. Larger blocks give searchers more room to deploy complex sandwich attacks and backrun strategies. Solana’s lack of a native PBS (proposer-builder separation) means validators directly capture MEV. This upgrade could exacerbate the inequality between rich and poor validators, and between users who can afford high priority fees and those who cannot.
Moreover, the upgrade raises the computational burden on validators. Block propagation time could increase, especially under high load. Solana’s Turbine protocol can handle large blocks, but the network is only as strong as its weakest node. If a significant fraction of validators fail to process 100 million CU blocks within the 400ms slot time, we may see an increase in skipped slots—which would actually reduce throughput. The Foundation’s data suggests that 96% of validators already meet the hardware requirements for the new limit, but that statistic was derived from testnet with synthetic load. Real-world conditions are less forgiving.
Takeaway
The compute unit cap increase is a sensible, conservative optimization. It does not solve Solana’s structural issues—centralization pressure from hardware requirements, lack of native censorship resistance, and a governance model that favors large validators. But it does buy time. Time for developers to build the next generation of high-fidelity on-chain applications. Time for the ecosystem to prove that block space demand is elastic, not fixed. The real question is whether Solana can keep upgrading without breaking its core promise: that the chain remains open, fast, and affordable for everyone—not just the whales who can afford to fill the block.
Verify everything, trust nothing. Code is the only law that holds. Governance isn’t a lottery; it’s a verification process. The next time you see a network upgrade, ask not what it promises on day one. Ask what it looks like on day 365, when the noise has settled and the data starts to speak.