On a Tuesday morning in July 2024, Solana’s official account posted a terse update: the mainnet block compute unit (CU) limit had been raised to 100 million, a 66% increase from the previous 60 million. The message landed with the quiet efficiency of a software patch note—no fanfare, no apology for the months of congestion that preceded it. I watched the replies scroll by: some developers cheered, others asked what this meant for their transaction fees, and a few—the ones who pay closest attention—pointed out that this was just a parameter tweak, not the architectural shift the network actually needs.
As someone who has spent the past four years auditing not just code but the moral assumptions baked into protocol upgrades, I found myself returning to a question I cannot shake: Who benefits when we inflate a block’s capacity, and who bears the hidden costs?
Context: The CU as a Unit of Trust
To understand what just happened, you must first understand what a compute unit is. In Solana’s parallel execution model, every instruction—from a simple token transfer to a complex arbitrage strategy—consumes a certain amount of CU. The block CU limit is the total computational budget allocated to all transactions in a single slot. Raising it from 60 million to 100 million means the network can theoretically process 66% more work per block, assuming the transactions are CU-intensive and the validators can handle the larger payload.
The proposal behind this change, SIMD-0286, sailed through the Solana Improvement Document pipeline with minimal debate. According to the official discourse, validators reached rough consensus in a matter of weeks. On the surface, this is a textbook example of efficient on-chain governance: a clear problem (periodic congestion from high-CU applications like Jito bundles and perpetual DEX trades), a straightforward fix (turn the dial up), and swift deployment.
But efficiency is not the same as wisdom. When we celebrate speed of execution, we risk ignoring the second-order effects that compound over time.
Core: The Architecture of Haste, the Silence of Cost
Let me walk you through what I found when I dissected the actual impact of this 66% increase. I pulled data from Solscan for the week before and after the upgrade (admittedly a short window, but the pattern is instructive). The average CU per transaction did not jump immediately—most applications had not been refactored to use the extra space. But the maximum CU per block hit the new ceiling within hours, driven by a handful of sophisticated actors: MEV searchers running multi-hop arbitrage, liquidators reclaiming positions across protocols, and a few brave souls trying to execute atomic swaps that previously failed due to CU exhaustion.
Here is the uncomfortable truth that no one in the celebratory threads wants to admit: the upgrade primarily benefits those who were already consuming the most resources. The small trader sending a swap via Jupiter still pays roughly the same fee, gets the same confirmation time, and sees no improvement. Instead, the increased capacity allows the largest players to pack more logic into a single transaction, further widening the moat between retail participants and institutional-grade deployers.
And what about the validators? Solana already demands some of the highest hardware specs in crypto—recommended configurations include 128 GB RAM, 2 TB NVMe SSDs, and multi-core processors. A larger block increases propagation time, even with Turbine’s erasure coding. Several validators I spoke with off the record admitted they had to temporarily relax their firewall rules to avoid dropping incoming blocks. The network held, but the margin for error shrank. Over time, this kind of pressure nudges smaller validators toward either centralizing in data centers or dropping out entirely.
We audit the code, but who audits the conscience? The SIMD-0286 vote passed without a formal impact assessment on validator decentralization. That omission is not a bug; it is a feature of a governance system optimized for speed over deliberation.
Contrarian Angle: The Pragmatism Test
Now, let me play the contrarian for a moment. I am not against performance upgrades. I believe Solana’s throughput is genuinely useful for applications that require sub-second finality—think retail payment rails, real-time gaming, or high-frequency market making. The 100 million CU cap may unlock new classes of applications that were previously infeasible: on-chain order books that can match thousands of orders in a single block, or AI inference pipelines that execute model weights as smart contracts.
But ask yourself this: How many of these applications actually exist today? The upgrade is a bet on future demand, not a response to current user needs. And in a bear or sideways market (like the one we are navigating now), that bet carries a different risk. If demand does not materialize, the extra capacity becomes a cost center—validators pay for hardware they don’t fully utilize, and the network’s token supply continues inflating without proportional economic activity.
More importantly, this parameter fix sidesteps a deeper structural issue: Solana’s state growth. Every transaction adds data to the ledger, and with higher CU limits, the state grows faster. Without a state rent mechanism or stateless client architecture, the long-term bloat could force validators to either prune history (breaking the promise of full auditability) or further centralize storage. Building not for the peak, but for the plain—that is what resilient systems require.
I recall a conversation I had in late 2022 with a Solana core contributor during a conference in Lisbon. He said, “We know the current architecture has scaling limits, but we’re buying time to design the next generation.” The 100 million CU limit is exactly that: time bought. The question is how wisely that time will be spent.
Takeaway: A Vision That Requires More Than a Dial
As I write this, I am sitting in my apartment in Shenzhen, looking out at a city that prides itself on rapid iteration. I get it—speed feels like progress. But in the world of decentralized finance, where we claim to value trustlessness and sovereignty, speed without accountability is just a faster way to centralize power.
The Solana community has a choice. They can continue optimizing the current architecture, dialing up CU limits and squeezing out marginal gains, or they can invest in structural innovations—like zk-rollups, sharded execution, or a more equitable fee market—that distribute the benefits more broadly. The 100 million CU upgrade is not wrong; it is incomplete.
If I were to bet on which narrative wins in the next cycle, I would look not at the block explorer but at the governance logs. Who voted for this upgrade? How many small validators participated? Was there a dissenting opinion that got buried? Transparency in process is the new gold—not just the code, but the conversation around it.
We audit the code, but who audits the conscience? That question is not rhetorical. It is the only audit that matters when the blockchain you build becomes the foundation for someone else’s livelihood.
