TON vs Satsuma: Sharding, Sub-Second Blocks and Finality
TON just shipped sub-second blocks and unbounded sharding. We measured Satsuma against it — and most of what makes TON fast, Satsuma is built not to need. Here's the reasoning, and the one idea worth borrowing.
Bruno Pierri GalvaoEarlier this year TON shipped Catchain 2.0: roughly 6× the block rate, sub-second “instant” transactions, and fees heading toward feeless. It’s a genuinely impressive piece of engineering, and it’s fair to ask the obvious question about a chain like ours: Satsuma runs 2-second blocks with in a few seconds — should we be chasing those numbers too?
We ran the comparison in depth. The short answer is the interesting part: TON and Satsuma are engineered for opposite goals, so “faster” and “bigger” aren’t the same as “better” — they’re only better for a job. Most of what makes TON fast is solving problems our use case doesn’t have. One idea is worth borrowing, and we’ll show exactly how we’d borrow it. But the and the “instant” layer that everyone quotes? We measured what they’d cost us, and we’re choosing not to pay — on purpose.
The one-screen version
| Dimension | TON (post Catchain 2.0) | Satsuma |
|---|---|---|
| Block time | ~400 ms | 2 s (a config parameter, not a floor) |
| “Instant” UX | 30–100 ms optimistic push | none today — could add (see below) |
| True finality | ~1 s, optimistic path (reorg-exposed) | ~6 s, provable |
| Throughput | horizontally unbounded via sharding | one pipeline — hundreds to a few thousand tx/s |
| Scaling model | scale out (dynamic shards) | scale up (a single chain) |
| Execution | TVM · async actors · FunC/Tact/Tolk | EVM · synchronous · Solidity |
| Composability | async, non-atomic across contracts | synchronous, atomic |
| Fees | rent + gas, heading feeless | metered by resource use, no rent |
| Trust model | public, permissionless, ~400 validators | permissioned, single operator, end-to-end |
| Speed paid for by | inflation raised ~0.6% → ~3.6% | no dilution |
What “sub-second” actually means
TON’s headline number deserves an honest read, because it’s the crux of everything below. “Instant subsecond” is not instant finality. TON’s own docs describe three distinct timing layers:
- Streaming push (30–100 ms): an notification that a transaction looks included — delivered before commits it.
- Block production (~400 ms): the transaction lands in a shard block.
- True finality (~1 s): the block is committed and irreversible.
The number people quote — the sub-100 ms “instant” feel — is the streaming layer surfacing state before it’s final. It’s a push-based optimistic-confirmation stream sitting above consensus. Think of it as a cache of “probably true” that consensus later ratifies.
And the trade-off is written into TON’s own guidance: acting on an optimistic confirmation carries risk, and — this is the sharp edge — if a confirmed balance is later rolled back, no invalidation notification is sent. A value you displayed as confirmed can silently revert. TON’s advice for anything balance-critical is to wait for finality. So the real shape of it is ~400 ms of responsive feedback wrapped around ~1 s of actual settlement, with a reorg-exposure window in between.
There’s a deeper structural trade-off behind the whole speed-and-scale story. TON’s throughput comes from an and dynamic — hot shards split to run in parallel, idle ones merge. That parallelism is real and powerful, but it gives up synchronous : a TON contract can’t call another and read the result in the same transaction — it sends a message processed in a later block. And the extra block rate wasn’t free; sustaining it meant raising network inflation from ~0.6% to ~3.6%. Speed, partly funded by dilution.
Where TON genuinely wins
No spin — these are real, and worth saying plainly:
- Raw latency. ~400 ms blocks and ~1 s finality versus our 2 s and ~6 s. Roughly 5–6× faster today.
- Scalability. Unbounded horizontal sharding versus our single pipeline. At the network level, orders of magnitude more aggregate capacity.
- Reach. A live, permissionless, consumer-scale network with hundreds of and Telegram-sized distribution.
If your job is to be a global public consumer network, TON is extremely well built for it. That’s genuinely not the job Satsuma is doing.
Could Satsuma close the gap? Yes — the useful 90%, cheaply
Here’s the part that surprised us most when we did the measurement work: TON’s “instant” is two independent moves, and Satsuma can make both without adopting any of the async/sharding machinery that costs so much.
Lower the block time. Satsuma’s 2 seconds is a configuration parameter, not a protocol floor. Bringing it to ~500 ms pulls finality from ~6 s down to roughly ~1.5–3 s — squarely in TON’s ballpark. The one real constraint is one we measured directly: a block has to be produced, propagated, and imported within its slot, and we’ve watched block time degrade when a block gets too heavy for its window. So a shorter slot has to be paired with a proportionally smaller per-block budget and validated on the slowest validator. For a small permissioned validator set on good hardware, ~500 ms is comfortably feasible.
Add an optimistic confirmation stream. This is the direct analogue of TON’s streaming layer, and the bigger perceived-latency win. Today our Ethereum JSON-RPC layer hands back a transaction hash and the client polls for the receipt. Instead, we could push status the instant a block author includes the transaction — a sub-100 ms “confirmed” signal — while final settlement lands underneath. Same optimistic trade-off TON makes, but with two advantages we keep: our finality is (a “finalized” transaction is a checkable guarantee, not a probability), and with a tiny validator set and short blocks, the reorg window is small and short-lived.
There’s a third lever worth naming, on throughput rather than latency: our runs an interpreter with no compiled-code cache today, and our measurements show the write path is bound by that, not by hardware. A compiled-code cache or is the lever that lifts EVM throughput — the same kind of move as TON’s streaming cache, in a different place. Put together, these are the ingredients of a faster Satsuma variant: shorter blocks, an optimistic stream, a compiled-code cache. TON-class feel, with none of the async model, sharding, or inflation.
But here’s the thing — we don’t need it
Every one of those levers exists. We know how to pull them. And for what Satsuma is actually for, we’re not going to — because they solve problems our use case doesn’t have.
Satsuma is built for a specific kind of workload: an autonomous system — a controlled set of high-value operations that govern state, move value, and record their own verifiable history on a chain that can’t be quietly rewritten, with no human approving each step. That’s a correctness-and-trust problem, not a throughput problem. Measured against that job:
- We don’t need to scale out. The workload is one entity’s low-volume, high-value actions — not millions of consumer transactions. Per-pipeline, we’re already in the same league as a single TON shard; TON’s giant numbers are the sum across many shards, which is capacity for a demand we don’t have.
- We don’t need the optimistic cache. An autonomous system acts on state and then can’t take it back. “Feels done but might silently revert” is precisely the wrong primitive for that — it’s a liability, not a feature. What it wants is “is done,” provably. That’s what our finality already gives.
- We don’t need sub-second. There’s no human staring at a spinner. A few seconds to provable settlement is not a constraint on an autonomous system’s decision loop.
And the things we do need, TON gives up to get its scale:
- Synchronous atomic composability. Check governance and move treasury and emit an attestation in one atomic transaction — all-or-nothing. On an async actor model that’s several messages across several blocks, non-atomic, with no synchronous read-back. When governance, treasury, and control logic have to interact correctly, atomicity isn’t a nicety — it’s the whole game.
- Provable finality. “Finalized” as a hard, checkable guarantee, not an optimistic confirmation with a silent-reorg gap.
- A durable record. Contracts that persist on a one-time deposit, not one paying per-second storage rent that can freeze or delete an underfunded contract — bad news for a tamper-evident audit trail.
- Determinism and control. For a controlled, high-assurance workload, a closed chain we operate end-to-end is the right tool. TON’s public, adversarial, asynchronous design is a liability here, not a benefit.
The takeaway
This comparison isn’t a scoreboard. It’s a lesson in right-sizing. TON is the better general-purpose public consumer network. Satsuma is the better special-purpose foundation for an autonomous system — and those sentences don’t contradict each other.
The useful discipline is knowing which numbers matter for your job and ignoring the ones that don’t. We measured the gap, we mapped exactly how we’d close the parts worth closing, and we’re deliberately leaving the rest — because the scale and the cache buy speed and reach at the cost of atomicity, provable settlement, and simplicity, and those three are the entire point of what we’re building.
If we ever need the faster variant, the plan is already written. We just don’t need it to prove the thing we’re proving.
The full design — architecture, access model, fees, and measured performance — is in the Satsuma litepaper. You can watch the chain settle blocks live at explorer.satsuma.one. And if you’re building autonomous on-chain systems, that’s the crowd we’re gathering — come say hi in the Telegram.