Matching engine

Documentation Index

Fetch the complete documentation index at: https://docs.whitebit.com/llms.txt

Use this file to discover all available pages before exploring further.

The matching engine is the core system that pairs buy and sell orders across WhiteBIT spot, margin, and futures markets. A single engine serves every market: every order — regardless of account, product, or order type — enters the same order book and follows the same matching rules. Understanding how the engine sequences orders helps integrators reason about fill probability and execution timing.

​

Order matching

The engine runs continuous matching — each incoming order is evaluated for a match on arrival, with no batch-auction window, speed bump, or arrival-time randomization. Resting orders match on price-time priority: better-priced orders fill first, and orders at the same price fill in arrival sequence. At a given price level, non-RPI orders form a priority queue ahead of RPI orders. FIFO holds within each segment, but the entire non-RPI queue at that price drains before any RPI order at the same price executes — even if the RPI order arrived first. Each fill triggers re-evaluation of resting stop and trigger orders. Any stop or trigger whose condition is met by the new trade price enters the matching pipeline immediately, in the same engine cycle as the originating fill. Time priority is determined by matching-engine arrival, not by arrival at the API gateway. Order modification does not preserve queue position — the engine cancels the original order and creates a replacement with a new orderId at the back of the price level’s queue. See order modification in the Market Maker Guide and the modify order endpoint.

​

Participant fairness

All participants are subject to identical matching logic and the same latency rules. No account type, VIP tier, or market-making agreement grants matching priority, a separate venue, or a preferential queue. Internal liquidity follows the same rules as external order flow — no priority lane and no separate aggregation layer. The engine applies no prioritization by request type (submit, cancel, modify, bulk), order type (limit, market, IOC, post-only), or product (spot versus margin). The unified-path design is deliberate: a single prioritization model across every flow sustains the engine’s throughput at high request rates. Self-Trade Prevention and order type flags change how an individual order behaves, not where the order sits in the matching sequence.

​

What’s Next