Solana's 200ms Slot Time Is Live on Mainnet at Epoch 1053, Completing SIMD-0525

Solana SOL$109.62+1.0%'s 200ms slot time is live on mainnet-beta. Anza, the team that builds the Agave validator client, confirmed the change at 14:42 UTC on 9 October 2026, shortly after the network crossed into epoch 1053. Solana Compass epoch data puts the start of epoch 1053 at about 14:40 UTC, some 20 minutes ahead of the 15:00 UTC estimate Anza gave two days earlier.

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 under SIMD-0525, the proposal that has taken Solana from 400ms to 350ms, 300ms, 250ms and now 200ms since August 2026.

Anza's post called SIMD-0525 "mission accomplished", said blocks now "land twice as often as they did at genesis", and put an epoch at "about a day instead of two". The 200ms figure is the protocol's target. No measured average exists for it yet, and the three earlier steps each ran slower than their targets.

Epoch 1053 completes SIMD-0525's 400ms to 200ms slot time reduction

All four SIMD-0525 feature gates are now marked "Live" on the slot-time upgrade page on solana.com, which states: "Solana's slot time is now 200ms, down from 400ms." The page dates the 350ms step to 21 August 2026 at epoch 1020, 300ms to 28 August at epoch 1024, 250ms to 18 September at epoch 1037, and 200ms to 9 October at epoch 1053.

The final step followed the staging we described when the 200ms gate went pending on 7 October: the gate was pending in epoch 1051, active in epoch 1052, and the faster slots began one epoch later. The solana.com page says block skip rate, the share of scheduled blocks that never get produced, "was the gating criterion for each step". Neither Anza's post nor the solana.com page gives a skip-rate figure for the 250ms stage.

Measured Solana slot times: no 200ms average until epoch 1053 closes

Our epoch records measure slot time one way: an epoch's wall-clock length divided by its 432,000 slots. That gives an epoch-wide average, skipped slots included, and it exists only for completed epochs. Epoch 1053 was under an hour old when we pulled the data at 15:21 UTC on 9 October 2026, so there is no measured 200ms figure to report. The first one is due when epoch 1053 ends, about a day after it began.

The completed record covers epochs 1004 to 1052, from 18 July to 9 October 2026. Against a 400ms target, slots averaged 415ms to 423ms across epochs 1004 to 1019. They averaged 365ms to 367ms at the 350ms step (epochs 1020 to 1023), 315ms to 317ms at 300ms (epochs 1024 to 1036), and 266ms to 269ms across the whole 250ms stage, epochs 1037 to 1052.

Epoch lengths show the same gap in hours. Epochs lasted 49.9 to 50.8 hours at the 400ms target, where the nominal figure is 48 hours. They lasted 43.9 to 44.0 hours at 350ms against a nominal 42, 37.8 to 38.1 hours at 300ms against 36, and 31.9 to 32.2 hours at 250ms against 30. Epoch 1052, the last at 250ms, ran 32.2 hours at an average of 268.5ms per slot.

Through the three reduced steps the overshoot held between 15ms and 19ms, so it grew as a share of a shrinking slot: under 5% of a 350ms slot, and up to about 7% of a 250ms one. Our data does not show what causes it.

Anza's "about a day" is the nominal figure: 432,000 slots at 200ms is exactly 24 hours. If the same 15ms to 19ms carried over, slots would average 215ms to 219ms and an epoch would take roughly 26 hours. That is our arithmetic from the earlier steps, and nothing has been measured at 200ms. Epoch 1053's own average will settle the question.

What 200ms slots change: 30-second blockhash expiry and an 800ms leader window

The solana.com page lists two changes that reach application code. A transaction's recent blockhash still expires after 150 blocks, but that window is now 30 seconds, down from 60 seconds at 400ms. The page also warns that "a slot count multiplied by 400ms no longer describes elapsed time" and tells developers to read the current slot duration or call getBlockTime instead of hardcoding a constant.

For validators, SIMD-0525 keeps each leader's turn at four consecutive slots, so the stretch one validator controls falls to 800ms from 1.6 seconds at 400ms. The proposal also scales per-slot limits in proportion to slot time. Each block has half the room it had at 400ms, and blocks arrive twice as often.

Alpenglow is next for Solana, and its mainnet migration has no date

Jacob Creech of the Solana Foundation wrote minutes after the epoch 1053 boundary: "Just like that, we're now running 200ms slots on Solana," adding, "Next up, Alpenglow." Alpenglow is the consensus protocol that replaced TowerBFT on Solana devnet in September 2026.

Slot time and finality are separate measures. Slot time is how often blocks are produced, and finality is how long until a block cannot be reversed. Anza's Alpenglow page, last updated on 8 October 2026, lists a 150ms finality target and shows the testnet and devnet migrations as completed on 24 and 25 September. Mainnet-beta is marked "Upcoming", with the line: "After our observation period confirms the earlier runs, migration will be announced." No mainnet date has been announced. RPC and indexing users preparing for that switch can start with Triton One's guide, which we covered in what Alpenglow changes for integrators.