Solana trims per-block compute limits for 350ms slots

Solana has reduced per-block compute limits on Mainnet to support a target slot time of 350 milliseconds. The feature account activated at slot 440,208,000, the first slot of epoch 1019, and the new parameters become effective in epoch 1020 after a one-epoch delay.

The change shortens the network’s target interval for block production from 400ms to 350ms while keeping the theoretical compute capacity per second roughly the same. To achieve that, the protocol lowers the maximum compute units allowed per block so shorter slots do not increase per-second resource demands.

Mainnet had previously set a maximum block limit of 100 million compute units at the 400ms target. Under the staged scaling in SIMD-0525, those limits would equate to about 87.5 million compute units at 350ms, 75 million at 300ms, 62.5 million at 250ms and 50 million at 200ms. The example composition yields roughly 250 million compute units per second across stages.

The staged rollout activated the 350ms feature at the start of epoch 1019 but preserves the 400ms effective target for that epoch. Testnet is running at an effective 200ms target. Devnet is at 300ms and has opened a 250ms gate that is not yet effective. SIMD-0525 remains a draft and later stages require further activation gates and coordination tests.

The update also tightens per-slot budgets for account writes, votes, data allocation, data shreds, coding shreds and partitioned rewards. Validators will continue to receive four consecutive slots as leader. At 400ms per slot the nominal leader window is 1.6 seconds; at 350ms it is about 1.4 seconds; at 200ms it would be 0.8 seconds. Shorter leader windows reduce the time available to receive the previous block, replay it, build on it and produce votes.

Validators and network services will face tighter handoff and propagation margins because vote and gossip events occur more frequently in the same wall-clock interval. Block packing, Turbine propagation and replay processes must enforce smaller, slot-aware budgets after each transition. The staged design pairs each latency reduction with a live coordination test for operators.

SIMD-0525 keeps the epoch slot count at 432,000, so epoch durations fall as slots get shorter: about 48 hours at 400ms, roughly 42 hours at 350ms, 36 hours at 300ms, 30 hours at 250ms and 24 hours at 200ms. Software that estimates elapsed time by multiplying slot distance by a fixed 400ms constant can produce incorrect time estimates after a faster stage becomes effective; RPC clients, explorers and SDKs should obtain timing parameters from the cluster.

The draft links to Alpenglow’s Validator Admission Ticket mechanism. If that mechanism is active, the proposal scales the charge from about 1.6 SOL per epoch at 400ms to about 0.8 SOL per epoch at 200ms to preserve an approximate daily target. Public evidence does not confirm whether VAT collection is active on any cluster.

For Mainnet users the immediate effect is limited to the 350ms target in epoch 1020. Further reductions in slot timing on Mainnet will depend on additional activation gates and coordination tests described in the draft.