Solana has reduced its mainnet target slot time to 300 milliseconds as part of SIMD-0525, cutting the original 400 ms target by 25% while preserving roughly the same protocol work budget per unit of wall-clock time. The upgrade is primarily a latency improvement rather than a proportional increase in raw throughput, because compute, data and shred limits are scaled down as slots become shorter. The next 250 ms and 200 ms stages remain pending on mainnet.
According to Solana’s official reduced-slot-times documentation, the 350 ms stage became effective in August before mainnet moved to 300 ms later that month. SIMD-0525 deliberately separates faster block cadence from additional wall-clock capacity, allowing users and latency-sensitive applications to receive fresher state without automatically multiplying the amount of computation the network can execute each second.
Faster Slots Meet Larger Blocks
That design interacts directly with SIMD-0286, which activated on July 29 and raised Solana’s 400 ms baseline block ceiling from 60 million to 100 million compute units. The 66% increase expanded computational capacity independently of the slot-time reduction. Once shorter slots are applied, however, SIMD-0525 scales that 100 million-CU baseline proportionally: 75 million CUs at 300 ms, 62.5 million at 250 ms and 50 million at 200 ms.
The result is an important distinction between block frequency and aggregate processing capacity. At 400 ms, a 100 million-CU ceiling corresponds to roughly 250 million CUs of theoretical block budget per second. At 300 ms, four-fifths as much compute is allowed per slot but slots arrive more frequently, leaving the wall-clock ceiling approximately unchanged. SIMD-0525 therefore improves latency without undoing the capacity gains delivered separately by SIMD-0286.
Other upgrades expand usable capacity in different ways. Solana activated its v1 transaction format at epoch 1035 on September 15, raising the maximum transaction size from 1,232 bytes to 4,096 bytes. Larger transactions can now accommodate workloads such as ZK proofs, larger multisigs and more complex atomic operations that previously needed to be split across transactions or bundles. Legacy and v0 transactions remain supported.
Efficiency Gains Extend Beyond Slot Timing
The optimized Token Program, known as p-token, is also live on mainnet and substantially reduces the compute consumed by common token instructions. Benchmark examples in SIMD-0266 show many operations using roughly 2% to 5% of the compute required by the previous implementation. Lower token-operation costs free block capacity for other transactions without requiring another increase in the protocol-wide CU ceiling. Solana estimates the change can reclaim roughly 10% of total block space under representative workloads.
For trading and other latency-sensitive applications, shorter slots mean more frequent state updates and shorter leader windows. SIMD-0525 also reduces the period during which one leader controls consecutive block production, which can improve market responsiveness and reduce the wall-clock impact of transaction ordering. Those benefits should not be confused with a 17% throughput increase when the eventual 250 ms stage activates, because the proposal explicitly scales per-slot resource limits alongside timing.
Solana’s next major latency milestone extends beyond slot production. Alpenglow remains in development as a replacement for TowerBFT and targets approximately 150 ms finality, while the separate slot-time roadmap ultimately targets 200 ms slots. Alpenglow’s 150 ms figure refers to consensus finality, not block or slot duration, making it another distinct performance dimension. The immediate milestone to watch is mainnet activation of the 250 ms SIMD-0525 stage, followed by whether applications adapt their routing, retry and transaction-construction logic to the network’s faster cadence.
