Solana has reduced its target slot time from 300 milliseconds to 250 milliseconds, increasing the number of targeted slots from about 3.3 to four per second.
The change went live on Sept. 18 and is the third stage of SIMD-0525, a plan to gradually reduce Solana’s slot time from the original 400ms to a final target of 200ms.
A slot is the short period when a selected validator can produce a block. With shorter slots, wallets, exchanges, trading apps and other services can receive network updates more often.
Validators still lead four slots in a row. Under the old 300ms setting, that gave a validator a 1.2-second leader window. At 250ms, the window is now about one second.
Solana started this rollout in August by reducing slot time from 400ms to 350ms. The plan uses four stages: 350ms, 300ms, 250ms and finally 200ms. Each stage requires a separate feature activation so developers and validators can watch network performance before moving forward.
The faster timing can help applications that depend on fresh blockchain data, including oracle markets and automated market makers. Shorter slots can also reduce the time between transaction submission and network updates.
However, the change does not mean Solana’s overall transaction capacity has increased by nearly 17%.
Under SIMD-0525, resource limits are lowered as slot times become shorter. This means the network produces more slots, but each slot can handle less computation and data. As a result, the amount of work the network can process over a given period stays roughly the same.
Using the proposal’s 60 million compute unit baseline, the 250ms setting brings the per-slot limit down to 37.5 million compute units. The planned 200ms stage would lower it further to 30 million.
The faster clock also changes how infrastructure and applications operate. Infrastructure providers will have more individual blocks to process and store, even though the overall processing limit remains broadly unchanged.
Applications that estimate time based on slot numbers may also need to adjust their calculations. Blockhashes can expire faster in real time because slots are advancing more quickly, which could matter for transactions involving offline signing or delayed approvals.
Epochs also become shorter. Solana keeps each epoch at 432,000 slots, so reducing the time of each slot reduces the total length of an epoch. At 300ms, an epoch lasted about 36 hours. At 250ms, it is expected to last around 30 hours. At 200ms, it would fall to about 24 hours.
The slot changes are part of the wider Agave 4.2 rollout, which also includes other network upgrades. Solana has added lower onchain storage rent and larger transactions, among other changes.
The rollout also includes a safeguard based on block skip rates. If skipped blocks rise above an acceptable level, progress toward the next slot setting can be stopped while validators operate under the current configuration.
The final goal is 200ms slots. That would give Solana five targeted slots per second and reduce the four-slot validator leader window to about 800 milliseconds.
There is still no mainnet activation date for the 200ms stage. Developers will continue watching network performance before activating the final feature gate.
Solana is also working on other major upgrades that are separate from the slot-time changes. Transaction V1 increases the maximum serialized transaction size from 1,232 bytes to 4,096 bytes, allowing larger and more data-heavy operations. Legacy and version zero transactions will continue to be supported.
The slot-time changes are also separate from Alpenglow, Solana’s planned consensus redesign. Alpenglow is designed to replace TowerBFT with a voting system called Votor and remove onchain vote transactions from the core consensus process. The upgrade is targeting roughly 150ms finality, but its deployment is separate from SIMD-0525.
For now, Solana remains at the 250ms stage. The network has moved from 400ms to 350ms, then 300ms, and now 250ms, with the final 200ms step still waiting for activation.
