Cabinet
Back to Technology Insights
2026.08.21

Solana Cuts Slot Time from 400ms to 350ms — the First Reduction Since Genesis Shifts Every Block-Count Constant in Wall-Clock Terms

Solana Cuts Slot Time from 400ms to 350ms — the First Reduction Since Genesis Shifts Every Block-Count Constant in Wall-Clock Terms

What happened

SIMD-0525 was approved and merged on 2026-05-14. It defines a plan to lower slot time from 400ms to 350ms, 300ms, 250ms and finally 200ms in four steps, treating each decrement as a separate activation rather than one change.

Testnet activated the first step on 2026-08-05. On mainnet, the feature gate activated at slot 440,208,000, the opening slot of epoch 1019, and after a mandatory one-epoch delay the 350ms target took hold at the start of epoch 1020. Jacob Creech, VP of technology at the Solana Foundation, announced the transition on 21 August and said the next stop is 300ms. Average mainnet slot time was running around 360 milliseconds at the time of reporting.

The change ships in Agave v4.2, whose mainnet feature activations Anza began the week of 17 August. The same release carries SIMD-0437 (the storage rent constant falls from 6,960 to 696 lamports per byte, a roughly 90% cut) and SIMD-0296 (maximum transaction size rises from 1,232 to 4,096 bytes via a new transaction v1 format). The full Alpenglow consensus codebase is also in v4.2 but is not activated on mainnet; activation is expected in Agave v4.3, targeted for October 2026.

The remaining three steps do not proceed automatically. Each 50ms cut activates only once roughly two-thirds of stake-weighted validators opt in, and the network will not advance if block skip rates stay high.

Why "faster" does not mean "more throughput"

This is the design point. A shorter slot fits less work. Anza therefore trimmed the per-block compute unit ceiling proportionally: the 100M CU cap becomes 87.5M CU at 350ms. The per-second budget stays flat at roughly 250M CU, and holds constant through every stage of the roadmap. At 200ms, the per-block ceiling works out to 50M CU.

SIMD-0525 is a latency proposal, not a capacity proposal. Confirmations arrive sooner, and each leader's monopoly over block building narrows. Leader span stays at four slots, so a leader's turn shrinks from 1.6 seconds to 1.4. From a censorship-resistance angle, narrowing the window in which one party holds discretion is the substantive change.

The parameters left alone matter too. Ticks per slot remain 64, leader span remains four slots, and slots per epoch remain 432,000. Only slot duration moves. That keeps the implementation diff small, at the cost of making every quantity defined in slots shorter in wall-clock terms.

Where compatibility breaks: block-count constants shrink in real time

Epochs are the clearest case. 432,000 slots × 350ms is 151,200 seconds, or 42 hours — six hours shorter than the 48 hours at 400ms. Everything tied to epoch boundaries (stake delegation taking effect, reward distribution, leader schedule generation) moves from roughly every two days to roughly every one day and 18 hours. Batch jobs that approximate epoch boundaries with cron will accumulate drift within a few epochs. At 200ms, an epoch computes out to 24 hours.

The sharper edge is transaction expiry. A recent blockhash is valid for a number of blocks (150), and SIMD-0525 does not change that constant, so the wall-clock window shrinks in proportion to slot time. On a simple calculation, the roughly 60 seconds available at 400ms becomes roughly 52.5 seconds at 350ms and roughly 30 seconds at 200ms (ignoring skipped slots, which in practice lengthen the window; the same caveat applies throughout). Flows with a human confirmation step between signing and submission, offline signing followed by later submission, and clients with fixed-second retry intervals all become more likely to expire.

Agave has adjusted alongside: the snapshot interval moved from 100 slots to 200, because covering the same wall-clock span now takes more slots.

SIMD-0296, shipping in the same Agave v4.2, touches compatibility independently of slot timing. Maximum transaction size rises from 1,232 to 4,096 bytes, but it does so by introducing a new transaction v1 format. The ceiling did not merely loosen; a serialisation format was added. Clients and hardware wallets that implement transaction parsing, size validation or signing themselves will reject the new format until they know about it. An implementation that keeps only the size limit in configuration does not gain support for the new format by editing that value.

Pitfalls to watch

First, progression is decided by a vote, not a calendar. The remaining three steps have no fixed dates. 300ms could arrive next week or stall for months on skip rates. Planning "prepare for 200ms" as a one-off task guarantees fresh drift at each intermediate stage; the work needs to be re-runnable at 350, 300, 250 and 200ms.

Second, activation and effect are separated. The feature gate activated at the opening slot of epoch 1019, but 350ms only took hold at the start of epoch 1020. That one-epoch delay exists to give operators time to update clients; assuming behaviour changed when the gate flipped will put observations and logs out of step.

Third, average slot time does not equal the target. Measured mainnet times were around 360ms against a 350ms target, because of skipped slots and network conditions. Converting to wall-clock using the target alone always errs optimistic. Expiry logic and SLAs should use the measured distribution.

Fourth, the 90% rent reduction (SIMD-0437) rolls out across five independent feature gates, with a fallback gate that can restore the current value. The rent constant can therefore change several times during this period. Implementations that hold account creation cost as a constant break here as well as on slot timing.

[Technical Insights & Actions]

  1. In any protocol with constants defined in blocks, changing the block interval silently changes what those constants mean in wall-clock time — with no specification change to review. A diff review will not catch it. This is structural, not Solana-specific; it applies to every chain that makes block time variable. [Integrators / wallet developers] Before 300ms is proposed, audit every place the code converts blocks or slots into seconds (blockhash expiry checks, retry intervals, timeouts, epoch-boundary cron) and replace them with calculations that read slot time at runtime.
  2. Staged feature gates let the network pause between steps, but for external implementations they mean four changes arriving on an unannounced schedule. A migrate-once model does not hold. [Product teams / SRE] Set up periodic collection of slot time and per-block CU ceiling with threshold alerts so each activation is detected, and have the process in place during September to re-assess impact by the following epoch boundary.
  3. Shorter slots do not add throughput. The per-second compute budget is held flat; what improves is confirmation latency and the narrowing of each leader's discretionary window. Presenting this internally as a performance gain sets expectations that measurements will not meet. [Tech leads] In internal and customer-facing explanations, describe the 350ms change strictly as reduced confirmation latency and a shorter leader turn (1.6s to 1.4s), and keep it separate from any TPS claim.

[Sources]

This article is a technical commentary based on publicly available information and is not investment advice.