Solana’s Slot Time Drops to 350ms, But Outlets Disagree on Whether the Upgrade Rule Is Final
Solana has cut its target slot time to 350 milliseconds, the first change to that parameter since the network’s genesis, according to Cointelegraph. The move is one step in a four-stage plan under proposal SIMD-0525 that aims to eventually bring slot times down to 200 milliseconds — but the three outlets tracking the rollout each caught it at a different stage, and their accounts don’t fully line up.
What happened
Cointelegraph reported on Aug. 21 that Solana’s average slot times stood at 360ms at press time, down from the network’s original 400ms target, citing the Solana slot time explorer. The outlet attributed the confirmation to Solana Foundation vice president of technology Jacob Creech, who posted on X: "We’re in a new era of 350ms. Next stop, 300ms." Cointelegraph said the Foundation first laid out the 400ms-to-200ms plan in June, with three further 50ms reductions still to come, all targeted for activation in the Agave v4.2 validator client built by Anza — though Cointelegraph noted the schedule remains tentative.
That framing sits alongside two earlier reports that describe the same rollout from different vantage points. Crypto Briefing reported that the first concrete activation happened on testnet on Aug. 5, when Solana moved from a 400ms to 350ms slot time as the opening stage of SIMD-0525. Crypto Briefing said Anza CEO Brennan Watt announced the activation hours before it went live and urged validators to upgrade to Agave v4.2. CryptoSlate, publishing Aug. 19, reported that mainnet’s 350ms feature had activated at slot 440,208,000, the first slot of epoch 1019 — but that a one-epoch delay built into SIMD-0525 means the change only becomes effective in epoch 1020.
Where the three accounts agree
All three outlets describe the same underlying mechanism: SIMD-0525 lays out four sequential 50ms reductions moving Solana from a 400ms slot target toward 200ms, and all three tie the current step to the 350ms figure. Cointelegraph and Crypto Briefing both describe 200ms as the end goal of the staged rollout. Crypto Briefing and CryptoSlate both describe the process as gated — Crypto Briefing says each 50ms reduction requires supermajority endorsement from roughly two-thirds of staked validators plus a one-epoch delay before taking effect; CryptoSlate independently describes the same one-epoch delay mechanic at the mainnet stage specifically.
Where they diverge
The clearest conflict concerns the formal status of SIMD-0525 itself. Cointelegraph reported that the proposal "was approved and merged on May 14." CryptoSlate, writing more than three months later on Aug. 19, described SIMD-0525 as a proposal that "remains a draft," and specified that feature activation on a cluster shows the change is moving through the network, not that the design has become an accepted final standard. Nothing in the evidence pack reconciles these two characterizations — they describe the same document with opposite formal status at different points in time, and it is not clear from either report whether the status changed between May and August or whether one outlet’s framing is simply imprecise.
The outlets also disagree, implicitly, on timing. Crypto Briefing said the mainnet rollout of Agave v4.2 was expected around Aug. 17. CryptoSlate’s Aug. 19 report describes mainnet’s 350ms change as activated but not yet effective, pending epoch 1020. Cointelegraph’s Aug. 21 report treats 350ms as already live on the network, citing the 360ms average slot time. Whether the Aug. 17 target was actually hit, and precisely when mainnet crossed from "activated" to "effective," is not established by any single outlet’s reporting and cannot be reconciled from the evidence available.
A smaller but notable gap: each outlet quotes or names a different individual as the source of authority on the change. Cointelegraph cites Creech’s X post. Crypto Briefing cites Anza CEO Brennan Watt’s announcement ahead of the testnet activation. Neither outlet’s named figure appears in the other’s report.
The compute-ceiling mechanics only CryptoSlate reported
CryptoSlate alone laid out the arithmetic behind why Solana is shortening slots without expanding compute. The outlet reported that Solana’s July 30 changelog had already activated a maximum block limit of 100 million compute units at the 400ms slot time, and that SIMD-0525 scales that limit down as slots shorten: 87.5 million compute units at 350ms, 75 million at 300ms, 62.5 million at 250ms, and 50 million at 200ms. Each of those figures works out to a theoretical ceiling of roughly 250 million compute units per second regardless of slot length, according to CryptoSlate — meaning the network is rescheduling how often work gets done, not raising how much work fits into a second. CryptoSlate also reported that the four-slot leader window shrinks alongside slot time, from 1.6 seconds at 400ms to 0.8 seconds at 200ms, and that a fixed 432,000-slot epoch compresses from roughly 48 hours to 24 hours across the same range. None of this compute-limit detail appears in Cointelegraph’s or Crypto Briefing’s reporting.
CryptoSlate additionally reported that testnet was already running at an effective 200ms target and devnet at 300ms by Aug. 19 — well ahead of mainnet’s 350ms stage — a gap in rollout progress across clusters that neither Cointelegraph nor Crypto Briefing addressed.
What remains unresolved
The formal status of SIMD-0525 — approved versus draft — is the sharpest open conflict in the coverage. The exact date mainnet’s 350ms slot time became fully effective, as opposed to merely activated, is also unclear given CryptoSlate’s epoch-based account and Cointelegraph’s later, more definitive framing. No outlet in this evidence set gives a firm date for the next 50ms step toward 300ms beyond Creech’s social-media reference to it as the "next stop."
Why it matters
A slot-time cut touches validator infrastructure and any off-chain tooling built on the assumption that a Solana slot equals 400 milliseconds. CryptoSlate’s reporting flags that some SDK constants and explorer tools remain tied to the 400ms assumption, meaning software that estimates elapsed time by multiplying slot counts by 400ms could disagree with the cluster once faster stages take effect. That risk, along with tighter validator handoff windows as leader slots shrink, is part of what the staged rollout and validator supermajority votes are designed to test at each 50ms increment.
Sources
Every fact above is attributed to one of these reports. Where they disagree, the article says so.
Read More
