SOLANA reduced its target slot time from 300 milliseconds to 250 milliseconds, making the network's clock operate nearly 17 percent faster.
A slot is the window during which a designated validator adds a block to the chain. At 250 milliseconds, Solana now targets four slots per second, up from roughly 3.3 previously.
Validators lead four consecutive slots. The faster clock shrinks each leader's control window from 1.2 seconds to one second—a direct hit on MEV exposure and the transaction-ordering power concentrated in any single validator's hands.
For applications like oracle-powered markets and AMMs, this matters immediately. A few hundred milliseconds of data staleness can be the difference between an execution and a failed swap or a price slippage that eats your profit. Traders see faster settlement and a tighter band between quoted and actual execution price.
The speed gain does not translate to a 17 percent bump in raw throughput. Under SIMD-0525, computation and data capacity per slot decrease proportionally. More slots per second arrive, but each carries less work. Network processing ceiling stays flat.
Infrastructure costs rise. Nodes must ingest and store more individual blocks. Downstream applications that estimate time by multiplying slot numbers by a hard-coded duration will drift. Blockhashes expire sooner.
The change compresses windows for transactions that depend on human action—offline signing, delayed approvals—leaving less slack for async workflows.
This is Solana's third reduction. The network previously moved from 400 to 350 milliseconds, then to 300. An epoch, fixed at 432,000 slots, now runs approximately 30 hours instead of 36.
Developers have discussed a final push to 200 milliseconds, which would yield five slots per second and 24-hour epochs. No mainnet timeline exists yet.
Solana has sustained over 5,000 user transactions per second on 300-millisecond slots. Parallel execution and the forthcoming Alpenglow upgrade target further capacity gains.
Separately, Solana raised the data capacity in a single transaction to 4,096 bytes via the Transaction V1 upgrade format, tripling the previous limit.
