Solana Mainnet Implements First Slot-Time Reduction to 350ms

Solana’s mainnet is producing blocks faster after its first staged slot-time reduction moved the network’s target from 400 milliseconds to 350 milliseconds.

Faster slots shorten block-level feedback and confirmation thresholds measured in slots, while throughput depends on a separate set of limits.

The Solana Foundation confirmed the mainnet change after the feature gate activated at slot 440,208,000, the first slot of epoch 1019. A feature gate is the switch validators use to coordinate a protocol change, and under the one-epoch delay required by SIMD-0525, the new timing applied when epoch 1020 began on Aug. 21.

A slot is the window in which a designated validator can produce a block, while an epoch is a fixed period of 432,000 slots.

Trillium, a Solana validator-telemetry provider, measured a slot-weighted mean of 365.4ms across 431,505 timed slots in post-change epoch 1021. Its view of pre-change epoch 1015 recorded a 420.7ms mean.

The same dataset recorded 331 skipped slots in epoch 1021, or 0.077%, compared with 1,890 skips and 0.438% in epoch 1015. The lower post-change reading offers an early stability signal across those two epochs, though the comparison cannot establish that the timing cut caused the change.

What faster slots change

Shortening the slot window reduces the wall-clock time for confirmation thresholds measured in slots. It also cuts the four-slot leader window from a nominal 1.6 seconds at 400ms to 1.4 seconds at 350ms, narrowing the period one block producer controls.

The proposal keeps four slots per leader and 432,000 slots per epoch. It scales per-slot compute, account-write, vote, data, and shred limits down with each shorter target. Blocks arrive more frequently and carry smaller budgets, leaving approximate work capacity per second broadly unchanged.

The 365.4ms telemetry reading measures observed spacing between slots, and it also supports faster block-level feedback, while finality remains a separate metric.

Solana’s official upgrade roadmap calls for distinct steps to 300ms, 250ms, and eventually 200ms. Each feature gate carries a one-epoch delay so validators can apply the timing and reduced shred limits together.

The 300ms stage remained pending as of Aug. 26. Solana Compass reported that Anza CEO and SIMD author Brennan Watt said it was intended to become effective at epoch 1024, around Aug. 28.

Solana’s roadmap says the network can pause between stages if skipped-block rates climb, making the 350ms stage a live test of how much validator timing can tighten before the path to 200ms continues.