Solana Raises Its Block Compute Limit 66% to 100M Units

Solana raised the maximum amount of computation permitted in a single block by 66% on July 29, lifting the ceiling from 60 million compute units to 100 million at the start of epoch 1009. The change arrived through SIMD-0286, a proposal authored by Lucas Bruder of Jito and first put forward in May 2025, after running on devnet and testnet. The case for it was congestion: roughly 11% of blocks were bumping against the 60 million ceiling during periods of peak demand, according to Crypto Briefing. Slot timing did not change, so the network now allows substantially more work inside the same interval. The upgrade brought no breaking changes for developers or for the indexers that read chain data.

The Unit: What a Compute Unit Actually Counts

A compute unit is Solana's meter for computational work: every instruction a transaction executes carries a set cost in units, and each transaction declares a budget before it runs. The block limit is the sum of all that metered work the network will accept in one slot, the roughly fixed interval in which a single validator is scheduled to produce a block. When the ceiling binds, transactions that do not fit wait for a later block, which is what users experience as congestion. Raising the ceiling to 100 million units does not make any individual transaction cheaper or faster; it widens the door. Two other limits were deliberately left alone: the cap of 12 million units on how much compute a single account can consume within one block, and the 100 MB limit on the raw data size of a block.

The Trade-off: The Same Slot, More Work Inside It

Every validator has to execute and verify the blocks other validators produce, and it has to finish before the next slot arrives. Because slot timing was untouched, the peak amount of work a node must get through in that fixed window rises by the same 66%. That is where the cost lands: machines that were only just keeping pace with 60 million units have less headroom at 100 million, and a node that cannot keep up falls behind the rest of the network rather than simply running slower. The effective hardware floor moves up whenever the ceiling does, which is why increases of this kind are staged through devnet and testnet first.

The Prerequisite: Networking First, Then Capacity

Compute is only one bottleneck. Bigger blocks have to be moved between validators as well as executed, and if the networking layer cannot keep up it becomes the new constraint the moment the compute one is relaxed. That is why adoption of XDP, a faster path for handling network packets, was treated as the gating condition: more than 70% of validators had taken it up before the block limit was raised. XDP moved from opt-in to on by default in the Agave 4.2 client release, part of the same run of releases that put Firedancer v1.1.0 on testnet in mid-July. The order has been consistent: client and networking work first, then the parameter change.

What Comes Next: Two Larger Changes Still Queued

The compute increase is a parameter change, and the structural work sits ahead of it. The Validator Admission Ticket went live on mainnet on July 22, requiring validators to register a BLS public key or be silently left out of the leader schedule and counted as zero stake for consensus; at epoch 1004 roughly 85 validators representing 3.87% of stake had produced blocks while still unregistered. That first activation only checks that a key exists and caps the admitted set at 2,000 validators by stake, leaving the 1.6 SOL per epoch admission fee, vote-fee payments and the removal of on-chain voting to arrive with Alpenglow, the consensus change targeted for the fourth quarter of 2026. Further out sits research into composing consensus instances in parallel, aimed at the same bottleneck from the other direction — shortening the interval rather than enlarging what fits inside it. The open question now is how much of the new headroom real demand takes up, and how fast.