Reduced Slot Times
Updated October 2026 • Solana Foundation
Solana is reducing its slot times from 400ms to 200ms. The first three staged reductions are now active on mainnet, bringing slot time to 250ms. 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, 300ms, and 250ms reductions are active on mainnet. The final 200ms reduction is already active on devnet and testnet and is scheduled to take effect on mainnet at epoch 1052.
| Expected Mainnet Activation Date | 350ms, 300ms, and 250ms live; 200ms at epoch 1052 |
| Devnet Activation | Live — all four reductions active, running at 200ms |
| Breaking Change? | No, but slot-derived timing changes |
| Indexing Changes Required? | No, but expect proportionally more block data |
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 250ms blocks today, blockhash expiration is about 50 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. Each feature gate activates at the start of an epoch, and the new slot time takes effect at the following epoch boundary:
| Feature Gate | SIMD-0525 Change | Status | Mainnet Slot Time Change |
|---|---|---|---|
iBRL5RuWhw4yqaAZu96RUULHckHTZAoe2b77qaV38JZ | Reduce slot time to 350ms | Live on Mainnet | August 21, 2026, epoch 1020 (slot 440,640,000) |
iBRLL3k18HST852F1Mf3Lv83waTNQmmqvKDxvYGwQFL | Reduce slot time to 300ms | Live on Mainnet | August 28, 2026, epoch 1024 (slot 442,368,000) |
iBRLMc81UjRa8fn8A6eE8bJTnRbgQoPTynM51akENCV | Reduce slot time to 250ms | Live on Mainnet | September 18, 2026, epoch 1037 (slot 447,984,000) |
iBRLjhJnkmDZgNoZRDMW11d8ZV7HvsL3vAyRjZB5npW | Reduce slot time to 200ms | Live on Devnet and Testnet | Scheduled for epoch 1052 (slot 454,464,000) |
Block skip rate is the gating criterion for each step: as agreed in the validator discussion, the network will not move to the next reduction if skip rates appear to be too high. Follow the final step live 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 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 30 hours at today's 250ms, down from roughly 48 hours at 400ms, and will take about 24 hours once 200ms activates.
Learn more: Solana Upgrades