Solana Cuts Block Time to 350 Milliseconds on Mainnet, Targets 200 ms
Key Takeaways
- •Solana's mainnet block interval now stands at 350 milliseconds, the fastest recorded since launch, after the May approval of technical proposal SIMD-0525.
- •The change lowers latency by shortening leader rotation from 1.6 seconds to 1.4 seconds, but does not increase the number of transactions that fit in each slot.
- •Solana plans a staged path to 200-millisecond block times in four 50-millisecond steps, each activated by a Feature Gate and tied to a 432,000-slot epoch, with delays possible if conditions such as skipped blocks worsen.
- •Improvements to Turbine's block propagation and the Replay system used by validators to verify and vote on blocks made the shorter slots feasible.
- •The slot reduction is separate from Alpenglow, a consensus protocol designed to cut transaction finality from roughly 12.8 seconds to about 100-150 milliseconds while tolerating 20% malicious and 20% offline validators.

Solana has reduced the time between blocks on its mainnet to 350 milliseconds, the fastest block interval recorded since the network launched, as developers continue work toward a further reduction to 200 milliseconds. The update was detailed in Solana's announcement on X and follows the approval of the technical proposal SIMD-0525 in May, a change designed primarily to reduce network latency rather than increase throughput.
How the Slot Reduction Works
Solana divides time into short intervals known as slots, and during each slot a designated validator, known as the leader, produces a block. Because each leader is assigned four consecutive slots, cutting the slot time from 400 milliseconds to 350 milliseconds shortens the leader rotation interval from 1.6 seconds to 1.4 seconds. Should the network eventually reach the 200-millisecond target, each leader would control four slots for a total of 0.8 seconds.
The shorter slots are intended to allow transactions to move through the network more quickly, which could improve the user experience for decentralized applications, payments, and decentralized finance. However, the change does not increase the number of transactions that can fit within a single slot, meaning the adjustment is primarily a latency improvement rather than a throughput increase.
Shorter leader rotations could also reduce the amount of time any individual validator controls block production. Solana developers argue that this could limit opportunities for validators to deliberately delay or selectively filter transactions, potentially improving the network's resistance to censorship.
A Four-Step Path to 200-Millisecond Block Times
Solana plans to reduce block time in four 50-millisecond steps, moving from 400 ms to 200 ms. The network will use a Feature Gate to activate each reduction, allowing developers to monitor stability before advancing to the next stage. Each change is tied to a subsequent 432,000-slot epoch and can be postponed if network conditions deteriorate, including if too many blocks are skipped.
Solana has pointed to improvements in Turbine, its block-propagation system, and in Replay, which validators use to verify and vote on blocks, as the factors that made the shorter slots possible.
Separate Track from Alpenglow
The shorter slot times are separate from Solana's work on Alpenglow, a new consensus protocol aimed at speeding up transaction finality. Solana currently takes roughly 12.8 seconds to reach finality, while Alpenglow is designed to reduce that to about 100 to 150 milliseconds.
Unlike shorter slots, which reduce the interval between block-production opportunities, Alpenglow is intended to improve the consensus process itself. Its proposed design is also intended to maintain finality if 20% of validators are malicious and another 20% are offline.
Because slot timing changes and finality changes affect different parts of the network, they are being developed on separate tracks. That distinction matters for users and developers watching Solana's execution layer and consensus layer evolve in parallel, since the practical effect of faster block production is not the same as faster finality.
Together, the upgrades point to continued work on making the network more responsive without changing the core constraint that block capacity remains the same per slot. For applications that depend on quick confirmation feedback, the timing details are part of how Solana is positioning its infrastructure as it iterates on both performance and resilience.