Reduced Slot Times

Reduced Slot Times

Updated October 2026 • Solana Foundation

Solana's slot time is now 200ms, down from 400ms. All four staged reductions are active on mainnet; the final step took effect at the start of epoch 1053 on October 9, 2026. This change was first discussed in SIMD Discussion 469 and formally proposed and approved in SIMD-0525. This change makes the protocol more competitive in terms of latency. It takes advantage of the performance improvements made to Solana validator clients especially in Turbine, and Replay.

This also doubles as a censorship resistance measure since it narrows the time a leader has a monopoly over block building. Together with the separately proposed reduction of consecutive leader slots, this improves fairness for validators and users by limiting individual leader control windows.

Each 50ms reduction had its own feature gate and activated independently. The steps were spaced out to give core developers time to monitor cluster performance between activations. All four reductions are now active on mainnet, devnet, and testnet.

Technical Details

Slot Duration

Default slot duration is defined as the default number of milliseconds per tick (based on Solana's proof of history) multiplied by the default number of ticks per slot. Slot times were originally set at 400ms, which was industry-leading at the time it was implemented.

The decrease to 200ms did not change the ticks per slot, the leader span of four slots, or the slots per epoch.

This time gives ample chance for the other validators to replay the transactions within the block and vote on whether a block is valid and should be included in the chain.

Concurrently, the next leader is receiving transactions via Gulf Stream and has to complete its blocks within the same timeframe.

Slot-Derived Timing

Nothing here requires an application to migrate, but any code that converts slots into wall-clock time now converts at a different rate. Two things to be aware of:

Time inferred from slot numbers. A slot count multiplied by 400ms no longer describes elapsed time. Estimated timestamps, countdowns, and "time until slot X" calculations drift unless they read the current slot duration or use getBlockTime rather than a hardcoded constant.

Blockhash expiration arrives sooner. The window for blockhash expiration is still 150 blocks, but it passes faster in wall-clock terms. The original window was 60 seconds with 400ms blocks. With 200ms blocks, blockhash expiration is now 30 seconds. Offline signing flows that wait on human confirmation now have less slack time before the blockhash goes stale. See retrying transactions for the underlying mechanics.

Rollout Status

The rollout is complete: all four feature gates are live on mainnet. Each feature gate activated at the start of an epoch, and the new slot time took effect at the following epoch boundary:

Block skip rate was the gating criterion for each step: as agreed in the validator discussion, the network would not move to the next reduction if skip rates appeared to be too high. Track live mainnet slot times at solana.com/200ms.

Indexers need no format changes, but shorter slots mean more blocks in the same wall-clock time. At 200ms the network now produces twice as many blocks per day as it did at 400ms, so plan ingestion and storage capacity accordingly.

About This Upgrade

Decreasing slot times allows the network to be more competitive to other blockchain protocols. This change also sets a precedent for future latency improvements.

Users get faster confirmation times on their transactions. Market makers can quote tighter spreads.

Validators get shorter epochs, which means they are rewarded faster for adopting the performance improvements on mainnet. An epoch is a fixed 432,000 slots, so it now takes about 24 hours at 200ms, down from roughly 48 hours at 400ms.

Learn more: Solana Upgrades