Solana reduces block times by 17% to 250 milliseconds

Solana’s network just got meaningfully quicker, though not in the way casual observers might assume. On September 18, 2026, the network activated a reduction in its target slot time from 300 milliseconds to 250 milliseconds, coinciding with the start of epoch 1037. That brings block production to four slots per second, up from roughly 3.3 slots per second before the change.

The upgrade is the fourth stage of SIMD-0525, a phased proposal to progressively tighten Solana’s block cadence. The end goal is 200 milliseconds per slot.

Speed without extra capacity

Here is the counterintuitive part: faster blocks do not mean more transactions per second. To keep the network stable, Solana proportionally scaled down the compute and data limits per slot alongside the timing change. Maximum compute units per slot dropped to 37.5 million, down from a baseline of 60 million, and data shred limits were adjusted in the same direction.

The practical benefit is not raw throughput but data freshness: prices, account states, and blockhash windows all update more frequently, which matters enormously for applications that depend on current information.

The epoch duration shrank as well. At 250 milliseconds per slot, Solana’s epoch now runs approximately 30 hours, down from around 36 hours. That affects validators, staking reward distribution, and any protocol that anchors timing to epoch boundaries.

A staged rollout with a clear roadmap

SIMD-0525 has moved in deliberate steps rather than a single leap. The first mainnet reduction brought slot times to 350 milliseconds on August 19, 2026. The second brought them to 300 milliseconds on August 25, 2026. The September 18 activation is the fourth stage, which means there was a third step between late August and mid-September.

The final target of 200 milliseconds has already been trialed on both devnet and testnet. What stands between that milestone and mainnet activation is the block-skip rate: Solana’s validators occasionally miss their assigned slot, and at tighter timing windows, the tolerance for that behavior narrows. The core development community wants to confirm that the skip rate stays within acceptable bounds before pushing the final reduction live.

Leader control windows also tightened with this change, dropping to 1 second from 1.2 seconds. Validators have less time to broadcast their blocks, which is one of the variables that influences skip rates.