Why Satsuma Has 2-Second Blocks
Block time is the one performance setting a chain can't change after it launches. Here's why Satsuma's is two seconds — and why faster blocks don't actually make a faster chain.
Bruno Pierri GalvaoAlmost every performance setting on a blockchain can be adjusted after the fact. How much work fits in a block, how transactions are priced, how storage is costed, what hardware runs the network — all of it can change on a live chain, in place, whenever the data says it should.
is the exception. It’s fixed when the chain launches, and it can’t be changed on a running chain without halting block production entirely. It’s the one performance decision that has to be right the first time — permanently, and with the least information there will ever be. Here’s how Satsuma’s ended up at two seconds.
Faster blocks don’t make a faster chain
The intuitive story — shorter blocks, faster chain — is mostly wrong, and why it’s wrong drives the whole decision.
A chain’s capacity is roughly how much work fits in a block times how many blocks arrive per second. Halve the block time and there are twice as many blocks — but each one now has half the room, because every block still has to be built, sent to the other machines, and re-verified by them within its own window. A one-second block can’t hold two seconds of work. So shorter blocks force smaller blocks, and total capacity barely moves.
What shorter blocks actually buy is — how quickly a transaction shows up as included, rather than how many can be processed overall. That’s the honest framing, and it’s the whole game.
Block time sets how fast the chain responds. A separate setting controls how much it can do. Only the first one is permanent.
What this chain actually needs
Satsuma is public to read and permissioned to write, and the work it does is coordination rather than heavy computation — approvals, settlements, attestations, record-keeping. That work arrives as a stream of small transactions, often in a tight loop where each one depends on the result of the one before it: act, observe, act again.
A workload like that is bound by latency, not compute. When transactions depend on each other in sequence, the time to include each one lands directly on the critical path, while the chain’s capacity for heavy work mostly goes unused. So when the one permanent setting had to be spent, the choice was clear: spend it on responsiveness, keep generous safety margins, and leave raw to the settings that can still be changed later.
Why two seconds — not six, not one
Not six seconds. Six is a sensible default for a public network of strangers running unknown hardware scattered around the world — it leaves enormous margin. For a tight, dependent loop it’s sluggish: three transactions that each rely on the last cost the better part of twenty seconds before settlement even begins.
Not one second. One second is achievable, and tempting. But it permanently minimizes the margin the chain has to build, share, and verify each block — and permanently is the word that matters. Locking in one second at launch is a standing bet that the chain will never want fuller blocks, more widely separated machines, or heavier state without paying for bigger hardware. Nothing about the workload justified that bet on day one.
Two seconds is the point where the irreversible downside falls to zero and the latency win is still large: about three times more responsive than the six-second default, comfortable margins on modest hardware, and — with trailing a couple of blocks behind — roughly six-second settlement (the point at which a transaction is irreversible, not just included). Everything reversible was set conservatively alongside it, leaving room to grow.
In practice that looks like this — live from the network right now: blocks seal about every two seconds, and each becomes provably final — irreversible — a couple of blocks later.
The margin turned out to be real
Months later came a full performance campaign, and one experiment tested this design more directly than expected. The per-block work limit was raised far past its launch setting to find the ceiling — and on real infrastructure, the blocks stopped fitting their windows. Block time stretched from two seconds toward four, and confirmation slowed with it. That’s the exact failure the safety margin exists to prevent, reproduced on demand.
It reframed the original decision: the margin isn’t wasted headroom — it’s the room the chain has to grow. Because the launch was conservative, throughput has since tripled at the same work limit, just by correcting how the chain prices its own storage, with the limit still raisable whenever there’s a reason. Every one of those gains fit inside the margin the two-second choice preserved. A one-second launch would have spent it in advance.
But some chains do sub-second
Some chains advertise sub-second transactions, and how they do it is worth understanding. In the fastest ones, an “instant” transaction is usually an signal: a notification pushed the moment a transaction is seen, ahead of real settlement, with a small window in which it can still be undone. The chain underneath isn’t necessarily settling any faster — there’s a fast, hopeful confirmation layered on top of a slower, certain one. TON’s recent sub-second launch works essentially this way.
It’s a good idea — and, crucially, it’s the kind of thing that can be added without touching the one number that can’t change. A transaction’s inclusion can be surfaced the instant it happens, for a near-instant feel, with real, provable finality landing behind it as the guarantee. Instant feel, hard settlement, no launch-day regret.
The decision, in general
Strip away the specifics and the block-time choice was really a decision procedure — one worth reusing anywhere:
- Sort the settings by whether they can be changed later. One is permanent; the rest are adjustable.
- Spend the permanent one on whatever the workload is actually limited by. Here, that’s latency.
- Set it to the most conservative value that still delivers the win — and let the adjustable settings chase everything else later, with real data.
Two-second blocks: fast enough for a tight, dependent workload, safe enough to never regret, and every ambition beyond it — more capacity, corrected pricing, near-instant confirmations — still reachable without ever touching the one number that can’t be taken back.