> ## 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. # Matching engine > How the WhiteBIT matching engine sequences and executes orders — price-time priority and participant fairness across spot, margin, and futures markets. 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](/glossary#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](/glossary#retail-price-improvement-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](/concepts/order-types#stop-market-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](/guides/market-maker-guide) and the [modify order endpoint](/api-reference/spot-trading/modify-order). ## 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](/platform/self-trade-prevention) and [order type](/concepts/order-types) flags change how an individual order behaves, not where the order sits in the matching sequence. ## What's Next Execution flags — IOC, post-only, reduce-only — and how each behaves. Colocation, quoting strategy, and the matching-engine-zone endpoint subset. STP modes for accounts running two-sided quotes.