Solana's blocks get faster and smaller — why speed is not capacity

Solana's mainnet is scheduled to shorten its target slot time from 400 milliseconds to 350 in epoch 1020, and to cut the maximum amount of computation a block may contain by roughly the same proportion. Blocks arrive more often; the work allowed per second stays about flat. That combination is the whole story, and it is a useful correction to a common beginner assumption that faster blocks automatically mean more capacity.

The numbers come from SIMD-0525, still a draft proposal. Mainnet already activated a maximum block limit of 100 million compute units at the 400ms target. The proposal composes that limit with each slot-time step: 87.5 million compute units at 350ms, 75 million at 300ms, 62.5 million at 250ms and 50 million at 200ms. Every row works out to roughly 250 million compute units per second of theoretical ceiling. The proposal also trims per-slot budgets for account writes, votes, data allocation, data and coding shreds, and partitioned rewards.

The rollout is staged rather than instant. The 350ms feature account activated at slot 440,208,000, the first slot of epoch 1019, but a one-epoch delay keeps mainnet at an effective 400ms through that epoch. Test clusters are further along: testnet is at an effective 200ms target, and devnet is at 300ms with its 250ms gate activated but not yet effective. A feature activating means a specific change is moving through the network, not that the full 200ms design has become a settled standard.

The cost is coordination time. Solana assigns four consecutive slots to each leader, so 400ms slots give that leader a nominal 1.6-second window; at 200ms it falls to 0.8 seconds. Validators get less time to receive the previous block, replay it, build on it and land votes before the network moves on. Epochs shift too: the slot count stays fixed at 432,000, so a nominal epoch shrinks from roughly 48 hours at 400ms toward 24 hours at 200ms.

There is also a quiet compatibility problem for anyone building on or reading from Solana. Some SDK constants and off-chain assumptions are still tied to 400ms, so software that estimates elapsed time by multiplying a slot count by 400ms will disagree with the cluster once a faster stage takes effect, explorers, RPC clients and dashboards that use slot distance to judge freshness included. The proposal's direction is for software to obtain effective timing parameters from the cluster instead of treating a compile-time constant as permanent.

Three takeaways survive the details. A block limit describes the most work a block may hold, not how much every block will hold. Target slot time is not the same as the confirmation you actually experience, which also depends on propagation and finality. And a network can get faster on paper while its per-second capacity stays where it was. This is information, not advice.