On July 29, 2026, Solana activated SIMD-0286 on its mainnet, an upgrade that raises the maximum work that fits in each block from 60 to 100 million units. In practice, each block now has 66% more capacity to process transactions, without changing the 400 milliseconds it takes to produce one. Below, we explain what those compute units are, why the limit has been raised now, and what it implies for the network.
What Is a Compute Unit and Why It Measures a Block’s Capacity
Compute units (CU) are how Solana measures the computational cost of processing transactions. Think of them as seats on an airplane: each instruction within the network—a transfer, a DeFi operation, or an oracle write—spends a certain amount of CU or “seats.” Each block has a maximum capacity budget.
Before this upgrade, the airplane had 60 million seats, and when that budget ran out during activity peaks, the remaining transactions had to wait for the next one. Now the airplane has 100 million seats, allowing more transactions to fit in each block without being left on the waiting list.
It is important to clarify that measuring the limit in compute units is not the same as “transactions per second” (TPS) , as the final TPS depends on the individual complexity of each operation and other network factors.
During calm periods, 60 million CU provided plenty of margin, but during high-demand moments, that ceiling acted as a bottleneck. Although the network implemented SIMD-0256 to raise the limit from 50 to 60 million CU, developer pressure continued to increase, making this new capacity jump necessary.
Why the Limit Has Been Raised Now and Not Before
The increase responds to the growing demand from applications such as DEX, restaking, and MEV. According to the Solana Foundation, 11.2% of blocks were nearing saturation by exceeding 56M CU during traffic peaks, causing transaction failures and higher fees.
The key moment came after validating Lucas Bruder’s (Jito Labs) proposal on devnet and meeting an essential condition: that more than 70% of the stake operated with XDP. This technology accelerates data propagation between validators, allowing capacity to be expanded to 100M without creating network bottlenecks.
What Changes for the Network and What Does Not
|
What DOES change |
What DOES NOT change |
| Total capacity: More transactions fit per block (+66%). | Generation time: Remains at 400 ms per slot. |
| Peak margin: Fewer failures due to congestion during high-traffic periods. | Per-account limit: Remains at 12M CU maximum per writable account. |
| App operation: DeFi protocols and oracles can aggregate operations more smoothly. | Compatibility: Zero code changes required for existing dApps. |
Maintaining the individual per-account limit at 12M CU while raising the total to 100M aims to ensure that the extra capacity is distributed across many different applications and prevents a single dApp or bot from absorbing all the block space.
What Sustains Such a Decision in a Decentralized Network
Behind this jump, there is not a single precept but a process of technical governance and community consensus. Proposed in May 2025 by Lucas Bruder, the SIMD-0286 improvement was prudently tested on testnet and devnet before reaching the mainnet.
Going directly from 60M to 100M CU was possible thanks to the accumulated progress in validator clients and the prior adoption of XDP by more than 70% of the stake.
For the average user, the change is completely invisible: the wallet works the same, but the network responds more smoothly. This demonstrates how a decentralized blockchain evolves through open proposals, technical validation, and coordinated deployment. Now the question is no longer whether the network can scale, but how long it will take for demand to approach the new ceiling.
FAQ
- What is Solana’s SIMD-0286 upgrade?It is a mainnet change that raises the compute limit per block from 60 to 100 million units, increasing its capacity by 66%.
- Does this improvement affect block confirmation time? The network’s speed remains intact, processing one block every 400 milliseconds.
- What direct benefit does this upgrade bring to the user?It reduces congestion during high-traffic periods, preventing failed transactions and increasing the overall smoothness of applications.
- Do developers need to adapt their dApps’ code? The improvement is fully compatible with the current infrastructure and does not require modifications to existing code.