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

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.

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.

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.

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

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.

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.