Inside Satsuma's Performance Benchmarks
A look at what the benchmarks measured, and how. What a 'transaction' even means, Satsuma's numbers next to a chain everyone knows, and a plain decode of the '143,000 TPS' headline you've probably seen.
Bruno Pierri GalvaoAlmost every blockchain advertises a “” number, and almost none of them mean the same thing. One chain counts simple payments. Another counts a hundred payments bundled into a single transaction and reports each one. A third adds up the work of many chains running in parallel. Put two of these numbers side by side and you usually learn nothing.
This post is a look at Satsuma’s performance benchmarks — what they measured, under sustained load, in a repeatable setup — and how. It defines what’s being counted, shows the numbers, puts them next to a chain everyone knows, and decodes one of the giant headline figures you’ve probably seen. How to read the results is up to you.
Two kinds of transactions
Before any numbers, two definitions, because they don’t run at the same speed:
- A token transfer is moving Satsuma’s own built-in coin from one account to another. It’s a simple, native operation the chain handles directly.
- A smart-contract transaction runs code. The most common example is moving a token that’s defined by a smart contract rather than built into the chain — the kind of token most applications issue. Because it executes contract code on every transaction, it’s inherently heavier than a native transfer.
Both matter; they just sit at different points on the cost scale, so they were measured separately throughout.
How the tests ran
The benchmark harness stands the chain up and drives it to saturation.
One detail is worth sharing, because it shaped the numbers. The first load generator was written in JavaScript, and it couldn’t submit transactions fast enough to fully load the chain — the test tool was the bottleneck, not Satsuma. So the earliest smart-contract figures understated what the chain could actually do. A rewrite in Rust let the generator properly saturate the chain, and only then did the numbers reflect Satsuma’s real ceiling instead of the tooling’s.
What the benchmarks measured
Under sustained load, in a controlled setup:
Are those numbers fast?
On their own, “330 smart-contract transactions per second” doesn’t tell a newcomer much. So here’s a reference everyone knows: Ethereum’s base layer — the most widely used smart-contract chain in the world — sustains roughly 15 to 30 transactions per second. The same kind of transaction, on the busiest chain there is.
Satsuma’s smart-contract is already several times that, and its token-transfer throughput is in the range of chains built and marketed for high performance. One caution when you compare, though: a lot of chains quote a theoretical maximum, or a number inflated by the same bundling decoded below. Compared like-for-like — one chain, one transaction at a time — a well-built independent chain lands somewhere in the hundreds to low thousands of transactions per second, and Satsuma sits comfortably in that band.
Why smart-contract transactions cost more
Why do smart-contract transactions run at ~330 per second while plain transfers run several times faster? The limit traces to the contract engine — the component that executes contract code. Today it reads a contract’s code and reloads it from scratch on every single call, without keeping the compiled result around. Execution engines like this are typically accelerated with : compiling a contract’s code once and reusing it on later calls. That single characteristic is what sets this particular ceiling.
A note on the chain’s own accounting
One of the more interesting findings came from how the chain prices its own storage operations — the reads and writes to its database. Those were set conservatively, using cost estimates suited to slow disk access. In practice, while a block is being produced, that data lives in memory and is far cheaper to touch. Measuring the real cost and updating the accounting to match roughly tripled token-transfer throughput — from ~1,150 to ~3,550 per second — with no change to hardware and the two-second block time unchanged. The conservative starting point was a reasonable default when the network launched and its true limits weren’t yet known; the measurement simply replaced an estimate with a fact.
What a headline number is made of
Whenever performance comes up, someone points to a giant number, so here’s a well-known one, unpacked. — a network built as a central “relay” chain coordinating many parallel “” — reported about 143,000 transactions per second in a public stress test. That figure is an aggregate, built from two things:
- Bundling: each transaction packed roughly 100 token transfers, and the count reports every individual transfer.
- Parallelism: the work ran across dozens of parachains at the same time, and the number sums all of them.
Both are legitimate. Running many chains in parallel is exactly how a network reaches enormous aggregate throughput — a genuinely powerful design, and a different measurement than a single chain’s per-transaction rate. Expressed per transaction, per chain, that run works out to roughly 1,300 transactions per second, and Satsuma — a single chain — is in a comparable range. The point isn’t that one design beats another; it’s simply to check what a “TPS” number is counting before setting two of them side by side.
Reproducible by design
Everything above comes from a repeatable benchmark: the same setup, the same load generators, the same raw data. The measurements and the method are here; the interpretation is yours. More of this work — architecture write-ups and head-to-head comparisons — is on the way; follow along on X or grab the RSS feed.