SOLANA·HUB
DE
Infrastructure

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

Mainnet-beta has run 200ms slots since the epoch 1053 boundary on 9 October 2026. Anza confirmed the switch. At 200ms the block limit is 50 million CUs.

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.

Update (September 18, 2026): 300ms Since Late August, Now 250ms

Two more stages are done. Per the Foundation’s official upgrade overview, the 300ms stage was activated on August 25 at epoch 1023 and took effect from epoch 1024 as announced. On September 18, the 250ms stage followed: the official Solana changelog of the same day lists it among the mainnet feature gates. At the time of writing, the Foundation’s upgrade overview still listed 250ms as pending; we rely on the changelog.

What this means in concrete terms: the network now targets four slots per second instead of roughly 3.3. Because the leader schedule stays at four consecutive slots, a leader’s window shrinks from 1.2 to 1.0 seconds, and an epoch works out to roughly 30 instead of 36 hours. Overall capacity stays broadly the same, since each slot carries proportionally less work. The final stage, 200ms, is active on devnet and testnet but has no mainnet date yet. Per the Foundation, skip rate remains the gate: if it rises too far, progression stops.

Update (September 28, 2026): The Foundation Publishes Measurements on the Stages

The Solana Foundation has analyzed how the stages from 400 to 250ms played out. The key findings:

  • Skip rate: per the Foundation, it stayed stable and low across all stages and shows no correlation with the shorter slot time.
  • Vote latency: it rose with each stage, most in Asia and South America. On network average, however, validators still vote for slot N in slot N+1, per the Foundation.
  • Lost vote credits: at 250ms, validators weighted equally lost 1.636 percent of their vote credits, and 0.0874 percent weighted by stake. At 400ms, the figures were 2.105 and 0.262 percent. Per the Foundation, validators with more stake lose proportionally fewer credits than the validator population on average. Vote credits determine staking rewards.

On the final stage, the Foundation writes that the discussion around 200ms is increasingly philosophical and economic rather than purely technical. There is still no mainnet date for 200ms.

Update (October 9, 2026): Mainnet Has Switched to 200ms Slots at Epoch 1053

Mainnet-beta has switched to 200-millisecond slots at the epoch 1053 boundary. Anza confirmed that on 9 October 2026 at 14:42 UTC, 16:42 in Berlin. The target slot time has dropped from 250 to 200 milliseconds. Anza lists the series as 400, 350, 300, 250, 200 milliseconds.

Anza writes that SIMD-0525 feature gates take effect one epoch after they activate. The post sets three marks:

  • Epoch 1051: pending activation
  • Epoch 1052: feature active
  • Epoch 1053: 200ms slots live

The Solana Foundation upgrade page, as of October 2026, lists “Scheduled for epoch 1052” in the column for the slot-time change. For the earlier stages that same column names the epoch in which the new slot time was in effect. The page also says a gate activates at the start of an epoch and the new slot time takes effect at the following epoch boundary. That is the one-epoch delay in the SIMD text. The slot time has applied since the first slot of epoch 1053. Anza had announced that on 7 October and confirmed it on 9 October. Per the Foundation, the 200ms stage is already running on devnet and testnet. The weekly Solana changelog of October 1, 2026, does not carry this mainnet announcement.

Since the switch, five slots fit in one second. The leader window is 0.8 seconds rather than 1.0, and an epoch runs about 24 hours rather than 30. A blockhash stays valid for 150 blocks and expires sooner on the clock. The Foundation puts that window at about 30 seconds at 200ms and about 38 seconds at 250ms. Each stage stays tied to the skip rate. If it rises too far, the reduction stops. The Foundation tracks the step at solana.com/200ms.

On the compute limit: on October 9, CoinDesk reports 30 million compute units per block at 200ms and 37.5 million at 250ms. Those are the SIMD-0525 table values on the 60-million base. SIMD-0286 raised the block limit to 100 million on July 29, 2026, at epoch 1009, before the slot-time stages began. SIMD-0525 requires the active 400ms baseline to be scaled by the slot-time ratio, and its 100-million table sets 62.5 million compute units at 250ms and 50 million at 200ms. Agave does the same in cost_limits: the table value is multiplied by 100 and divided by 60 while the 100-million feature is active. The test in slot_params.rs expects 50 million compute units at 200ms. The May table higher up in this article shows the unscaled 60-million base. On mainnet the scaled cap applies: 50 million compute units per block.

The 200ms stage has been live on mainnet-beta since the epoch 1053 boundary on 9 October 2026.

Sources

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

Related Articles