Solana sets target slot time to 250ms at epoch 1037
Solana set its target slot time to 250 milliseconds at epoch 1037 on Sept. 18, assigning 62.5 million compute units per slot and narrowing leader handoff windows.
Solana updated its network target slot time to 250 milliseconds at epoch 1037, activating the change at about 05:06 UTC on Sept. 18. The update sets a per-slot compute budget of 62.5 million compute units and shortens the interval validators have to produce blocks.
A slot is the interval during which a leader may produce a block. Shorter target slots increase how often blocks can be proposed while reducing the amount of work each block can carry. An early sample of 60 one-minute windows on Sept. 20 recorded an average produced slot of about 266 milliseconds and a roughly 0.05% slot skip rate for epoch 1037.
Under the draft SIMD-0525 design, a 200 millisecond target remains under consideration. At 200 milliseconds the per-slot compute limit would be 50 million compute units. Both the 250ms and 200ms settings keep the protocol’s nominal ceiling near 250 million compute units per second.
Leader turns remain fixed at four consecutive slots, which provides a nominal one-second production window at a 250ms target and an 800 millisecond window at 200ms. The Solana Foundation measured a median first-slot penalty of about 28 milliseconds when consecutive leaders are within 500 kilometers and about 122 milliseconds when they are more than 8,000 kilometers apart. The 122 millisecond figure equals roughly 61% of a 200ms target and reflects routing, scheduling and client behavior in addition to raw network latency.
Engineering teams are running tests to preserve reliability as slot times shrink. Client teams are executing block-and-transaction tests against conformance binaries across implementations and versions. Agave developers are experimenting with pessimistic forwarding, in which transactions are forwarded proactively to the next leader when they risk missing an intended slot. The draft keeps a 250 millisecond repair-defer threshold even if slot targets drop to 200 milliseconds, which would make that repair delay longer than a single target slot.
Concentration in hosting and software remains a factor. A routing outage at a hosting provider on Aug. 12 caused 12 sites to lose reachability and led to the temporary removal of a Miami site; analysis showed about 28.83% of active stake delinquent for roughly 33 minutes while blocks continued and transactions continued to land. Independent snapshots on Sept. 7 put Solana’s Nakamoto coefficient at 18 and the largest single validator at about 4% of active stake. A provider report from the same date recorded the hosting provider at 22.1% of active stake and noted it had hosted about 38% the previous year before a reduction.
Software concentration on Sept. 20 grouped roughly 87.4% of stake on 4.x client versions, 7.3% on 0.x and 5.3% on 26.x, with major-version numbers serving as rough markers for client families. A decision to adopt a 200ms target will depend on sustained measurements of slot duration, skip rates, transaction landing and leader handoff performance, ideally broken down by client implementation and hosting provider. A separate consensus upgrade called Alpenglow targets roughly 150ms finality on a different timeline; no activation date is set.








