The Limit of Sub-Second Blocks Is Geography, Not Speed

In Why Satsuma Has 2-Second Blocks we argued that block time is the one performance setting a chain can’t change after it launches — so it has to be right the first time, and Satsuma spent it conservatively on two seconds. That post left an obvious question hanging: how much faster could it have gone? Chains advertise 500-millisecond and even 250-millisecond blocks. Is sub-second real, or is it marketing?

So we built a testbed and tried to break it. This is what we found: a modern node has enormous headroom to run sub-second blocks — and none of that matters, because the real limit isn’t the computer. It’s the distance between the computers.

A 60-second primer

If you already know how Satsuma seals blocks, skip ahead. If not, five ideas are all you need for the rest of this post.

• A block is a batch of transactions. Block time is how often a new one is sealed — Satsuma’s is two seconds.
• Validators are the machines that run the network. On a chain like this a small, known set of them takes turns producing blocks.
• A slot is one turn. If the block time is 500 ms, every 500 ms it’s some validator’s turn to produce the next block.
• Finality is the moment a block becomes irreversible — and on Satsuma it’s a first-class guarantee, not an afterthought. Producing a block and finalizing it are two separate jobs: blocks keep coming while a dedicated process runs a few blocks behind to lock them in for good. When a Satsuma block is final, it is final — there is no “probably safe after enough confirmations.”
• The one rule that governs everything below: within a single slot, the new block has to be built, sent to the other validators, and re-checked by them — all before the next slot begins. Build, propagate, import, in one slot. Hold that sentence; the whole story is about when it stops being true.

The setup: a chain we could push

You can’t safely run experiments like “halve the block time and flood it with traffic” on a live network. So we ran them on a pared-down chain built from the same block-production and finality machinery Satsuma uses, with everything non-essential stripped away — no smart contracts, no token economics, just block production, transfers, and finality. Removing the smart-contract engine matters for a subtle reason we’ll return to: contract execution is the heaviest thing a block does, and taking it out lets the block time — not the workload — be the one variable we test.

Then we ran three rounds, each trying to break sub-second blocks a different way.

Round 1 — Can one machine keep up? (Yes, easily.)

The first suspect is always compute. A 500 ms block gives the producer half a second to assemble everything; a 250 ms block, a quarter. Surely at some point the machine just can’t build a block fast enough?

We swept the block time from one second down to 60 milliseconds on a single node and hammered it with transaction load, measuring the real interval between blocks rather than the nominal setting.

Block time held tight all the way down to 125 ms. At 500 ms the node sustained around 1,650 transfers per second, and the telling number was in the logs: assembling a full block took about 50 milliseconds — a tenth of the slot. There was roughly 10× headroom to spare.

What gives out at 60 ms isn’t timing — it’s capacity. Every block gets a compute budget sized to its slot, so a shorter slot means a smaller block that carries fewer transactions. At 60 ms that budget is so small the block fills up almost immediately: blocks still seal right on schedule, there’s just very little room in each one. That’s a throughput ceiling — a separate, tunable setting — not the block-time wall this post is chasing. So round one’s verdict is clear: on a single machine, the computer is nowhere near the bottleneck.

Round one only proves that a machine can make blocks fast enough. But a blockchain isn’t one machine — it’s many, deliberately spread out so no single operator holds the network. And the moment those validators aren’t sitting next to each other, a second limit appears, one that has nothing to do with how fast any of them can think.

Round 2 — The real limit: distance

Here’s the concept the whole post turns on. When one validator produces a block, that block has to travel across the network to the next validator before the next slot starts. Network distance is measured in round-trip time, or RTT — how long a packet takes to go to another machine and come back, in milliseconds. Same building is under a millisecond; across the Atlantic is about 90 ms; across the Pacific to Asia is 200 ms or more.

And moving a block isn’t one round-trip. The receiving validator has to be told a block exists, ask for its contents, and receive them — roughly two to three round-trips. So the real cost of getting a block from one validator to the next is about 2–3 × RTT. Now recall the one rule: that has to finish inside a slot.

• At RTT 100 ms → ~200–300 ms to move the block → fits inside a 500 ms slot ✓
• At RTT 218 ms → ~450–650 ms → overflows the 500 ms slot ✗

