Three ways to run a chain. One honest comparison.
Public networks, enterprise chains, and Satsuma make different trade-offs on access, transparency, and accountability. Here is where each one lands — including where a public chain is the right answer and Satsuma isn't.
At a glance
| Dimension | Public L1 / L2 | Enterprise chain | Satsuma |
|---|---|---|---|
| Who can write | Anyone with gas | Members, gated at the network perimeter | Allowlisted accounts, enforced by consensus rules |
| Who can read | Everyone | Typically members only | Everyone — no account, no API key |
| Finality | Probabilistic, or minutes (L2 → L1 settlement) | Varies by deployment | Deterministic BFT, ~6 s |
| Fees | Auction-driven, volatile | Often zero-fee, unmetered | Metered, utilization-targeted, stable |
| Front-running / MEV | Structural — open mempool | Low — closed membership | Removed by design — no anonymous writers |
| Operator | None — best-effort, no accountable party | A consortium; governance varies | A single accountable operator |
| Trust model | Trustless (economic security) | Trust the consortium; often opaque | Accountable: trusted operator, every action on a public ledger |
| EVM compatibility | Native or high | Varies | Full — Solidity unmodified, standard JSON-RPC |
Satsuma vs public chains
Public blockchains are the right tool when you need trustlessness against everyone — including the operator. Their design pays for that property with volatile auction fees, open mempools where bots front-run intent, and finality that is either probabilistic or minutes away. For autonomous software holding a budget and executing a plan, each of those is a hazard.
Satsuma inverts the trade: it gives up permissionless writing and gains a stable 2-second clock, deterministic ~6-second finality, fees an agent can budget for, and counterparties that are known and admitted. Reads stay as open as any public chain — every balance and every transaction is publicly verifiable.
We say this plainly: for workloads that require trustlessness against their own operator, a public chain remains the right tool. Satsuma's guarantee is not “trustless” — it is accountable.
Satsuma vs enterprise chains
Permissioned enterprise deployments gate access at the network edge — firewalled RPC endpoints, API keys, VPNs — and are usually opaque to anyone outside the consortium. That perimeter is also their weakness: a misconfigured endpoint is an open door, and outsiders can verify nothing.
Satsuma enforces admission inside transaction validation, at the same protocol stage that verifies signatures. A transaction from a non-admitted account is invalid by consensus rules, no matter which node it reaches — so the public RPC endpoint can stay public, and the entire state of the chain stays readable by anyone. A permissioned chain does not have to be an opaque one.
Curious how that works in practice? See the architecture, read the litepaper, or watch the chain seal blocks on the chain page.