Solana’s 350ms Mainnet target is set to take effect in epoch 1020, down from the current 400-millisecond target slot time. The feature activated at the start of epoch 1019, but a one-epoch delay means the network keeps its existing parameters until the next epoch. In practical terms, blocks get a shorter target production interval without receiving a larger compute allowance per second.
The rollout is already further ahead elsewhere. Testnet is at an effective 200ms target, while Devnet is at 300ms and has activated its 250ms gate without making it effective yet. Solana’s Aug. 6 changelog had listed only the 350ms step on the two test clusters, showing how quickly the later stages have advanced.
Mainnet’s 350ms feature account activated at slot 440,208,000, the first slot of epoch 1019. Under the delay in SIMD-0525, Mainnet stays at an effective 400ms target through that epoch and shifts to 350ms in epoch 1020.
SIMD-0525 remains a draft. Feature activation shows that a specific cluster change is moving through the network, not that the full 200ms design has become an accepted final standard. The figures are also target timings, which are distinct from observed block production, confirmation latency and economic finality.
The arithmetic keeps the compute ceiling flat
The proposal’s defining constraint is that less work fits into each slot as slots get shorter.
Solana’s July 30 changelog reported that Mainnet had already activated a maximum block limit of 100 million compute units. SIMD-0525 shows how that 400ms maximum would compose with the slot-time stages: 87.5 million CUs at 350ms, 75 million at 300ms, 62.5 million at 250ms and 50 million at 200ms.
| Target slot | Example max block CUs | Theoretical max CUs per second | Four-slot leader window | 432,000-slot epoch |
|---|---|---|---|---|
| 400ms | 100M | 250M | 1.6 seconds | 48 hours |
| 350ms | 87.5M | 250M | 1.4 seconds | 42 hours |
| 300ms | 75M | 250M | 1.2 seconds | 36 hours |
| 250ms | 62.5M | 250M | 1.0 second | 30 hours |
| 200ms | 50M | 250M | 0.8 seconds | 24 hours |
Each row works out to approximately 250 million CUs of theoretical maximum block budget per second. Halving the target slot time therefore leaves the example’s block-compute ceiling roughly unchanged.
That ceiling is not a transaction-throughput forecast. Actual use depends on workload and network conditions, and the 100 million figure is a composition example for maximum block CUs rather than a universal baseline for every limit.
The proposal separately reduces per-slot account-write, vote, data-allocation, data-shred, coding-shred and partitioned-reward budgets. Its purpose is to create more frequent scheduling opportunities without quietly doubling the resources validators may be asked to process each second.
This distinction matters because a limit describes the most work a block may contain, not how much work every block will contain. Shorter target slots can change when transactions receive an inclusion opportunity even while the theoretical per-second compute allowance stays flat.
Solana would still assign four consecutive slots to each leader. At 400ms per slot, that produces a nominal 1.6-second leader window. At 200ms, the window falls to 0.8 seconds.
That shorter span reduces the time controlled by one leader. It also leaves less time to receive the previous block, replay it, build on it and land votes before the network moves on.
Validators therefore face tighter handoff and propagation margins. Vote and gossip events occur more often in the same wall-clock interval, while block packing and Turbine must enforce smaller, slot-aware budgets after each delayed transition. The staged design pairs its latency goal with a live coordination test at each step.
Epoch timing compresses as well. SIMD-0525 keeps each epoch at 432,000 slots, so the nominal duration falls from roughly 48 hours at 400ms to 24 hours at 200ms. The slot count stays fixed, but its wall-clock meaning changes.
The same compatibility problem extends to software outside the validator. Some SDK constants and off-chain assumptions remain tied to 400ms, so an application that estimates elapsed time by multiplying a slot count by 400ms can disagree with the cluster after a faster stage becomes effective.
RPC clients, explorers and other off-chain services may use slot distance to estimate freshness or elapsed time. The proposal’s longer-term direction is for software to obtain effective timing parameters from the cluster instead of treating a compile-time constant as permanent.
Alpenglow’s Validator Admission Ticket illustrates the economic version of that mismatch. The scaling in SIMD-0525 applies only if the dependent Alpenglow VAT mechanism is active. In that case, the proposed charge falls from 1.6 SOL per epoch at 400ms to 0.8 SOL per epoch at 200ms, preserving an approximately 0.8 SOL daily target. The available evidence does not establish that VAT collection is active on any cluster.
For Mainnet, the immediate change is 350ms in epoch 1020, not a jump straight to 200ms. Solana is trying to rotate scheduling opportunities sooner while keeping resource ceilings roughly constant. The remaining risk is whether validators and surrounding infrastructure can preserve their coordination margins as each stage shortens.
The post Solana is slashing per-block compute limits so its new 350ms speed boost doesn’t overload the network appeared first on CryptoSlate.
