A virtual machine built for trading
The kernel accepts a fixed set of trading operations and nothing else. Each one has a meaning the protocol understands, so the chain can say exactly what a transaction did, such as cancelling a specific order at a specific place in the book.
A transaction outside this set is rejected at validation. The set changes only through a protocol upgrade, never by deploying new code.
Operations
A payload that is not a member of the enumerated set — rejected at validation, not at runtime
What was actually asked for
Truth
Treating the per-block working set as authoritative. It is a journal; engine state is the source
What is true right now
Inputs
Anything that can differ between two machines: wall clock, entropy, floating point, hash order
Whether another node gets the same bytes
Causality
A state change with no owner. Effects belonging to no user transaction get a system channel, not an exemption
Why this particular change happened
Closed
Refused
So the ledger can answer
Four closures, one move: enumerate the space in advance and refuse what falls outside it.
Six stages per block
Every block runs through the same six stages, in the same order.Pricecompute the marks from certified prices
Loadingest the block’s accounts and orders
Fundingsettle funding flows
Riskvault withdrawals → liquidation → ADL
Matchpre-match → matching → post-match
Finalizecollect outputs, purge dead state
Every downstream stage reasons about one price per instrument, not a moving one
Settled against the positions as loaded, not as they end up
Forced flow is resolved before any new discretionary flow is admitted
Running after Risk is why a liquidation cannot be front-run by an order in the same block
Zeroed positions and emptied accounts do not persist
One block, six stages
What the placement determines
Conditional orders are scanned and advanced inside this sequence, so a trigger fired by this block’s prices takes effect in this block rather than the next.
On-chain CLOB
The order book is chain state, not an off-chain engine reporting results. Every order, cancel, and fill is executed by the kernel in the order consensus committed, and every resulting event is public and traceable to its transaction. Anyone can replay a block and rebuild the book exactly. Priority is price, then the order’s position in the committed block. Within a block, transactions are sorted by type before matching; see Transaction sequencing. Order types, time-in-force, and self-trade prevention are covered under Trading.Clearinghouse
The Clearinghouse is a decentralized central counterparty (CCP). Every fill is novated: buyer and seller each end up with a position against the protocol, not against each other. Margin, liquidation, funding, and settlement run inside the kernel in the same block as the fill, and every step is public and agreed by consensus. It is the only component that can change a balance or a position.
When an account falls below maintenance, a fixed sequence runs: its orders are cancelled, opposite legs are netted off, and the whole position moves at the bankruptcy price to the liquidation account. That protocol-owned account takes over liquidated positions and absorbs the loss. Nothing goes through the order book. While auto-deleveraging is active in the market, the position goes to profitable opposing positions instead. No keeper, no multisig, and no committee is involved. The whole sequence commits or aborts with the block. See Liquidations.
The risk stage, in fixed order, before matching
1 · Vault withdrawals
2 · Liquidation
3 · ADL
An account below its maintenance requirement
Cancel orders and net offthe account may recover here
The liquidation account takes overat the bankruptcy price; absorbs any loss beyond margin
Auto-deleveraging opposing positionsinstead, while ADL is active; a score anyone can recompute
Settled
still below maintenance
ADL active