Network-reported block times put the new slots at about 267 milliseconds on average, the same roughly 16-millisecond overhead that sat on top of the 400, 350 and 300 millisecond targets before it. Block limits fell in proportion, so throughput stays at 150 million compute units a second.
Solana's mainnet-beta network began targeting 250-millisecond slots at the start of epoch 1037, which opened at 05:06 UTC on Friday. It is the third cut in a staged schedule that began at 400 milliseconds, and it arrived with a matching reduction in how much work a single block is allowed to carry.
The schedule comes from SIMD-0525, a draft proposal by Anza's Brennan Watt that walks the network from 400 milliseconds down to 200 in four steps. Each step lowers the slot target and scales the per-slot limits by the same proportion. At 250 milliseconds a block may consume 37.5 million compute units, down from 60 million at the 400-millisecond baseline, and carry 20,480 shreds instead of 32,768.
Those pairs describe one rate. Sixty million compute units every 400 milliseconds is 150 million a second, and 37.5 million every 250 milliseconds is also 150 million a second. The shred ceiling works out to 81,920 a second either way. The proposal says as much: per-slot work limits scale so that wall-clock resource rates stay unchanged. The change makes the network commit more often, not commit more.
Slots have not been hitting their targets, and the size of the miss has held steady. Network-reported block timestamps put the first slot of epoch 1037 at 05:06:43 UTC and slot 448,170,000 at 18:53:06 UTC, 186,000 slots later. That is 49,583 seconds for 186,000 slots, an average of 266.6 milliseconds. The four full epochs that ran on the 400-millisecond target averaged 415.9 milliseconds. The four that ran on 350 averaged 366.0. The thirteen on 300 averaged 316.5. Each of those figures sits between 15.9 and 16.6 milliseconds above its own target.
Solana's block timestamps are stake-weighted medians reported by validators rather than readings from an independent clock, and the epoch 1037 average covers only the portion of the epoch that has run so far.
The overhead is worth about 4 percent of a 400-millisecond slot and about 6.6 percent of a 250-millisecond one, because the target keeps shrinking while the overhead does not. The absolute gain has still landed in full at each step, with measured slot times falling by roughly 50 milliseconds every time, which is what the schedule asked for. What grows is the gap between the target and the result as a share of the slot.
Applied to the last step, the same overhead would put a 200-millisecond target near 216 milliseconds in practice, about 4.6 slots a second rather than the nominal 5, and would stretch a nominal 24-hour epoch closer to 26. Epoch 1037 is on the same course: at 266.6 milliseconds a slot, its 432,000 slots come to about 32 hours against the 30 the proposal's table lists. These are projections from a figure that has held across three targets, not a commitment from anyone who maintains the network.
Shorter slots also shorten the window in which one validator controls ordering. A leader's turn covers four consecutive slots, so it now runs one second instead of the 1.6 seconds it ran at the baseline. Epochs are a fixed 432,000 slots, which is why they shrink alongside the slot target, and the proposal scales the Validator Admission Ticket, the per-epoch charge in Anza's Alpenglow design, from 1.6 SOL to 1.0 across the same range to hold the implied cost near 0.8 SOL a day.
The first cut, to 350 milliseconds, was the network's first slot-time change since launch and took effect at epoch 1020 on August 21. The 300-millisecond step followed a week later, at epoch 1024 on August 28. Separate protocol work on what Solana charges for state is moving through its own feature gates and does not depend on the slot schedule.
One step remains. At 200 milliseconds a block would be capped at 30 million compute units and 16,384 shreds, and the leader window would fall to 0.8 seconds. No mainnet date has been set. The proposal treats the staged rollout as a way to surface timing, implementation and operational problems at 350, 300 and 250 milliseconds first, and each step waits on observation of the one before it under production conditions.
