Solana shortened the time slot to 350 milliseconds and the network began to accelerate...

Why did Solana shorten the slot time?

Solana has reduced its target slot time from 400 milliseconds to 350 milliseconds and initiated a phased main-network upgrade with the ultimate goal of shortening network slots to 200 milliseconds without doubling the amount of calculations processed by verifiers per second. This change, which took effect on August 21 with the 1020th Era, is the first time Solana has adjusted its long-maintained 400-millisecond goal since early development of the network. Jacob Creech, vice president of technology at the Solana Foundation, confirmed the activation, saying the network is entering a "new era of 350 milliseconds" and has set 300 milliseconds as the next goal. After activation, the average slot time observed was approximately 360 milliseconds. The gap between the 350-millisecond goal and actual performance is expected because slot time is the goal of block production rather than ensuring that each block arrives in exactly the same time interval. This change is the first phase of the SIMD-0525 proposal on the main network, which sets progressive goals of 350 milliseconds, 300 milliseconds, 250 milliseconds, and ultimately 200 milliseconds. The proposal was approved and merged in May, and subsequent reductions are expected to be introduced through separate function switches after network testing.

Does faster block production mean double capacity?

This upgrade is mainly aimed at reducing latency rather than simply increasing nominal transaction throughput. As Solana shortens time slots, the amount of calculations allowed within each block also decreases proportionally. Under the previous 400-millisecond target, the maximum block used in upgrade calculations was limited to 100 million compute units. It drops to 87.5 million at 350 milliseconds, to 75 million at 300 milliseconds, to 62.5 million at 250 milliseconds, and to 50 million at the proposed 200 milliseconds target. These changes have kept the theoretical processing power roughly at 250 million computing units per second throughout the launch process. As a result, Solana is able to create blocks more frequently without requiring the verifier to process twice the theoretical amount because of halving the slot time. Other restrictions associated with individual time slots will also be adjusted accordingly, including resources allocated to account writes, voting, and data fragmentation. This design reduces the risk of a sudden surge in validator workload caused by faster block production alone.

Investor revelation

Solana's slot time upgrade is mainly a latency improvement rather than a simple throughput expansion. If the network reaches 200 milliseconds while keeping the amount of computing per second roughly constant, users will get more frequent block opportunities without requiring the verifier to endure the proportional pressure of doubling its processing power.

What have changed in verifiers and cycles?

Shorter time slots also reduce the control time a single verifier has in consecutive block production opportunities. Currently, Solana validators receive four consecutive slots in each leader round. At 400 milliseconds per slot, the nominal leader window is 1.6 seconds. The new 350 msec setting shortens this window to 1.4 seconds. Drop to 1.2 seconds at 300 milliseconds, drop to 1 second at 250 milliseconds, and drop to 800 milliseconds if the network reaches the final 200 milliseconds goal. The Solana Foundation believes that a shorter leader window reduces the time a single block producer can spend delaying or reordering transactions before leadership is handed over to the next validator. Era duration also changes because each Solana era contains a fixed 432,000 time slots. At 400 milliseconds, an era theoretically lasts about 48 hours. At 350 milliseconds, it drops to approximately 42 hours. The 300-millisecond goal will bring it down to about 36 hours, while the 200-millisecond slot will bring the era closer to 24 hours. This is operationally important because Era is used in processes such as verifier rewards and feature activation. As a result, a faster era may affect the timing of network operations, not just transaction inclusion.

How far is Solana from the 200-millisecond slot?

The remaining stages have been tested outside the main network. Solana's August developer update showed that a 350-to-300-millisecond reduction has been activated in the testnet and the Devicenet, and the next 300-to-250-millisecond function switch has reached the testnet. Some test environments have been further advanced, including running at a target of 200 milliseconds. These deployments allow developers and verifier operators to observe network behavior before considering equivalent settings for the main network. These reductions rely in part on performance improvements in Solana verifier software and network stacks, including Turbine and Replay. Anza, which developed the Agave verifier client, played a central role in preparing the software needed for short slot scheduling. There is no fixed timetable for main network deployment in the remaining stages. Each curtailment depends on testing, client readiness, and validator adoption, which provides the operator with the opportunity to evaluate performance before activating the next feature switch. A 350-millisecond change should not be confused with the finality of a transaction. Slot time measures how often verifiers receive block production opportunities, while confirmation and finality depend on other parts of the Solana consensus process. If SIMD-0525 reaches its final stage, Solana's target slot time will drop by 50% from 400 milliseconds to 200 milliseconds. Block arrival frequency will double, but the upgrade is designed to keep theoretical computing power per second roughly unchanged, so reducing latency rather than scaling up raw computing is a core goal.