Reduced Slot Times

Reduced Slot Times

Updated September 2026 • Solana Foundation

Solana is reducing its slot times from 400ms to 200ms. The first two staged reductions are now active on mainnet, bringing slot time to 300ms. This change was first discussed in SIMD Discussion 469 and formally proposed and approved in SIMD-0525. This change will make 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 has its own feature gate and activates independently. The steps are spaced out to give core developers time to monitor cluster performance between activations. The 350ms and 300ms reductions are active on mainnet. The final two feature activations of 250ms and 200ms have already been activated on devnet and testnet but have not been scheduled for mainnet.

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 will 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 approximately 80 seconds with 400ms blocks. With 300ms blocks today, blockhash expiration is about 60 seconds. When 200ms blocks are activated, the window will be roughly 40 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 partially activated on mainnet:

Activation dates for the 250ms and 200ms reductions are still being determined by core developers. Block skip rate is the gating criterion: as agreed in the validator discussion, the network will not move to the next reduction if skip rates appear to be too high.

Indexers need no format changes, but shorter slots mean more blocks in the same wall-clock time. At 200ms the network 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 will experience faster confirmation times on their transactions. Market makers will be able to quote tighter spreads.

Validators will enjoy 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 takes about 36 hours at today's 300ms, down from roughly 48 hours at 400ms, and will take about 24 hours once 200ms activates.

Learn more: Solana Upgrades