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.

Not financial advice. This article describes a technical protocol specification in draft stage. Implementation and activation are not guaranteed.

Sources

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