Solana cuts slot time to 350ms for first time since network launch

Average slot times were running at around 360ms at the time of writing, according to Solana’s slot time explorer, compared with the network’s original 400ms target.

The change is the first step under SIMD-0525, a Solana improvement proposal that introduces four progressively shorter slot configurations at 350ms, 300ms, 250ms and 200ms. The proposal was approved and merged on May 14.

Rather than moving immediately to the final target, Solana plans to activate each reduction separately, giving validator operators and client developers a chance to test network behavior as block production becomes faster.

Solana slot time starts its move toward 200ms

The Solana Foundation said in June that reducing slots from 400ms to 200ms would lower latency and allow confirmations to reach users faster.

Under SIMD-0525, the first feature gate changes the slot target to 350ms. Later activations would bring it to 300ms, then 250ms and finally 200ms.

All four stages are currently targeted for Agave v4.2, the validator client developed by Anza, although the rollout schedule remains tentative and can change depending on testing.

Shorter slots mean block-production opportunities pass between validators more frequently. SIMD-0525 keeps the network’s 64 ticks per slot and its four-slot leader window, but the amount of real time represented by each leader window falls with every reduction.

At the previous 400ms target, four slots gave a leader a nominal 1.6-second window. A 350ms slot cuts that figure to 1.4 seconds, while 300ms would lower it to 1.2 seconds. At the final 200ms target, a four-slot window would last around 800ms.

The proposal says reducing the amount of time controlled by one leader can also reduce the period during which transactions could be delayed or reordered before another validator receives the opportunity to produce blocks.

SIMD-0525 does not simply allow the network to perform twice as much work after moving from 400ms to 200ms. Resource limits are adjusted proportionally as slot duration falls so that processing demands over a given period do not rise solely because more slots are being produced.

At the original 60 million compute-unit baseline used in the proposal, the per-slot limit would fall to 52.5 million CUs at 350ms, 45 million at 300ms, 37.5 million at 250ms and 30 million at 200ms.

Faster slots change confirmations and epoch timing

Confirmation latency is one of the main areas targeted by the change because Solana measures several parts of network operation in slots.

With validators moving through slots more quickly, slot-based confirmation thresholds can be reached in less real-world time. Applications that use slot numbers to determine how recent blockchain information is can also receive finer timing intervals.

SIMD-0525 identifies oracle users and automated market makers among applications that could benefit from the shorter intervals, particularly when decisions depend on the age of on-chain data.

Epoch duration will also fall because Solana plans to retain 432,000 slots per epoch.

An epoch with 400ms slots has a nominal duration of about 48 hours. The move to 350ms cuts that to roughly 42 hours, while 300ms would bring an epoch to about 36 hours. At 250ms, the figure falls to around 30 hours, before reaching roughly 24 hours if 200ms slots are activated.

Solana’s annual slot calculations are adjusted alongside the change so that protocol issuance remains based on real-world time instead of rising simply because more slots occur each year.

The Validator Admission Ticket proposed under Solana’s Alpenglow consensus system is also designed to scale as epochs get shorter. SIMD-0525 specifies that a 1.6 SOL cost per epoch at 400ms would decline to 1.4 SOL at 350ms, followed by 1.2 SOL, 1 SOL and 0.8 SOL at the subsequent stages.

The proposal says the adjustments are intended to keep the validator cost at roughly 0.8 SOL per day despite the shorter epochs.

Solana performance upgrades extend beyond slot times

The slot-time rollout comes while Solana developers are working on several changes to the network’s validator and consensus infrastructure.

As previously reported by crypto.news, Alpenglow entered community validator testing in May after Anza deployed the consensus design on a test cluster.

Alpenglow is designed to bring confirmation times to roughly 150ms while removing Proof of History and on-chain vote transactions from Solana’s core consensus process. Anza has called the planned upgrade the largest consensus change in Solana’s history.

The system introduces a voting design called Votor, which uses off-chain validator communication and signature aggregation to reach consensus. Its development is separate from SIMD-0525, although both projects focus on reducing the amount of time required for network operations.

Validator software has also become more diverse during 2026. Jump Crypto’s Firedancer mainnet rollout began producing blocks in May after years of development, providing an independently built alternative to Solana’s existing validator implementations.

Jump Crypto advised validators at the time not to migrate to Firedancer at scale until security audits had been completed. The client has been developed both to improve performance and to reduce the risk created when a blockchain depends heavily on one validator software implementation.

Later that month, Coinbase disclosed a multi-client setup using Jito and Firedancer across its Solana validator infrastructure. Its validator architecture supported approximately 40.48 million staked SOL at the time, or about 9.52% of the network’s staked supply, according to the exchange’s Q1 validator performance report.

Solana introduced another network-level change in July when it launched an on-chain governance framework that allows validators to take stake-weighted votes on Solana Governance Proposals. Under the new governance process, proposals that receive 15% initial support proceed through an 11-epoch process containing discussion, a stake snapshot and formal voting.

A proposal passes when votes in favor account for at least 66.67% of participating “For” and “Against” stake, while technical changes can still move through the existing SIMD process without first receiving a governance proposal vote.

The next slot reduction would bring Solana to 300ms

With the 350ms setting now active, SIMD-0525 identifies 300ms as the next stage in the sequence.

The change would reduce the nominal four-slot leader window from 1.4 seconds to 1.2 seconds and bring an epoch down from roughly 42 hours to 36 hours.

Further feature activations would then move Solana to 250ms and 200ms. Each configuration is calculated from the network’s baseline values instead of using the rounded limits from the previous stage, a design intended to prevent rounding differences from accumulating across successive reductions.

Testing of Solana’s infrastructure has continued while those stages are being prepared. During July, network activity also reached record levels as tokenized assets expanded on Solana, with tokenized stock activity contributing to increased usage across the chain.

For SIMD-0525, however, each remaining slot reduction still requires its corresponding feature activation. Following the newly activated 350ms setting, Creech identified 300ms as the network’s next target.