Solana has recently shortened its target slot time to 250 milliseconds, roughly 17% faster than the previous 300 milliseconds. The network’s total transaction processing capacity, however, has not risen with it. That is intentional: the amount of compute and data each slot can carry is scaled down by the same proportion.
SIMD-0525 maps a four-step move from 400ms to 200ms
According to SIMD-0525, a proposal put forward by Anza’s Brennan Watt, Solana is set to lower its target slot interval from 400 milliseconds to 200 milliseconds in four staged feature activations: 350 milliseconds, 300 milliseconds, 250 milliseconds, and finally 200 milliseconds. The network is currently at the third stage.
Each stage comes with a one-epoch delay when it is activated. The proposal states that if a switch is first enabled at epoch E, all slots inside that epoch must still use the previous block-time parameters. The stated purpose is to give network infrastructure such as Turbine time to prepare.
Per-slot limits are reduced in proportion
The central issue is how capacity is calculated. The proposal gives the scaling rule as trunc(value at 400 milliseconds × target slot milliseconds ÷ 400).
Using the proposal’s endpoint examples, at 400 milliseconds the limit for compute units in a single block is 60 million, the writable account limit is 24 million, the vote limit is 36 million, and the data-change limit is 100 million. At 200 milliseconds, those figures are cut in half to 30 million, 12 million, 18 million, and 50 million.
In practice, that means more blocks are produced each second, but each block carries less work. The two effects offset each other. Users get faster confirmation, not a larger throughput ceiling.
The proposal frames the change as a latency improvement
The motivation in the document is centered on latency. It says shorter slots “reduce user confirmation and finality latency” and give applications “a finer-grained understanding” of on-chain time. The proposal’s example points to oracle users.
The trade-off, then, is lower delay rather than more capacity.
Shorter slots also bring operational and security considerations
The proposal also lists risks. It says shorter slots “reduce the time available for leader handoff, block propagation, replay, and vote landing.”
Two additional security considerations are named in the document. Validators must correctly implement the one-epoch delay, and inflation-related code must use slot calculations equivalent to real elapsed time.
SIMD-0525 is still marked as a draft in the proposal repository.