Solana Slots Are Going to 200 ms: What Halves, What Shrinks

Solana's slot was 400 milliseconds from genesis until 21 August 2026. The ladder that halves it — SIMD-0525 — is usually explained as "blocks get faster", which is the least interesting thing it does. The interesting part is everything that was quietly denominated in slots because slots were a fixed unit of time, and now is not.

Your blockhash expires in 150 slots. An epoch is 432,000 slots. Stake warms up over epochs. A vesting cliff might be a slot number. A liquidity lock might be an epoch count. None of those numbers change. All of them shrink in wall-clock time — by a quarter at today's 300 ms, by half at 200 ms.

Here is the ladder as the validator has it coded, and the consequences in the order people will hit them.

Four Steps, Four Feature Gates, One Epoch of Notice Each

The reduction is not a switch. It is four separate feature gates — 350 ms, 300 ms, 250 ms, 200 ms — each a normal Solana feature that activates when 95% of stake runs software that supports it, and each taking effect at the first slot of the epoch after it activates. The source explains why: shred filters get a full epoch of advance notice.

The validator carries a full parameter set for every regime. Reading across: hashes per tick, shreds per slot, entry bytes per slot, and the validator admission ticket per epoch.

Slots per year went from 78.9 million at 400 ms to 105.1 million at today's 300 ms, and reaches 157.8 million at 200 ms. Nothing in this table is a projection; it is the literal struct the node loads when each gate flips.

Blocks Get Smaller, Not Just Faster

The first surprise. A 200 ms block is not a 400 ms block delivered twice as often; it is a smaller block. The compute limits scale with slot time. With SIMD-0286 active on mainnet since 28 July 2026 (epoch 1009), the 400 ms baseline is 100 million compute units per block and 40 million per writable account, stepping down to 50 million and 20 million at 200 ms; at today's 300 ms it is 75 and 30 million. Throughput per second is roughly preserved. Throughput per block falls with the slot time: a quarter lower today than at 400 ms, half at 200 ms.

That matters for anyone whose transaction is large. A single transaction that needs more than 20 million units against one account cannot fit in a 200 ms block at all, regardless of how empty the block is. And the "hot account" ceiling that decides whether a popular pool is jammed — today a pool absorbs at most 30 million units of a block, down from 40 million at 400 ms — arrives more often and smaller at every step, and at 200 ms twice as often at half the 400 ms size.

SIMD-0286, the raise to 100 million, is already in force and does not undo this. The code applies it as a multiplier of 100/60 on whatever regime is active, so at 200 ms it yields 50 million per block and 20 million per account — lower absolute numbers than the 75 and 30 million in force at today's 300 ms.

Your Blockhash Expires in 45 Seconds Today, 30 at 200 ms

A transaction is valid for 150 slots after the blockhash it references, a constant the validator does not rescale. At 400 ms that was a minute. At today's 300 ms it is 45 seconds, from epoch 1037's 250 ms it is 37.5 seconds, and at 200 ms it is 30 seconds.

Every piece of software that signs a transaction and then does something before sending it — a hardware wallet prompt, a multisig collecting a second signature, a bot that fetches a quote, builds, then waits for a better fee — has less time than it used to: a quarter less at today's 300 ms, half at 200 ms. Retry loops that were tuned to "we have about a minute" are already seeing expired blockhashes at a rate they never saw before.

The defence exists and is older than the problem: durable nonces, which replace the expiring blockhash with one that lasts until you advance it. They have their own hazards, covered in that post, but for any flow with a human in the loop they go from optional to necessary at 200 ms.

An Epoch Is Already 36 Hours, and Every Lock You Promised Is Wrong

432,000 slots at 400 ms was two days; at today's 300 ms it is 36 hours, from epoch 1037's 250 ms it is 30 hours, and at 200 ms it is one day. Everything measured in epochs completes in less wall-clock time — three-quarters of the old span today, half at 200 ms:

• Stake warm-up and cool-down run their epoch schedule faster — a third faster at today's 300 ms, twice as fast at 200 ms — good news for unstaking, and a change in behaviour for anyone modelling exit queues.
• Rewards land more often, in smaller pieces — every 36 hours today, every day at 200 ms.
• The admission ticket per epoch steps down with the slot time — 1.6 SOL at 400 ms, 1.2 SOL today, 0.8 SOL at 200 ms — so the yearly total near 292 SOL per validator is unchanged.

And then the one that costs money. A "12-month" lock expressed as an epoch count — 180 epochs, say — is already about nine months at today's 300 ms and becomes six at 200 ms. A vesting schedule with slot-numbered cliffs unlocks early by exactly the ratio of the slot-time change at each step. Nothing in the lock contract is wrong; the calendar underneath it moved.

Worth knowing: slot-to-time arithmetic of the form slot × 400 ms has been dead code since the first gate took effect on 21 August 2026. The validator computes elapsed time per regime, summing each regime's slots times its own duration. Anything you build should do the same.

Smaller Things That Will Bite Specific People

• Shreds per slot have already fallen to 24,576 at today's 300 ms, reach 20,480 from epoch 1037 and 16,384 at 200 ms, so the maximum block payload shrinks along with the compute limit.
• PoH hashes per tick fall from 62,500 at 400 ms to 46,875 at today's 300 ms and 31,250 at 200 ms; a validator's hashing budget per slot shrinks with them, which is why the reduction is paced rather than jumped.
• The reward distribution engine pays 4,096 stake accounts per block at 400 ms, 3,072 at today's 300 ms and 2,048 at 200 ms; the distribution still completes within the first 10% of the epoch, but in more blocks.
• Any timeout in a client library that assumed "about 400 ms per slot" — the reference client's own slot-watcher poll is set with that assumption in a code comment — is already wrong at today's 300 ms and needs re-reading.

200 ms Slots: Questions People Actually Ask

The Checklist, in the Order the Ladder Will Enforce It

• The first three steps have already landed. 350 ms took effect in epoch 1020, 300 ms in epoch 1024, and 250 ms lands in epoch 1037. Find every place your code turns slots into seconds, replace the constant with a per-regime lookup, and cut your assumed blockhash budget to 45 seconds today and 30 seconds at 200 ms.
• Before locks matter to you. Re-compute the real unlock date of anything denominated in slots or epochs, publish the corrected date, and re-lock if the original promise was a calendar date.
• Before you rely on block size. If a transaction needs more than 20 million compute units against one account, it will not fit at 200 ms. Split it now.
• All the way down. Each gate activates at an epoch boundary after 95% adoption, which means each one gives you at least one epoch — 36 hours today, 30 hours from epoch 1037, a day at 200 ms — between "activated" and "in effect". That is the only warning you will get, and it is enough if you have already done the work above.

Regime parameters read from the Agave validator source at commit beee69b958: runtime/src/slot_params.rs and feature-set/src/lib.rs. Gate status read from mainnet-beta on 17 September 2026: the 350 ms, 300 ms and 250 ms gates are active, the 200 ms gate is not.