Solana has lowered its target slot time from 400 milliseconds to 350ms, marking the first such reduction since the network launched and beginning a four-stage plan that could eventually bring slots down to 200ms.
Solana Foundation vice-president of technology Jacob Creech announced the change on 21 August, saying the network had entered “a new era of 350ms” before adding: “Next stop, 300ms.”
Average slot times were about 360ms when the change was announced, according to Solana’s slot time explorer. The figure compares with the network’s original 400ms target.
The first reduction is being introduced under SIMD-0525, a Solana improvement proposal approved and merged on 14 May. It sets out four progressively shorter slot configurations: 350ms, 300ms, 250ms and 200ms.
Rather than moving directly to the final 200ms target, Solana will activate each stage separately. The phased approach is intended to give validator operators and client developers time to test how the network behaves as block production accelerates.
The Solana Foundation said in June that reducing slot times from 400ms to 200ms would lower latency and enable confirmations to reach users more quickly.
All four stages are currently targeted for Agave v4.2, the validator client developed by Anza. However, the timetable remains provisional and could change depending on the results of testing.
Shorter windows and adjusted limits
Shorter slots mean opportunities to produce blocks move between validators more frequently. SIMD-0525 keeps Solana’s 64 ticks per slot and its four-slot leader window, but the real-world duration of that window becomes shorter at each stage.
Under the previous 400ms target, four slots gave a leader a nominal 1.6-second window. The new 350ms setting reduces that to 1.4 seconds. A 300ms slot would bring it down to 1.2 seconds, while the final 200ms configuration would leave a four-slot window lasting about 800ms.
The proposal says reducing the time controlled by an individual leader could also shorten the period in which transactions might be delayed or reordered before another validator has the opportunity to produce blocks.
However, the move from 400ms to 200ms does not mean Solana will simply process twice as much work. Resource limits are reduced proportionally as slots become shorter, preventing processing demands over a given period from increasing merely because more slots are being created.
Based on the proposal’s original 60 million compute-unit baseline, the limit per slot would fall to 52.5 million compute units at 350ms, 45 million at 300ms, 37.5 million at 250ms and 30 million at 200ms.
Confirmation latency is one of the principal targets of SIMD-0525 because several parts of Solana’s operation are measured in slots. As validators move through those slots more rapidly, slot-based confirmation thresholds can be reached in less real-world time.
Applications that use slot numbers to assess how recent blockchain data is could also gain more finely spaced timing intervals. The proposal specifically identifies oracle users and automated market makers as potential beneficiaries, particularly where decisions depend on the age of on-chain information.
Epochs will also become shorter because Solana intends to retain 432,000 slots in each epoch. At 400ms, an epoch has a nominal duration of about 48 hours. The 350ms stage reduces that to roughly 42 hours, while 300ms would bring it down to about 36 hours.
At 250ms, an epoch would last approximately 30 hours, falling to about 24 hours if the 200ms setting is activated.
Solana’s annual slot calculations will be adjusted at the same time so protocol issuance remains tied to real-world time, rather than increasing simply because more slots are produced each year.
The Validator Admission Ticket proposed under Solana’s Alpenglow consensus system is also designed to scale with the shorter epochs. SIMD-0525 says a cost of 1.6 SOL per epoch at 400ms would become 1.4 SOL at 350ms, followed by 1.2 SOL, 1 SOL and 0.8 SOL at the later stages.
Those changes are intended to keep the validator cost at about 0.8 SOL per day despite the reduction in epoch length.
Wider changes to Solana infrastructure
The slot-time rollout comes as Solana developers work on several changes to the network’s validator and consensus infrastructure.
Alpenglow entered community validator testing in May after Anza deployed the consensus design on a test cluster. It is intended to deliver confirmation times of about 150ms while removing Proof of History and on-chain vote transactions from Solana’s core consensus process.
Anza has described the planned upgrade as the largest consensus change in Solana’s history. It introduces a voting system called Votor, which uses communication between validators off-chain and signature aggregation to reach consensus.
Although Alpenglow and SIMD-0525 are separate projects, both are focused on reducing the time required for network operations.
Validator software has also become more varied during 2026. Jump Crypto’s Firedancer mainnet rollout began producing blocks in May following years of development, offering an independently built alternative to Solana’s existing validator implementations.
Jump Crypto advised validators 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 risks associated with a blockchain relying heavily on a single validator software implementation.
Later in May, Coinbase disclosed that it was using Jito and Firedancer in a multi-client setup across its Solana validator infrastructure. Its validator architecture supported approximately 40.48 million staked SOL at the time, representing about 9.52% of the network’s staked supply, according to the exchange’s Q1 validator performance report.
Solana also introduced an on-chain governance framework in July. The system allows validators to cast stake-weighted votes on Solana Governance Proposals.
Under the new process, proposals receiving 15% initial support enter an 11-epoch process involving discussion, a stake snapshot and formal voting. A proposal passes when votes in favour represent at least 66.67% of participating “For” and “Against” stake.
Technical changes can still proceed through the existing SIMD process without first receiving a governance-proposal vote.
With the 350ms setting now active, 300ms is the next step identified by SIMD-0525. That stage would reduce the nominal four-slot leader window from 1.4 seconds to 1.2 seconds and shorten an epoch from roughly 42 hours to 36 hours.
Further feature activations would then take Solana to 250ms and 200ms. Each configuration is calculated from the network’s baseline values rather than using rounded limits from the preceding stage, a design intended to prevent rounding differences from accumulating through the sequence.
Testing has continued as the remaining stages are prepared. Network activity also reached record levels during July as tokenised assets expanded on Solana, with tokenised stock activity contributing to increased usage across the chain.
For SIMD-0525, however, each remaining reduction still depends on its own feature activation. After the newly implemented 350ms setting, Creech identified 300ms as Solana’s next target.