To find the exact tipping point, we ran networks of 2, 4, and 6 validators and used network emulation to dial in precise latency between them, sweeping the RTT upward until block time broke.

A sharp cliff, right around 200 ms RTT. Below it, 500 ms is rock-steady. At it, block production can no longer get the block across in time, so a validator’s turn comes and goes with nothing to build on — the slot is skipped, and the block time doubles to one second. And the cliff barely moved as the set grew — the wall is latency, not the number of validators. That’s what makes it safe to extrapolate: carrying a block across a link costs the same whether a handful of validators share the network or hundreds do, and coordinating a larger set only piles more traffic on top. So ~200 ms RTT is a ceiling, not a fragile small-scale artifact — a bigger, real-world network meets it at the same latency, or a lower one.

Round 3 — Proof on real hardware, real oceans

Emulated latency is convincing but not the real thing. So we deployed genuine validators in three cloud regions on three continents — Germany, US-East (Virginia), and Singapore — and measured the actual distances between them:

Two of the three links sit comfortably below the cliff. The trans-Pacific hop, US-East to Singapore, lands at 218 ms — just over it. And the chain behaved exactly as the emulation predicted: with the validators genuinely spread across the planet and no artificial delay at all, 500 ms block time did not hold. It ran at one second. One over-the-cliff link was enough to force it.

Push the latency higher from there and a second failure appears behind the first: block production degrades first (500 ms → 1 s → 1.5 s), and then, further out, finality falls apart too — the lag between the latest block and the last finalized one blew from a few blocks to over two hundred. Two independent things break, at two different distances.

That two methods — a laptop with emulated latency and a real intercontinental deployment — agree on the same ~200 ms number is what makes us trust it.

What this actually means

The headline isn’t “sub-second blocks don’t work.” It’s that sub-second is a placement decision, not a speed decision.

500 ms holds for any validator set where every pair of validators is within ~200 ms RTT of each other — regional, transatlantic, even Europe-to-Singapore. It breaks the moment the set spans a link beyond ~200 ms, such as a US-to-Asia hop, where you’d want ~1-second blocks instead.

This is precisely the line between a permissioned network and a permissionless one:

• A permissioned chain — like Satsuma — chooses its validators and places them. It can keep every link under the cliff and run sub-second blocks reliably, or knowingly trade block time for global spread. It’s an engineering decision with a known answer.
• A permissionless network can’t. Validators join from wherever they are, and some pair of them will inevitably be an ocean apart. A block time that assumes everyone is close will stall for the participants who aren’t.

It also reframes Satsuma’s original two-second choice. Two seconds isn’t just conservative for compute — it’s conservative for geography. It holds even if validators are placed on opposite sides of the planet, with enormous margin to spare. Sub-second is on the table; two seconds is what you pick when you’d rather never think about the map again.

The shortcut we don’t take

There’s a cheaper way to put “sub-second” on a page, and it’s worth naming because plenty of chains use it. Instead of making blocks faster, you change what confirmed means: the instant a transaction is seen by the network, you show the user an optimistic, near-instant confirmation — and let the real, irreversible one catch up a beat later. The block time underneath never moved; a fast, hopeful signal was layered on top of a slower, certain one.

It works, and it’s easy. But it softens the one guarantee Satsuma is built to provide. An optimistic confirmation can still be reversed in the gap before finality — and on a chain meant for settlement, approvals, and record-keeping, a confirmed that can be taken back is precisely the failure mode you’re trying to design out. Satsuma’s finality is built in and deterministic, and we’d rather not trade that away for a faster-looking number.

Worth being precise, though: instant feel and hard finality aren’t actually in conflict. You can surface an immediate “included” signal for responsiveness — as long as it’s labeled honestly as included, not final — with real finality landing right behind it. What we won’t do is call something final before it is. The genuinely-faster-block path, the one this post is about, stays bounded by geography; the optimistic path is fine as honest presentation, never as a substitute for the guarantee.

The takeaway

Sub-second blocks aren’t blocked by how fast a computer can think. They’re bounded by how fast light can cross an ocean — and that’s a limit you engineer around, by deciding where your validators live.