> ## 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.

# Order Book & Matching

> Intention Exchange runs a full on-chain central limit order book with price-time priority and a strict per-block action ordering for fair, deterministic matching — implemented at the L1, not at the application layer.

Intention Exchange's matching engine is a fully on-chain central limit order book (CLOB). Every order, cancellation, and fill is produced by IntentionKernel, sequenced by IntentionBFT, and written to state — Intention Exchange does not implement its own matcher, it inherits the L1's. There is no off-chain matcher and no hidden queue — traders see exactly the book that the chain sees.

## Matching rules

Matching uses price-time priority:

* **Price priority.** The best bid and best ask win first. For buyers, higher prices rank ahead; for sellers, lower prices rank ahead.
* **Time priority.** Among orders at the same price, the order that entered the book earliest is matched first.

A taker order (market, IOC, FOK, or a crossing limit) walks the opposite side of the book, consuming resting maker orders by price-time order until it is filled, expires, or hits a protective limit. A resting maker order keeps its position in the queue as long as it is not re-priced or increased in size — see [Modify orders](/trading/modify-orders) for details on priority preservation.

## Per-block action priority

Because Intention is a blockchain, every block packages many user actions together. To keep matching fair and predictable, the chain applies actions in a fixed order:

<Steps>
  <Step title="System operations">
    Listings, parameter updates, mark-price updates, fee updates, and other admin actions run first so subsequent actions use fresh state.
  </Step>

  <Step title="Non-matching user actions">
    Deposits, funding settlement, margin adjustments, account configuration, post-only order intake, liquidations, TWAP sub-order submissions, and conditional-order triggers.
  </Step>

  <Step title="Cancellations">
    User-initiated cancels run before any new order that might match. This makes cancels effectively preemptive — you can always pull a resting order before it trades against a just-submitted taker.
  </Step>

  <Step title="Potentially matching placements">
    New limit, market, IOC, and FOK orders enter the matching queue in FIFO order. Non-post-only orders wait two blocks off-chain before entering matching, bounding latency race conditions.
  </Step>
</Steps>

This is the ordering described in detail in [Transaction sequencing](/trading/tx-sequencing). Note that post-only orders are handled inside the non-matching phase, which is why they can reach the book without the two-block wait.

## Self-trade prevention

When a new taker would match an existing maker from the same account, the maker is cancelled before any execution. See [Self-trade prevention](/trading/self-trade-prevention).

## Execution quality controls

Intention adds several protections that keep aggressive orders sane:

* **Band limits.** Each contract enforces a per-order price band derived from the index and mark price. Orders outside the band are rejected.
* **Market-to-limit conversion.** Market orders are converted into protective limit orders before they reach matching, so a taker cannot sweep the book far beyond a reasonable slippage. See [Market-to-limit](/trading/market-to-limit).
* **Reduce-only safety.** Reduce-only orders are re-checked at match time to guarantee they never increase a position. See [Reduce-only](/trading/reduce-only).
* **OI limits.** A user's directional exposure cannot exceed a fraction of platform open interest. See [OI limits](/trading/oi-limits).

## Determinism and auditability

Because everything runs on-chain, the order book is fully reproducible from the transaction log. Any party can rebuild the exact sequence of events that led to a fill — which is what makes on-chain liquidations and [ADL](/trading/adl) ranking transparent and verifiable. The order of events within a block is a pure function of the block content, so historical audits of price-time priority are always possible.