/ Writing · · 8 min read
How long is a Solana slot now? 200 ms on paper, and what the chain really does
By Oussama Allamou · Solana · Slot Time · Trading Bots · Infrastructure
A Solana slot targets 200 ms from epoch 1053, which starts at slot 454,896,000 on October 9, 2026. It was 400 ms from genesis until August 21, 2026, then 350, 300 and 250 ms. The target is not what the chain delivers. At every step so far the real average was 16 to 19 ms longer, and during the 250 ms step I measured 267 ms.
I run a capture that records every Pump and PumpSwap transaction with the time it arrived. That gave me a clock that does not depend on what validators report, and it showed me a script of mine that had been quietly wrong for weeks.
One leader · 4 slots at 200 ms0.8 s
The same 4 slots at 400 ms1.6 s
- Slots per second
- 5
- Leader window
- 0.8 s
- Blockhash · 150 blocks
- 30 s
- Epoch · 432,000 slots
- 24 h
The target from epoch 1053, slot 454,896,000, on October 9, 2026. It has no measured average yet.
The counts never changed: 4 slots per leader, 150 blocks per blockhash, 432,000 slots per epoch. Only the clock under them did. At 200 ms each of them lasts half as long as it did at 400 ms.
What is the Solana slot time right now?
| Target | Live from | First slot | Chain average |
|---|---|---|---|
| 400 ms | genesis | 0 | 419 ms |
| 350 ms | Aug 21, 2026 | 440,640,000 | 366 ms |
| 300 ms | Aug 28, 2026 | 442,368,000 | 316 ms |
| 250 ms | Sep 18, 2026 | 447,984,000 | 267 ms |
| 200 ms | Oct 9, 2026 | 454,896,000 | not measured yet |
The first slots are the starts of epochs 1020, 1024, 1037 and 1053. The 400 ms average covers only the last twenty epochs before the first cut, and the 250 ms average covers epochs 1037 to 1051.
A slot is still 64 ticks. Each step shortens the tick, from 6.25 ms down to 3.125 ms, behind its own feature gate, and each gate takes effect at an epoch boundary. I am writing this a few hours before the last boundary, so the 200 ms row has no average yet. The command at the end of this post tells you what the network is doing when you read it.
Is a slot really as long as the target?
No. The target is a parameter, and the proposal itself says its timing values may deviate from reality. To see by how much, I asked a public RPC node for the block time of the first slot of each step, then divided the seconds between two steps by the slots between them.
- Case 01400 ms step
The last twenty epochs before the first cut averaged 418.6 ms per slot, 18.6 ms over the target. Source for every bar: getBlockTime at the step boundaries, read on October 9, 2026.
- Case 02350 ms step
Four epochs, 1,728,000 slots in 632,361 seconds. That is 366.0 ms per slot, 16.0 ms over.
- Case 03300 ms step
Thirteen epochs, 5,616,000 slots in 1,777,300 seconds. That is 316.5 ms per slot, 16.5 ms over.
- Case 04250 ms step
Fifteen epochs on chain averaged 267.4 ms, 17.4 ms over. My capture, timed by its own clock, covered 323,224 slots in 86,402 seconds: 267.3 ms.
Two things stand out. The gap is about the same number of milliseconds at every step, so it grows as a share: under 5% of a 400 ms slot, 7% of a 250 ms slot. And it shows up on a clock that has nothing to do with validators. My capture stamps every message with the time it arrived. One 24 hour run in late September covered 323,224 slots in 86,402 seconds. That is 3.74 slots per second against a target of 4. A shorter sample said about the same: 881 slots in 238 seconds.
I do not know what causes the gap, and I have not measured the 200 ms step yet, so I will not guess at either.
How do I convert a slot number to a time?
For one slot, ask the chain: getBlockTime returns the estimated production time of a block. For a range of slots, or a slot that has not happened yet, you have to add up each step's share. Multiplying by 400 ms no longer works for anything after slot 440,640,000.
Slot time by slot number · msYour range
- Slots × 400 ms
- 35 h 55 min
- Each step at its target
- 22 h 27 min
- Each step at the chain's average
- 24 h 1 min
My capture's own clock measured 86,402 seconds for this range, which is 24 h 0 min. The chain's averages land within a minute of it. The old constant is off by almost 12 hours.
A slot count becomes a time only once you know which step each slot falls in. The averages come from block times at each step's first slot, read on October 9, 2026. I did not measure before epoch 1000, so older slots use the same 419 ms, and the 200 ms step uses its target until it has a full epoch behind it.
The first preset is my capture. The old constant turns a 24 hour run into almost 36 hours.
This is the bug I had. A gap report of mine converted slots to seconds with SECONDS_PER_SLOT = 0.4, so a hole of 300 slots was printed as 120 seconds when it was about 80. A library constant does not save you either. SIMD-0525 notes that the SDK's clock constants stay at 400 ms at first, so code that imports the default slot duration is as wrong as code that types it.
What breaks when the slot gets shorter?
Nothing in the transaction format. What changes is every place where a number of slots stood in for an amount of time. In the order I went through my own code:
- Blockhash lifetime. A blockhash is still good for 150 blocks. That was about a minute and is about 30 seconds at 200 ms. Refresh it more often, stop retrying sooner, and do not let a person take 40 seconds to approve something you signed in advance.
- Slot maths. Any "slots behind times 0.4", any timeout derived from slots, any dashboard that turns a slot gap into seconds.
- Thresholds counted in slots. I treat a long run of empty slots as missed data, and I rewind 150 slots after a restart. Both rules now cover half the wall-clock time they were tuned for. If your stream provider's replay window is counted in slots, it shrank the same way.
- The leader window. Four slots is 0.8 seconds at 200 ms, where it used to be 1.6. Your network distance to the leader did not shrink with it. I covered that path in how a Solana transaction lands.
- Per-block budgets. The proposal scales per-block limits with the slot. A block at 200 ms has half the compute budget of a block at 400 ms, and so does one hot account inside it. Per second it is about the same. Per block there is less room.
- Anything counted in epochs. An epoch is still 432,000 slots: two days at 400 ms, about one day at 200 ms. Staking and unlock schedules written in epochs move with it.
What stays the same?
The counts: 64 ticks per slot, four slots per leader, 432,000 slots per epoch, 150 blocks per blockhash. The proposal kept the counts and shrank the clock, which is why so little code failed loudly and so much of it became slightly wrong.
How do I check the slot time myself?
curl -s https://api.mainnet-beta.solana.com -X POST -H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"getRecentPerformanceSamples","params":[5]}'Each sample covers 60 seconds. Divide 60,000 by numSlots to get milliseconds per slot. A few hours before the 200 ms step I got between 219 and 229 slots per sample, which is 262 to 274 ms. getEpochInfo gives you the epoch: 1053 or later means the last step has begun.
What do the terms mean?
- Slot: the unit of time in which one leader may produce one block. The network counts slots whether or not a block was produced.
- Tick: a fixed fraction of a slot. There are 64 ticks in a slot, and the slot target is the tick duration times 64.
- Epoch: 432,000 slots. Leader schedules and staking rewards are organised by epoch.
- Leader window: the four consecutive slots one validator gets before the next one takes over.
- Blockhash lifetime: how long a signed transaction stays valid. It is counted in blocks, 150 of them, not in seconds.
- Feature gate: a switch in the validator software that turns on at an epoch boundary once it has been activated.
FAQ
How long is a Solana slot in 2026?
The target is 200 ms from October 9, 2026. It was 400 ms until August 21, 2026, then 350, 300 and 250 ms. Measured slots have run 16 to 19 ms longer than each target so far.
How many slots per second does Solana produce?
Five at the 200 ms target, four at 250 ms. The real rate is lower. During the 250 ms step I measured 3.74 slots per second over 24 hours.
How long is a Solana blockhash valid now?
150 blocks, the same count as before. At a 200 ms target that is about 30 seconds. It was about a minute when slots were 400 ms.
How long is a Solana epoch now?
Still 432,000 slots. That is about 24 hours at the 200 ms target, down from about two days at 400 ms. During the 250 ms step epochs took about 32 hours on chain, where the target implied 30.
Is the 200 ms slot the same thing as Alpenglow?
No. SIMD-0525 only shortens the slot. Alpenglow is a separate change to how the network reaches consensus, with its own schedule.
Do I need to change my code for the shorter slot?
Only where a slot count stands in for time. Search for 400, for 0.4 and for fixed slot counts such as 150. Transaction formats and RPC methods did not change.
Further reading
- Reduced Slot Times: the Solana upgrade page, with the schedule and the developer notes.
- SIMD-0525: Shorter slot times: the proposal, with the table of every limit that scales with the slot.