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

# Transaction Sequencing

> Every block applies user actions in a fixed priority order so traders and integrators can reason precisely about when their orders and cancels take effect.

Intention is a blockchain, and every block packages many user actions into a deterministic sequence. To keep trading fair, predictable, and resistant to latency races, the chain applies those actions in a **fixed priority order** within each block. This page is the reference for that order — it matters for anyone building algos, HFT strategies, or integrations that depend on knowing exactly when their inputs take effect.

The priority is:

```
system operations
    > non-matching actions
    > cancellations
    > potentially-matching placements
```

## Layer 1 — System operations

The highest priority. These run first so subsequent actions use the freshest parameters: admin account changes, contract listings/delistings, risk and system parameter updates, wallet or sub-account creation, fee-schedule updates, and [mark price](/trading/mark-price) updates. System operations never race with user flow.

## Layer 2 — Non-matching actions

Actions that do not interact directly with the matching engine. They run in a fixed internal order:

<Steps>
  <Step title="Deposits and funding settlement">
    Deposits into the exchange, manual margin additions for isolated positions, and hourly [funding](/trading/funding) settlements.
  </Step>

  <Step title="Account configuration">
    Changing [margin mode](/trading/margin-modes), position mode, leverage, or delegated agent wallets.
  </Step>

  <Step title="Post-only order intake">
    Post-only limits enter the book here in FIFO order. Because post-only guarantees zero taker behavior, these placements can be processed before cancels without creating races.
  </Step>

  <Step title="Liquidations">
    Risk checks fire, at-risk accounts have their orders cancelled, and the liquidation engine takes over affected positions. See [Liquidations](/trading/liquidations).
  </Step>

  <Step title="TWAP and conditional-order triggers">
    [TWAP](/trading/twap) sub-orders fire on their schedule, and any triggered stop/take-profit conditional orders enter matching directly. Triggered conditional orders are internally ordered by trigger-price then by time.
  </Step>

  <Step title="Transfers, withdrawals, and vault actions">
    Inter-account transfers, withdrawals off the exchange, and vault create/deposit/withdraw actions.
  </Step>
</Steps>

## Layer 3 — Cancellations

All user-initiated cancellations. Because cancels run **before** any new placement that could match, a cancel submitted in the same block as a crossing taker is effectively preemptive — you can always pull a resting order before another user's taker trades against it, provided both arrive in the same block.

## Layer 4 — Potentially-matching placements

All new orders that might cross on submission:

* Limit orders (GTC, IOC, FOK)
* Market orders (which have been converted to protective limit orders — see [Market-to-limit](/trading/market-to-limit))
* Scale and TWAP initial submissions (not post-only)

These enter the matching queue in FIFO order.

### The two-block wait

Non-post-only orders do **not** enter matching in the block they are submitted. They wait **two blocks off-chain** before matching: block N receives the order, block N+1 is the wait, and block N+2 is when the order finally enters the matching queue.

This delay bounds latency-race advantages. Without it, a trader with 10 ms faster connectivity could consistently place ahead of slower traders' cancels. With a two-block wait, every placement is subject to everyone else's cancel window. Post-only orders skip the wait because they cannot take liquidity by definition.

The table below summarizes when each order type enters matching:

| Type                              | Matching entry                              |
| --------------------------------- | ------------------------------------------- |
| Market                            | Converted to IOC limit; waits two blocks    |
| Limit (GTC / IOC / FOK)           | Waits two blocks                            |
| Post-only limit                   | Enters in the same block (layer 2)          |
| Triggered stop-market / TP-market | Enters immediately in the block it triggers |
| Triggered stop-limit / TP-limit   | Enters immediately in the block it triggers |

## Consequences for integrators

* A cancel submitted in the same block as a crossing order reliably wins.
* Post-only placements and triggered conditional orders are the only paths to same-block matching.
* Front-running by resubmission is bounded — you cannot leapfrog another trader within a single block.
* The layer-2 ordering is fixed, so integrators can compute the state of the book at the start of layer 4.

This deterministic ordering is what makes on-chain matching fair: every validator computes the same outcome, and any party can replay blocks from the public log to verify it.