State model
Chain state is the single authority. The kernel keeps a working copy laid out for matching and clearing, but that copy is always derived from chain state, never the other way round.Engine statemarkets · accounts · positions · books · clearinghouselives across blocks · a reconstruction
Block working setmarks · touched accounts · fills · staged outputlives for one block · a journal
Chain stateversioned key-value, Merkle-authenticatedthe authority
The failure this preventsAn engine whose in-memory view has drifted from what was committed keeps serving answers, and every one of them is wrong in a way that only shows up at settlement.
engine state must be derivable from the committed record, never the other way round
- Every block is a version. Values are stored against the block that wrote them, so reads, proofs, and replay can target any past block, not only the latest one.
- Every change has an author. Each transaction carries its own writes and events. Effects that belong to no single user, such as funding payments and liquidation takeovers, go to a separate system channel. Nothing in the record is unexplained.
- Configuration is versioned on-chain. Fees, leverage tiers, and other parameters live in named, versioned keys. Read them from the chain; a value pinned in client code will drift from what the network applies.
Storage
Committed state is split across three stores, each tuned for one access pattern.Committed block
Ledger storetransactions · outputs · events · write sets · accumulators · block metadata
Replay and audit
State KV storecurrent and historical values, sharded sixteen ways, hot state in its own tier
Queries and execution
State Merkle storea versioned sparse Merkle tree, plus the indexes tracking superseded nodes
Verification — proofs
A read that only needs a value does not pay for tree traversal, and a proof is not reconstructed from a store optimized for point lookups.
Three choices make it fit a trading workload:
- Sharded writes. The state KV store is sharded across sixteen RocksDB instances, so one block’s writes do not contend on a single database. Frequently used state has its own tier.
- No undo on failed blocks. Results of a block that has not committed yet sit in an in-memory overlay. If the block commits, the overlay is written; if not, it is dropped. Storage never holds data that has to be rolled back.
- Cheap pruning. When a value is superseded, the old entry is marked stale in an index at the same moment. Pruning is a scan of that index, with no search for garbage.
Proofs
Two structures, both committed by consensus in every block, make the state checkable.Versioned sparse Merkle tree
Accumulators
Your key and its value
sibling hash
sibling hash
State root, committed by consensus
Your transaction, or an event
Transaction accumulator · event accumulatoreach commits to everything included so far, in order
Ledger root, committed by consensus
The tree proves what a value was; the accumulators prove what happened and in what order. Together they make “this transaction is in the chain at this position” provable without holding the chain.
- A versioned sparse Merkle tree proves what a value was at a given block. Versions share unchanged nodes, so updating one account adds one path, not a new tree.
- Two accumulators, one for transactions and one for events, prove what happened and in what order.