TLDR
-
Solana cuts its target slot time from 400ms to 350ms in its first major reduction.
-
The 350ms upgrade starts a four-stage plan that could eventually reach 200ms.
-
Solana developers have identified 300ms as the network’s next major slot target.
-
Shorter slots reduce confirmation latency and shorten Solana’s epoch duration.
-
Agave v4.2 is expected to support all four planned Solana slot-time reductions.
Solana has activated a 350-millisecond target slot time, starting the network’s first major reduction since launch. The change cuts the previous 400ms target and begins a planned four-stage performance upgrade. Developers have already identified 300ms as the next target under the same technical proposal.
Solana Starts First Slot Time Reduction
Solana Foundation technology vice president Jacob Creech confirmed the 350ms activation on August 21. Network data showed average slot times near 360ms after the new configuration became active. Previously, the blockchain operated around an original target of 400ms per slot.
Solana has officially reduced its slot time for the first time since its inception
We're in a new era of 350ms
Next stop, 300ms pic.twitter.com/GItTzfL6vB
— Jacob Creech (@jacobvcreech) August 21, 2026
The adjustment forms part of SIMD-0525, which establishes several progressively shorter slot-time settings. Developers approved and merged the proposal on May 14 after reviewing its technical requirements. The planned stages reduce target slot times to 350ms, 300ms, 250ms, and eventually 200ms.
Solana developers designed the staged rollout to test performance before activating each faster configuration. Therefore, validators and client developers can assess network behavior during every step. The approach also gives operators time to prepare infrastructure before block production becomes progressively faster.
Faster Slots Shorten Confirmation and Epoch Times
Shorter slots allow validators to receive block-production opportunities more frequently across the network. As a result, slot-based confirmation thresholds can occur within shorter periods of real time. Applications using recent blockchain data can also receive updated information at smaller time intervals.
The previous 400ms setting provided a four-slot leader window lasting about 1.6 seconds. Solana now reduces that period to about 1.4 seconds under the 350ms configuration. A future 300ms target would shorten the same leader window further to around 1.2 seconds.
Epoch duration will also decline because the blockchain will retain 432,000 slots within each epoch. Under 400ms slots, one epoch had a nominal duration of roughly 48 hours. The 350ms configuration lowers that duration to about 42 hours before further planned reductions.
Solana Targets 300ms Before Eventual 200ms Slots
Solana plans to move toward 300ms as the next stage under SIMD-0525. That setting would lower the estimated epoch duration from approximately 42 hours to 36 hours. Later activations would then introduce 250ms and 200ms slot targets.
The developers also adjusted resource limits to prevent shorter slots from automatically increasing processing demands. For example, the proposal lowers the per-slot compute limit as slot duration decreases. The limit falls from 60 million compute units toward 30 million at 200ms.
All four stages currently target activation through Agave v4.2, the validator client developed by Anza. However, developers can adjust individual activation schedules according to testing and network readiness. Each remaining reduction will also require its corresponding feature activation before deployment.
The upgrade forms part of broader work to reduce latency across Solana’s validator and consensus infrastructure. Faster slots could particularly support applications that depend on recent on-chain information, including oracles and automated market makers. Following the 350ms activation, the network’s next scheduled technical milestone remains the 300ms slot configuration
