Solana's 200ms Slot Time Is Pending on Mainnet, Scheduled to Go Live at Epoch 1053 on October 9

Anza, the team that builds the Agave validator client, said on 7 October 2026 that the 200ms slot time feature gate is pending activation on Solana SOL$101.16+0.9% mainnet-beta. According to Anza's post, 200ms slots are scheduled to go live at the epoch 1053 boundary, which Anza expects at about 15:00 UTC on Friday 9 October.

A slot is the window in which one validator produces a block, so slot time sets how quickly the network can include a transaction. The 200ms step is the last of four reductions defined in SIMD-0525, which has taken Solana from 400ms to 350ms, 300ms and 250ms since August. Nothing has changed on mainnet yet: Solana is still running 250ms slots, the schedule is Anza's own, and we have not verified the gate's status on-chain.

How SIMD-0525's one-epoch delay puts 200ms slots at epoch 1053

The 200ms feature gate is scheduled to activate at the start of epoch 1052, and the faster slots begin one epoch later, at epoch 1053. Anza's post lays out the staging as three lines: "epoch 1051: pending activation", "epoch 1052: feature active", "epoch 1053: 200ms slots live".

The gap comes from the proposal itself. The SIMD-0525 text, authored by Brennan Watt of Anza, states: "A slot-time feature gate MUST take effect on a one-epoch delay." It adds that the delay gives validators an epoch of notice before the network starts enforcing the smaller per-slot limits. That is why the slot-time upgrade tracker on solana.com lists the 200ms step as "Scheduled for epoch 1052" while Anza gives epoch 1053 for the slots themselves. Both describe the same schedule. Anza's feature-gate tracker for Agave lists the gate under "Pending Mainnet Beta Activation".

The 250ms step followed the same pattern in September, when we covered the gate going pending two days before epoch 1037.

Solana Compass epoch data shows epoch 1051 began at 22:14 UTC on 6 October 2026. Recent epochs have lasted about 32 hours each, and epochs 1051 and 1052 both still run on 250ms parameters. At that pace epoch 1052 would begin at about 06:30 UTC on 8 October and epoch 1053 at about 14:30 UTC on 9 October, roughly half an hour ahead of Anza's estimate. Boundary times are estimates until they pass.

Measured Solana slot times ran 15ms to 19ms above target at each step

All three earlier reductions are live, and each has run slightly slower than its nominal figure. The tracker on solana.com dates the 350ms step to 21 August 2026 at epoch 1020, 300ms to 28 August at epoch 1024, and 250ms to 18 September at epoch 1037.

Our own epoch records give the average slot time each step delivered, calculated as an epoch's wall-clock length divided by its 432,000 slots. It is an epoch-wide average, skipped slots included, and says nothing about individual blocks. On that basis slots averaged 415ms to 423ms across epochs 1007 to 1019, when the target was 400ms. They averaged 365ms to 367ms at the 350ms step, 315ms to 317ms at 300ms, and 266ms to 269ms across epochs 1037 to 1050 at 250ms.

The overshoot has stayed between 15ms and 19ms through all three reductions, which means it has grown as a share of a shrinking slot. In practice an epoch at 250ms has taken about 32 hours, against the 30 hours the nominal figure implies. Our data does not show what causes the difference. The first full epoch after 9 October will show whether it carries over to 200ms.

What changes at 200ms: 30M compute units per block and 24-hour epochs

At 200ms each block gets half the room it had at 400ms, and blocks arrive twice as often. SIMD-0525 scales per-slot limits in proportion to slot time, so the maximum compute units per block falls to 30 million from 37.5 million at 250ms and 60 million at 400ms, and the data shred limit falls to 16,384 from 32,768 at 400ms. Because blocks come twice as often, the ceiling per second works out the same.

Each leader still produces four consecutive slots, so the window one validator controls shrinks to 800ms from the 1.6 seconds it was at 400ms, according to the proposal. The shorter window applies to every operator on our validator list.

Epochs stay fixed at 432,000 slots, so they get shorter in wall-clock terms. The solana.com tracker puts an epoch at about 24 hours once 200ms is active, down from roughly 48 hours at 400ms. SOL issuance is not meant to change: the proposal adjusts the inflation calculation across each transition, which it says "preserves issuance from a wall-clock perspective".

The solana.com tracker also says block skip rate, the share of scheduled blocks that never get produced, is "the gating criterion for each step", and that the network will not move to the next reduction if skip rates look too high. That wording comes from the tracker, and SIMD-0525 contains no skip-rate rule. Anza has not published skip-rate figures alongside this notice. The same tracker lists 200ms as already live on devnet and testnet.

Alpenglow is the next consensus upgrade Anza is discussing

Anza's post opens with the words "Final slot reduction step". Challenged on that wording in the replies, Anza answered: "Should have clarified for this SIMD-0525 specifically." So the label covers this proposal and makes no claim about later ones.

The next protocol change in testing is Alpenglow, the new consensus protocol that went live on Solana devnet in September. Anza said on 6 October that it would cover the Alpenglow migration in a session the following day. That post gives no mainnet date for Alpenglow.