Tag
#satsuma
Satsuma owns what it builds, and fixes it without touching the money
Eleven runs. Every contract Satsuma deployed became a product it owns: a record on its chain, a repository, a list of things that must stay true, and a review of its own code by a model told to attack it. Those reviews found real defects, twenty of them, and Satsuma fixed nine by vote, three different ways: a redeploy for a contract holding nothing, a migration that moved ten thousand tokens to a successor, and in the last run an upgrade in place of the contract holding the position. In five of the last seven runs nobody touched anything.
Satsuma coordinates its work, runs what it builds, and judges the result
The same objective as the first experiment, given seven more times to a loop that changed between runs. Satsuma learned to refuse duplicate work, to run its trading as a governed operation under a policy it wrote, and to review that operation every five minutes: measure, recommend, vote, act. In the last run it amended its own policy twice, under a market rigged against it, with nobody stepping in.
Satsuma gets a goal, builds what it needs, and trades on another chain
Satsuma was given an objective and nothing else. Its own process proposed an exchange, a mandate account and a keyless executor, voted on them on chain, built them, reviewed them and deployed them across two chains. Then it used them: ten swaps on another chain, each bounded by limits it had set for itself. Nobody approved a proposal or a trade.
The Same Bridge, the Parity Way — and the Bill
We rebuilt our trustless bridge with the stack that runs Polkadot↔Kusama: pallet-bridge-grandpa plus ordered message lanes. Same trust model, different machinery — and this time every proof lands as a signed transaction with a fee on the record. The head-to-head, measured.
ISMP Bridging with Satsuma
We ran two independent satsuma chains — different genesis, different validators — and moved value between them with no multisig, no custodian, no middleman. Each chain verifies the other's GRANDPA finality on-chain, then verifies a state proof. 4 seconds end to end.
A Trustless zk Re-Genesis
The trust-minimized restart still leaned on an honest two-thirds of validators to sign. This time we replace the signatures with a zero-knowledge validity proof — anyone verifies it in milliseconds, and no coalition of validators can forge it.
The Limit of Sub-Second Blocks Is Geography, Not Speed
We built a testbed to push Satsuma's block time below one second and find where it breaks. Compute wasn't the wall. The speed of light was.
A Trust-Minimized Re-Genesis
Changing a chain's block time means halting it and relaunching from the old ledger. We built that migration on a live testbed — and made it so nobody has to trust that the balances carried over honestly.
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.
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.
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.
Introduction to Satsuma
A live, sovereign Solidity Layer-1 — Ethereum-compatible, final in seconds, public to read and permissioned to write. A visual tour of what Satsuma is and the choices that shape it.