Originally published on xroot.dev.
Solana's slot has been 400 milliseconds since genesis. The plan to halve 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 halve in wall-clock time.
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.
400 ms — today — 62,500 hashes · 32,768 shreds · 20 MiB · 1.6 SOL
350 ms — 54,687 hashes · 28,672 shreds · 17.5 MiB · 1.4 SOL
300 ms — 46,875 hashes · 24,576 shreds · 15 MiB · 1.2 SOL
250 ms — 39,062 hashes · 20,480 shreds · 12.5 MiB · 1.0 SOL
200 ms — final step — 31,250 hashes · 16,384 shreds · 10 MiB · 0.8 SOL
Slots per year goes from 78.9 million to 157.8 million. Nothing in this table is a projection; it is the literal struct the node loads when each gate flips.
Worth knowing: none of the four gates was active on any cluster when this was written. The table exists, the code paths are tested, the schedule is not published. The upgrades tracker reads the gate accounts from the chain every minute, so it is the current answer rather than this paragraph.
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: the block limit steps down from 60 million compute units to 30 million, and the per-account write limit from 24 million to 12 million. Throughput per second is roughly preserved. Throughput per block is halved.
That matters for anyone whose transaction is large. A single transaction that needs more than 12 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 24 million units of a block — arrives twice as often at half the size.
The proposal to raise block limits to 100 million (SIMD-0286) 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 — still lower absolute numbers than today's 60 and 24.
Your Blockhash Expires in 30 Seconds
A transaction is valid for 150 slots after the blockhash it references, a constant the validator does not rescale. At 400 ms that is a minute. 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 half the time it used to. Retry loops that were tuned to "we have about a minute" will start 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 Becomes a Day, and Every Lock You Promised Is Wrong
432,000 slots at 400 ms is two days. At 200 ms it is one day. Everything measured in epochs completes in half the wall-clock time:
- Stake warm-up and cool-down run their epoch schedule twice as fast — good news for unstaking, and a change in behaviour for anyone modelling exit queues.
- Rewards land twice as often, in smaller pieces.
- The admission ticket per epoch halves so the yearly total is unchanged.
And then the one that costs money. A "12-month" lock expressed as an epoch count — 180 epochs, say — becomes six months. 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.
If you told a community "team tokens unlock in a year" and the lock is denominated in slots or epochs, you have a promise that the chain will break for you. Re-derive the wall-clock date of every lock you have published, at every step of the ladder, and decide now whether to re-lock to the date you meant.
Worth knowing: slot-to-time arithmetic of the form slot × 400 ms is dead code the moment the first gate activates. 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 fall to 16,384, so the maximum block payload halves along with the compute limit.
- PoH hashes per tick fall from 62,500 to 31,250; a validator's hashing budget per slot halves, which is why the reduction is paced rather than jumped.
- The reward distribution engine pays 4,096 stake accounts per block at 400 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 — needs re-reading.
200 ms Slots: Questions People Actually Ask
When does Solana move to 200 ms slots?
In four feature-gated steps (350, 300, 250, 200 ms), each activating at an epoch boundary after 95% stake adoption and taking effect the following epoch. None had activated on any cluster as of 11 September 2026.
Does a 200 ms block hold as many transactions as a 400 ms block?
No. The block compute limit halves from 60 million to 30 million units and the per-account limit from 24 million to 12 million. Throughput per second is preserved; throughput per block is not.
How long is a Solana epoch at 200 ms slots?
432,000 slots either way, so about one day instead of two. Warm-up, cool-down and rewards all run on the shorter epoch.
Will my token lock unlock early at 200 ms slots?
If it is denominated in slots or epochs, yes — its wall-clock date shortens by the slot-time ratio at each step. A 180-epoch “12-month” lock becomes six months at 200 ms.
The Checklist, in the Order the Ladder Will Enforce It
- Before the first step (350 ms). Find every place your code turns slots into seconds. Replace the constant with a per-regime lookup. Halve your assumed blockhash budget and see what breaks.
- 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 12 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 — two days today, one day later — 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.
— One Epoch Is All the Warning You Get —
Watch the four gates, not the roadmap.
Each slot-time step is a feature account on chain. The upgrades tracker reads them every minute and shows which step is live on which cluster — which is the gap between "activated" and "in effect" that your migration has to fit inside.
Regime parameters read from the Agave validator source at commit beee69b958: runtime/src/slot_params.rs and feature-set/src/lib.rs. No gate was active on any cluster at the time of writing.
