200ms slots: retries, blockhash windows, and UX copy

SIMD-0525 shortens Solana's target slot time from 400ms toward 200ms. Agave 4.2 carries the feature gates. The Foundation write-up is solana.com/upgrades/reduced-slot-times. Live tracker: solana.com/200ms. Proposal: SIMD-0525.

This is not Alpenglow. Alpenglow changes how a block becomes irreversible. Shorter slots only change how long each slot is on the clock. Commitment labels stay processed, confirmed, and finalized until Alpenglow actually activates (targeted later, in Agave 4.3 on current Foundation notes). The validator-facing 4.2 notes are in Agave v4.2.

What actually changes

Four gates: 350ms, 300ms, 250ms, 200ms. Each waits one extra epoch after activation before the new duration applies, so Turbine can switch shred limits cleanly. Skip rates too high and the next step does not fire. Leader span stays 4 slots. Epoch length stays 432,000 slots. Ticks per slot stay 64. Per-slot CU and shred caps scale down with the target so wall-clock work rate stays about the same.

At 400ms a leader window is 1.6s and an epoch is about 48 hours. At 200ms those are 800ms and about 24 hours. The Foundation changelog for 20 August 2026 recorded mainnet moving 400ms to 350ms. Later steps are separate gates. Do not hardcode the current step in an app. Read solana.com/200ms or measure slots over wall time.

Retries

A recent blockhash is valid for a fixed number of slots, not a fixed number of seconds. Fetch getLatestBlockhash and honor lastValidBlockHeight. Stop retrying that hash when getBlockHeight is past it, then take a new hash. Do not sleep for "one minute" because a tutorial used 400ms times 151.

const { blockhash, lastValidBlockHeight } = await connection.getLatestBlockhash()
const sig = await sendTransaction(tx)
await connection.confirmTransaction({ signature: sig, blockhash, lastValidBlockHeight })

SIMD-0525 says SDK clock constants may stay on the 400ms values at first. UI math that does slots * 400 will lie as gates fire. Slot counts from RPC are the source of truth. If a flow must live longer than the blockhash window, use a durable nonce, not a longer sleep.

What UX copy should assume

User-facing copy should say 200ms or 400ms, not the in-between steps. Those steps are operator gates. A wallet that prints "lands in 350ms" will be wrong twice: once when the next gate fires, and always if the user hears that as finality.

A 200ms slot is the chance to produce a block. Confirmed still means the cluster voted. Finalized still means enough subsequent slots rooted that block. Do not write "final in 200ms." Do not write "Alpenglow is live" because slots got shorter. If you show a timeout spinner, size it off remaining slots to lastValidBlockHeight, or you will expire the UI while the hash is still valid, or keep spinning after it is dead.

Mid-rollout, slot time on mainnet will sit between 400ms and 200ms. Treat 200ms as the destination the protocol named. Treat 400ms as the old default your SDK may still print. Measure if you need the number on screen today.