SOLANA·HUB
DE
Infrastructure Developing

SIMD-0525: Anza Proposes Staged Reduction of Solana Slot Time to 200 ms

Brennan Watt has published SIMD-0525 in the repository — Solana's slot time would drop from 400 ms to 200 ms in four steps. Status currently Draft, four feature gates defined, vote costs double by end of rollout.

SOLANA·HUB Redaktion
Source: Solana Improvement Documents

What happened

Brennan Watt of Anza published the proposal SIMD-0525 “Reduce Slot Times” in the official Solana Improvement Documents repository on 1 May 2026. The proposal would reduce Solana’s target slot time in four steps from 400 ms to 200 ms.

Current status: Draft. The SIMD is published in the repository — the associated feature gates are still marked as “TBD”. Mainnet activation requires separate validator voting steps and is not yet scheduled.

What is proposed

Four separate feature gates, each with a one-epoch activation delay:

  1. reduce_slot_time_to_350ms
  2. reduce_slot_time_to_300ms
  3. reduce_slot_time_to_250ms
  4. reduce_slot_time_to_200ms

Each step keeps the following unchanged: 64 ticks per slot, 4 slots per leader window, 432,000 slots per epoch. What changes: per-slot limits are reduced proportionally so the per-second throughput stays roughly constant at the validator level.

Key values from the proposal

Target slot timeSlots per yearEpoch durationLeader windowMax block CUs
400 ms (current)78,892,31448 h1.6 s60,000,000
350 ms90,162,64542 h1.4 s52,500,000
300 ms105,189,75336 h1.2 s45,000,000
250 ms126,227,70330 h1.0 s37,500,000
200 ms157,784,62924 h0.8 s30,000,000

Vote costs remain the same per slot — at 200 ms slots the vote load per wallclock hour therefore doubles. Anza calls this out explicitly in the “Drawbacks” section as an accepted trade-off.

What changes for users and developers

After complete rollout at 200 ms:

  • Confirmation latency halved — Anza describes this in the “Motivation” section as the primary driver.
  • Leader window duration halved to 0.8 seconds. Reduces the worst-case window in which a single leader can reorder or selectively exclude transactions.
  • Finer on-chain time granularity for oracle consumers and market makers measuring freshness in slots.
  • Vote costs per wallclock day double (about 1 SOL/day/validator).
  • Gossip traffic scales proportionally with slot rate.

Relation to Alpenglow and SIMD-0286

SIMD-0525 respects the Alpenglow interaction: hashes_per_tick is not reduced in Alpenglow-active banks — Alpenglow’s low-power Proof-of-History path keeps its active hashing behavior.

SIMD-0525 is also explicitly composable with the SIMD-0286 proposal to raise block compute units to 100 million. If both activate, a 200 ms block would still hold 50 million compute units — at double the frequency, keeping total throughput per wallclock second roughly equal.

Backwards compatibility and risks

Anza explicitly marks SIMD-0525 as a “consensus-breaking change” — validators must implement the feature or risk consensus break. Plus:

  • SDK constants will diverge from chain reality while solana-sdk statically assumes 400 ms. Apps that use 400ms * slots as a wallclock conversion must adjust their logic.
  • Blockhash expiry becomes shorter in wallclock time because it is counted in slots.
  • Staged rollout is part of the safety strategy: each stage should be observed under production conditions before activating the next.

Context

SIMD-0525 is a classic performance iteration step in the context of ongoing Solana improvements (Alpenglow, Firedancer, P-Token, SIMD-0286). The staged approach reduces risk compared to a direct jump to 200 ms. Anza did not name a specific mainnet activation timeline in the proposal.

Observers typically track rollout via validator client releases (Agave, Firedancer) and via the SIMD repository on GitHub.

Update (August 7, 2026): First Stage Running on Devnet and Testnet

The draft has become an active rollout: per the Solana changelog of August 6, the first feature gate — 350ms slots — is active on devnet and testnet. A day later, Anza CEO Brennan Watt posted testnet metrics: eight hours of continuously stable 350ms slots, higher vote throughput, and an unremarkable skip rate of around 0.85 percent; further load tests are planned, per Watt. A mainnet date for the first stage remains outstanding — the rollout path runs through the Agave 4.2 feature activations.

Update (August 10, 2026): 300ms Stage on Testnet

The rollout is accelerating: on August 10, Watt reported that the second stage — 300ms slots — is already active on testnet. Epochs shrink to roughly 36 hours (exactly the value from the proposal table above), which further shortens the path to the next 250ms stage, since feature gates activate per epoch.

Update (August 18, 2026): Mainnet’s Turn — 350ms From Epoch 1020

The first stage reaches production: per Watt, the 350ms gate is activated on mainnet and becomes effective with epoch 1020 — feature gates run the cadence pending → activated → effective with a one-epoch delay. Watt’s explicit note for the transition period: SDK constants such as DEFAULT_MS_PER_SLOT are not yet updated — applications deriving wallclock time from hardcoded 400ms per slot (exactly the risk point from the backwards-compatibility section above) will compute wrongly until adjusted. Timing-sensitive apps, indexers, and RPC consumers should check their own slot-time assumption before the stage takes effect.

Update (August 21, 2026): The Countdown Is Running — With a Live Monitor and Adjusted CU Limits

The switch-over moment is imminent: Solana has put a live monitor at solana.com/200ms showing the remaining slots on the 400ms clock, measured slot times, and client distribution straight from mainnet; at the time of this update it is counting down the final slots before epoch 1020. It is the first slot-time reduction since mainnet genesis.

One important numbers update versus the proposal table above: the table dates from May and assumes the then-current 60 million CU base. Since the increase to 100 million CU, the proportional scaling applies on the new base — at 350ms, the block limit drops to roughly 87.5 million CU, keeping throughput per second constant at around 250 million CU/s. The table’s principle holds unchanged; its absolute CU values map onto the 100M base.

Update (August 25, 2026): 350ms Is Routine — 300ms Is Up Next, From Epoch 1024

The switch-over is done: since epoch 1020, mainnet runs on 350ms slots — the first reduction since genesis is in production. And the rollout keeps pace: per Watt, the second stage — 300ms — is already pending and becomes effective at the start of epoch 1024, roughly three days after the announcement at the current epoch cadence (around August 28). The plan’s safety mechanism stands: if skip rates spike, progression pauses.

Not financial advice. This article describes a technical protocol specification in active rollout. Mainnet implementation and activation are not guaranteed.

Sources

#simd-0525 #anza #performance #infrastructure #alpenglow

Related Articles