Solana's mainnet is about to get faster. The network's target slot time will drop from 400 milliseconds to 350 milliseconds, with the change taking effect in epoch 1020 after activation in epoch 1019. The one-epoch delay gives the network time to adjust, but it's just one step in a longer push toward 200ms slots.
The new slot time schedule
Testnet is already running at an effective 200ms target, and Devnet sits at 300ms with its 250ms gate activated. On mainnet, the shift to 350ms is the first reduction from the long-standing 400ms baseline. Each epoch still contains 432,000 slots, so the faster the slot time, the shorter the epoch. At 400ms an epoch lasts roughly 48 hours; at 350ms it compresses to around 42 hours. If the network eventually hits 200ms, epochs would shrink to about 24 hours.
Compute stays flat, blocks get lighter
One thing isn't changing: the theoretical maximum compute per second. Across all slot-time stages from 400ms down to 200ms, that cap stays at approximately 250 million compute units (CUs). Instead, per-block limits scale down. At 400ms, a block can use 100 million CUs; at 350ms it's 87.5 million; at 200ms it drops to 50 million. So blocks get lighter even as the network processes them faster.
A tighter window for validators
The four-slot leader window shrinks as slot times speed up. At 400ms, a leader has 1.6 seconds to propagate and replay blocks. At 200ms, that window is just 0.8 seconds. That leaves less time for validators to receive, verify, and agree on the chain's state. The compressed schedule also affects how quickly epochs turn over, which could put more pressure on network participants that rely on timing assumptions.
The draft proposal and its dependency
The changes are outlined in SIMD-0525, a draft proposal that also calls for reductions in per-slot budgets for account writes, votes, data allocations, data shreds, coding shreds, and partitioned rewards. But the scaling only applies if a separate mechanism called the Alpenglow Validator Admission Ticket (VAT) is active. VAT is designed to gate validator entry and would adjust charges based on the new slot times. Without VAT, the proposed slot-time scaling doesn't kick in.
Off-chain software needs to adapt
Software built around the old 400ms constant could start producing inaccurate results as faster slot times activate. The proposal suggests off-chain clients shift to pulling timing parameters directly from the cluster rather than hardcoding them. That's a practical hurdle for exchanges, indexers, and analytics tools that have baked the 400ms figure into their logic. The activation in epoch 1019 is the immediate step, and the one-epoch delay to 1020 gives the network a brief window to catch problems. Whether off-chain tools update in time remains an open question.
