The draft cuts per-slot limits as slots shorten, squeezing leader handoffs and off-chain timing without raising the theoretical CU-per-second ceiling.
olana'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.
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.
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.
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.