Skip to main content
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:

​
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 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:
1

Deposits and funding settlement

Deposits into the exchange, manual margin additions for isolated positions, and hourly funding settlements.
2

Account configuration

Changing margin mode, position mode, leverage, or delegated agent wallets.
3

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

Liquidations

Risk checks fire, at-risk accounts have their orders cancelled, and the liquidation engine takes over affected positions. See Liquidations.
5

TWAP and conditional-order triggers

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

Transfers, withdrawals, and vault actions

Inter-account transfers, withdrawals off the exchange, and vault create/deposit/withdraw actions.

​
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)
  • 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:

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