> ## Documentation Index > Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt > Use this file to discover all available pages before exploring further. # IntentionKernel > Intention's execution core: a state machine built for trading, with a fully on-chain order book and a decentralized clearinghouse inside it. IntentionKernel is the core of Intention: a state machine built for trading, used in place of a general-purpose virtual machine. The on-chain order book and the Clearinghouse are both part of it. Matching, margin, liquidation, and settlement run in the same block, on one ledger, in the order consensus committed. ## 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. | Group | Operations | | - | - | | **Orders** | Place, cancel, replace, amend | | **Accounts** | Sub-accounts, leverage, margin mode, position mode | | **Transfers** | Between accounts, and in and out through the [bridge](https://docs.intention.xyz/protocol/architecture/stack/services.md#bridge) | | **Agents** | Authorize and revoke an agent that trades for an account | | **Vaults** | Create, deposit, withdraw, configure | | **System** | Market listing, fees, leverage tiers, and risk parameters, authorized by governance; certified prices from validators | A transaction outside this set is rejected at validation. The set changes only through a protocol upgrade, never by deploying new code. OperationsA payload that is not a member of the enumerated set — rejected at validation, not at runtimeWhat was actually asked forTruthTreating the per-block working set as authoritative. It is a journal; engine state is the sourceWhat is true right nowInputsAnything that can differ between two machines: wall clock, entropy, floating point, hash orderWhether another node gets the same bytesCausalityA state change with no owner. Effects belonging to no user transaction get a system channel, not an exemptionWhy this particular change happenedClosedRefusedSo the ledger can answerFour closures, one move: enumerate the space in advance and refuse what falls outside it. Execution is deterministic: every correct node that runs the same block on the same state gets the same result, byte for byte. Settlement math is integer fixed-point with fixed rounding rules. Nothing reads a wall clock or a random number, and nothing depends on hash order. ## Six stages per block Every block runs through the same six stages, in the same order. Pricecompute the marks from certified pricesLoadingest the block's accounts and ordersFundingsettle funding flowsRiskvault withdrawals → liquidation → ADLMatchpre-match → matching → post-matchFinalizecollect outputs, purge dead stateEvery downstream stage reasons about one price per instrument, not a moving oneSettled against the positions as loaded, not as they end upForced flow is resolved before any new discretionary flow is admittedRunning after Risk is why a liquidation cannot be front-run by an order in the same blockZeroed positions and emptied accounts do not persistOne block, six stagesWhat the placement determinesConditional 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. **Price** fixes one mark per instrument for the whole block. Consensus certifies the index and the external perpetual price; every node computes the mark from them the same way. **Load** brings in the accounts and orders involved. **Funding** settles against positions as loaded. **Risk** first processes pending vault withdrawals (cancelling the vault's orders and reducing its positions into the book), then runs liquidations, then auto-deleveraging. **Match** produces fills. **Finalize** records every change against the transaction that caused it. Risk runs before matching, so no order in the same block can front-run a liquidation. ## 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](https://docs.intention.xyz/trading/tx-sequencing.md). Order types, time-in-force, and self-trade prevention are covered under [Trading](https://docs.intention.xyz/trading/order-types.md). ## 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. | | Traditional CCP | Intention Clearinghouse | | - | - | - | | **Who can clear** | Admitted clearing members | Any address | | **Ledger** | Private | Public chain state | | **Margin** | Called end of day | Checked in the same block as the fill | | **Settlement** | T+1 or later | Same block as the fill | | **Defaults** | A risk committee decides | A fixed sequence, run by the protocol | 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](https://docs.intention.xyz/trading/liquidations.md). The risk stage, in fixed order, before matching1 · Vault withdrawals2 · Liquidation3 · ADLAn account below its maintenance requirementCancel orders and net offthe account may recover hereThe liquidation account takes overat the bankruptcy price; absorbs any loss beyond marginAuto-deleveraging opposing positionsinstead, while ADL is active; a score anyone can recomputeSettledstill below maintenanceADL active This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.