A sovereign Layer-1, engineered for certainty.

Consensus: fixed-cadence production, explicit finality

Satsuma separates block production from finality — two protocols with two distinct jobs.

Block production rotates on a fixed schedule among a closed set of authorized validators. Each validator knows in advance which slots are its own, so blocks arrive every 2 seconds without leader elections, mining, or stake-weighted lotteries.

Finality runs alongside production as a Byzantine-fault-tolerant voting protocol. Once more than two-thirds of validators agree on the canonical chain, everything up to that point becomes irreversible. Finality is an explicit protocol event, not a probability that grows with confirmations — a finalized block can never be reorganized away. In measured operation, finality lands within roughly three blocks (about 6 seconds), even under saturating load.

Execution: the Ethereum contract you already wrote

• Solidity contracts deploy unmodified. No custom language, no transpilation, no non-standard semantics to audit around.
• Standard Ethereum JSON-RPC. The same interface every Ethereum tool already speaks: eth_sendRawTransaction, eth_call, eth_getLogs, gas estimation, and the rest.
• The existing toolchain works out of the box. MetaMask connects as a custom network; Hardhat and Foundry work against Satsuma exactly as against any Ethereum endpoint.

The access model: open reads, permissioned writes

Most "private" chains restrict access at the network edge — a firewalled RPC endpoint, an API key, a VPN. Satsuma does not rely on any of that. Admission is checked inside transaction validation, the same protocol stage that verifies signatures. A transaction from a sender not on the on-chain allowlist is rejected before it ever enters the mempool — it is invalid by consensus rules, no matter which node it reaches.

Reads are unrestricted: state queries, contract view calls, simulation, gas estimation, and event queries are open to anyone, from anywhere, without registration. Every balance, every contract, and every transaction ever executed can be independently verified. Contract deployment is doubly gated — the deployment transaction passes the standard admission check, and the deployment operation itself independently requires allowlist membership.

Fee economics: metering, not auctions

Each transaction pays in proportion to the resources it actually consumes — a compute-and-state component plus a size component per byte, paid in SUMA. Instead of a bidding market, a smooth dynamic multiplier targets 25% average block utilization: fees rise gradually under sustained load and decay back when it falls. 80% of every fee accrues to the on-chain treasury; 20%, plus any priority tip, goes to the block producer.

Chain parameters & measured performance

Measured on commodity cloud hardware with a reproducible benchmark harness (medians, with conditions — the full methodology is in the litepaper):

Want to see it running? The explorer streams the chain live — no sign-up, no wallet. Or compare Satsuma against public chains and enterprise chains.