• Solana’s main network has cut its target block time from 400 milliseconds to 350ms, the first slot-time reduction since the network launched.
  • At the same time, the amount of computing work packed into each block has been trimmed, so blocks arrive more often but carry less.
  • Testnet is already running an effective 200ms target and Devnet is at 300ms, so more steps are coming.

Solana has sped up. Blocks now arrive roughly every 350 milliseconds instead of 400, the first cut to the network’s slot time since it launched, and it is live on mainnet rather than pending. The less-reported half is that each block is being made to do less work.

If you hold or use SOL, the sensible expectation here is: things feel a bit snappier, and nothing much else changes. Faster blocks that each carry less work add up to roughly the same total capacity as before, so this is not a reason to expect cheaper transactions or fewer failed ones during a busy mint or a market crash. The speed number is the headline. The compute number is the reason the speed number is safe.

What a slot actually is

Close-up of a hand holding a smartphone with a stopwatch app running.
A stopwatch app running on a phone: Solana’s change is measured in fractions of a second, cutting the time between blocks from 400 milliseconds to 350. Photo by Castorly Stock on Pexels.

Start with the bit the announcements assume you know. Solana’s timeline is chopped into slots, and a slot is simply the window in which one gets to produce one block. The target slot time is how long that window is meant to be.

So going from 400ms to 350ms means the windows get shorter and blocks turn up more often: a little over two and a half per second rather than two and a half. For a user, that’s the difference between a transaction confirming very quickly and confirming slightly more quickly. It is not a change you would notice with a stopwatch.

The second number is the per-block compute limit. Every transaction consumes “compute units”, a rough measure of how much work it asks the network to do, and each block has a ceiling on the total it can contain. That ceiling is what’s being trimmed.

Why the two changes go together

Here’s the arithmetic that explains the whole story. If blocks come 14% more often and each one holds around 14% less work, the network is doing about the same amount of work per second as it was before. Shorter blocks, more of them, similar throughput.

That’s deliberate. The thing that breaks a fast isn’t block frequency on its own, it’s how much work the machines running it have to get through in a given second. Validators, the computers that produce and verify blocks, have to receive each block, execute everything in it and agree with everyone else before the next one lands. Keep the work per second flat and you get faster confirmations without asking those machines to do more.

Hand them shorter windows and a full compute allowance and you’d get the other outcome: validators falling behind, missing their slots, and the network slowing down in exactly the way the change was meant to prevent. Validator load was the same underlying worry in our earlier piece on Solana stake delinquency and finality, and it’s the constraint that shapes this one too.

The one-epoch delay

The feature that enables 350ms switched on at slot 440,208,000, the first slot of epoch 1019. An epoch on Solana is a scheduling period of roughly two days, used for things like rotating who validates what. The network stayed at an effective 400ms target through that whole epoch and only shifted to 350ms at the start of epoch 1020, which is the point it has now passed.

That gap was on purpose. Thousands of independently operated validators need to be running software that agrees on the new parameters at the same instant, and a change that took hold mid-epoch would have left some of them working to one rulebook and some to another. Waiting for a clean epoch boundary gave operators a known moment to be ready for.

How far ahead the test networks are

Mainnet is the cautious one. Testnet is already at an effective 200ms target, and Devnet is at 300ms with its 250ms gate activated but not yet effective. Solana’s changelog on 6 August listed only the 350ms step on those two clusters, so the later stages have moved quickly since.

Two caveats worth holding onto. SIMD-0525, the proposal setting out the delay mechanism, is still a draft, and a feature activating on one cluster shows a change is moving through the network rather than that the full 200ms design is a settled standard. And all of these are target timings. What blocks actually do in production is a separate measurement, and the two do not always match.

What to watch

Whether 350ms holds in production now that it is running on mainnet, without validators starting to miss slots. If it does, expect the 300ms and 250ms steps to follow within months rather than years.

And watch the compute limit at each step. If Solana keeps shrinking blocks in proportion to the speed gain, this is a latency project and total capacity stays roughly where it is. If a later step raises the compute allowance per second, that’s the point at which faster blocks might genuinely mean more room for transactions, and the first time this work could plausibly show up in what you pay. For more on the tech beat, see our technology coverage.

Update, 22 August 2026: The 350ms target slot time has now activated on Solana’s mainnet, the network’s first slot-time reduction since it launched. The article originally described the change as pending at the epoch 1020 boundary and has been updated to reflect that it is live.