Skip to main content
IntentionKernel is where a committed block becomes trading state. It is not a general-purpose virtual machine executing arbitrary programs — its instruction set is the enumerated set of financial operations a derivatives venue needs, and every one of them has a defined effect the protocol understands. That distinction is the reason the network can make claims about trading at all. A general-purpose chain can tell you that a transaction was signed and did not abort. It cannot tell you that the transaction was a cancel of a specific order at a specific position in the book, because the meaning of the call is opaque to it. Here the meaning is the instruction.

​
Closed-world execution

Closing the instruction set is one instance of a move the kernel makes four times. In each case the space of what can happen is enumerated in advance, and anything outside it is refused rather than handled.
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.
These are not four independent virtues. Each is load-bearing for the next: closing the operations is what makes an instruction’s meaning recoverable; a single authoritative state is what makes “the result” well defined; closing the inputs is what makes that result reproducible off this machine; and closing causality is what lets a result be traced back to the request that produced it. Drop any one and the chain of accountability breaks at that link. What the four buy together is worth naming, because traditional venues buy the same thing at far greater expense. An exchange’s audit trail is assembled beside the trading system and reported onward, which is why it can disagree with the system, why reconciliation is a standing job, and why clock synchronisation between venues is a regulatory requirement rather than an implementation detail. Here there is no second record to reconcile against. The audit trail is the execution. The rest of this page is those four closures in detail.

​
The instruction set

Everything a participant or a validator can do is one of a fixed set of typed operations: A transaction whose payload is not a member of this set is rejected at validation. The set changes only by protocol upgrade, never by deploying something new.

​
Executing a block

Execution is a fixed sequence of stages. The order is not an implementation detail — it is what determines whether a liquidation sees the price that triggered it, and whether a cancel beats an incoming aggressor.
Pricefix the marks for the block
Loadingest the block’s accounts and orders
Fundingsettle funding flows
Riskvault deleveraging → 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 marks takes effect in this block rather than the next.
Price runs first and fixes the marks the rest of the block will use, so every downstream stage reasons about one price per instrument rather than a moving one. Load ingests the block’s accounts and orders. Funding settles funding against the positions as loaded. Risk runs three phases in order — vault deleveraging, then liquidation, then auto-deleveraging — so that forced flow is resolved before new discretionary flow is admitted. Match then runs its own three phases, producing fills. Finalize collects what changed and purges state that no longer needs to exist, such as zeroed positions and emptied accounts. Conditional orders are scanned and advanced through their lifecycle within this sequence, so a trigger fired by this block’s marks takes effect in this block rather than the next.
Liquidation running before matching is why a liquidation cannot be front-run by an order in the same block. The liquidating flow is already resolved by the time discretionary orders are matched.

​
Two kinds of state

The kernel keeps a strict separation between what persists and what is scratch.
while a block executes
Engine statemarkets · accounts · books · positions · clearinghouselives across blocks
Block working setmarks · touched accounts · fills · staged outputlives for one block
Committed chain stateversioned · authenticatedthe authority
Dirty tracking is easy to mistake for authority. What changed during a block builds deterministic output — it is not where the state lives.
the authority the engine is rebuilt from
read
apply
materialize
Engine state lives across blocks: market metadata, accounts, order books, instrument state, clearinghouse state. It is the answer to “what is true right now.” Per-block working set exists only while a block is executing: the block’s inputs, the marks fixed at the start, the accounts and orders touched, and the outputs being assembled. It is a journal, not a source of truth. The distinction matters because dirty tracking is easy to mistake for authority. What changed during a block is used to build deterministic output — it is not where the state lives. Getting this backwards produces a system where the answer depends on how you asked.

​
Why the result is reproducible

Determinism here is enforced, not hoped for. Every honest node executing the same block against the same prior state produces the same result byte for byte, because nothing on the execution path can read anything that differs between nodes:
  • Fixed-point arithmetic throughout. Settlement math runs on integer fixed-point with explicit rounding semantics — round-up on negative exponents in margin, floor and ceiling on fees. There is no floating point on the settlement path, because a rounding difference between two machines is a fork.
  • No wall clock. Ordering within a block uses the canonical position committed by consensus and the block timestamp, never local time.
  • No runtime randomness. Anything requiring randomness derives it deterministically from chain state.
  • Deterministic iteration. Any collection whose iteration order is observable in the output is ordered, not hash-randomized.
One consequence worth naming: because “time” inside a block is the committed intra-block position, no sub-millisecond colocation advantage exists within a block. Combined with the priority schedule — which runs cancellations before aggressive placements — this is a structural defense against having a resting quote picked off by an order that arrived in the same block.

​
Risk formulas are pure

The formulas that decide margin requirements, liquidation prices, deleveraging selection, fees, and open-interest limits are implemented as pure, stateless functions. They take values and return values; they do not read or mutate ledger state. State changes are driven exclusively by the Clearinghouse, which calls those functions and applies the results. The modules that hold state — accounts, positions, order books — store data and expose mutators, but do not drive business flow themselves. This is a deliberate boundary. It means a margin calculation can be checked in isolation against a table of inputs and outputs, and it means there is exactly one code path by which anyone’s balance can change.

​
Output

Execution produces state writes and events, each bound to the transaction that caused it, plus a channel for system-level effects that belong to no single user transaction — funding, insurance movements, block counters. Those become the transaction outputs that the state layer commits and the indexer serves. Nothing that happens inside the kernel is invisible downstream. If it changed state, it is in someone’s output or in the system channel.

​
Where to go next

Matching

The order book, price-time priority, and how time-in-force and self-trade prevention resolve.

Clearinghouse

The single path by which balances, positions, and margin change.

State model

What the kernel’s output becomes once it is committed.

IntentionBFT

Where the ordering and the prices came from.