When you open Binance Spot and Perpetuals, the order book looks almost identical. But at the moment of "sell," there are two completely different mechanisms at play.

Why does perp need to maintain two sets of prices? Why must an Iron Condor's four legs trade together? Why are fees on prediction markets most expensive at p=0.5? These questions may seem to be about the mechanism on the surface, but fundamentally, they are all asking the same thing—the matching engine has never been an independent engineering module; it is shaped by the assets it serves.

The differences between Spot, Perpetuals, Options, and Prediction Markets are much deeper than their similarities. This article breaks them down to understand what forces have made "matching" diverge into nearly unrelated engineering entities.

1. Matching Is Not a Standard Part

If you have only seen the matching implementation of Spot trading, you may think a "matching engine" is a mature, convergent, and almost technically trivial matter—an ordered order book, a price-time priority matching loop, plus a one-time settlement path, end of the story.

But you would be quite mistaken...

When you shift your perspective from Coinbase's BTC/USDT to Binance's BTCUSDT Perpetual Contract, then to Deribit's BTC-26DEC25-50000-C, and finally land on some event market on Polymarket, you will find that the matching engines behind these four markets are almost four different machines in structure.

They share some algorithmic similarities—they all have buyers, sellers, prices, quantities—but when you delve into aspects like state machines, risk coupling, transaction boundaries, trust assumptions, the differences are so vast that the term "matching engine" itself seems too abstract.

The aim of this article is to unpack these four typical forms and understand the forces that have differentiated the same underlying concept into different engineering entities across different underlying assets.

2. Spot Matching: The Most Basic Form

Spot matching is a standard model, and almost all textbooks and open-source projects (such as LMAX Disruptor, a simplified version of CME Globex, various open-source matching engines) start from here.

Core Data Structure is usually two price trees (bid side, ask side), with each price node hosting a FIFO queue. The matching process is very straightforward: when a taker order arrives, it scans from the counterparty's best price level, consumes the maker queue in chronological order until the taker order is exhausted, or the price crosses the limit price.

Core Features have several key points worth highlighting:

First, assets are homogenous and fungible. The buyer holds the quote asset (USDT), the seller holds the base asset (BTC), and the nature of the match is an asset swap. The ledger operation is a pair of balance additions and subtractions bound together in a transaction, with settlement and matching occurring in the same transaction. The matching engine requires almost no external dependencies—matching is settlement, with no downstream chain.

Second, risks are instantly cleared. The moment a spot trade is executed, all position relationships vanish, and there is no concept of "holding" at the matching layer. The engine does not care if you will be liquidated due to price fluctuations the next second because there is no concept of a "position" in the first place.

Third, order types are relatively consolidated. Limit, Market, IOC, FOK, Post-only, Stop—these are all variants of order lifecycle management.

Let's consider a specific scenario. In the BTC/USDT order book, the top ask level is 50,001 × 1.5 BTC (maker A placed the order at 09:30:00.100), the second ask level is 50,002 × 3.0 BTC (maker B placed 1.0 at 09:30:00.200, maker C placed 2.0 at 09:30:00.300).

A market order for 4.0 BTC arrives. Matching sequence: first, fully fill A's 1.5 @ 50,001, then move to the next level in FIFO order—B before C. Fully fill B's 1.0 @ 50,002, then partially fill C's 1.5 (C left with 0.5 unfilled).

The taker account deducts 200,006.5 USDT and receives 4.0 BTC, with the three maker accounts updated accordingly. This series of operations is completed in a single database transaction, where matching is settlement. It is worth noting that B is prioritized over C not based on price (same level) but on who placed the order first—this is the practical embodiment of price-time priority.

The challenge in spot matching engine lies not in logic, but in performance: how to maintain microsecond-level latency at millions of TPS, how to handle cache locality of cold and hot paths, how to achieve deterministic replay. However, these are optimization issues, not fundamental mechanism issues.

III. Perpetual Contract Matching: Invasion of Risk Engine

If you were to place a screenshot of Binance's perpetual contract order book next to the spot order book, you might not see any difference with the naked eye. But the underlying infrastructure tells a different story.

The key change is this: the matching engine is not the endpoint of settlement, but merely an event source (a.k.a. a domino).

Each completion of a perpetual contract match triggers a complex downstream chain: mark price update, position update, margin recalculation, unrealized PnL refresh, possible liquidation trigger. The matching engine and risk engine are deeply integrated at this point, and the nature of this integration determines the entire system's behavior.

The dual-price system is the first unique structure of perpetual contracts. The matching itself is still driven by the "last traded price," but the maintenance margin, liquidation trigger, and UPnL calculation use the "mark price," which is a composite of multiple spot market indices plus a funding adjustment. This is an anti-manipulation design: if the matching price aligns with the mark price, an attacker could use a small fund to push the order book to an extreme price, instantly triggering liquidation of all opposing positions. The dual system eliminates this attack vector.

Illustrating the role of dual pricing with a specific scenario. A trader goes long 1 BTC with 50x leverage, entry price at 60,000, initial margin of 1,200 USDT, maintenance margin of 300 USDT. At one point, a large market order pierces through the order book, bringing the last price to 58,500—resulting in an unrealized loss of 1,500 USDT based on the last price, causing liquidation.

However, at the same time, the mark price (weighted average of multiple spot indices + funding adjustment) is 59,400, resulting in an unrealized loss of 600 USDT based on the mark price, with an account balance of 600 > maintenance margin of 300, so liquidation is not triggered. A few seconds later, the last price returns to 59,400, saving this trader from being liquidated due to a momentary market anomaly.

If the matching engine and liquidation share the same last price, an attacker can manipulate the price to an extreme level with a small amount of funds during a vulnerable moment in the order book, triggering a cascading chain of liquidation and a buyback at a lower price — this was a type of event that frequently occurred in BitMEX's early days. The dual pricing mechanism is not "for accuracy," but "for defense against attacks."

Pre-trade Risk Control is another key insertion point. In spot trading, a market order is immediately matched; in perpetual futures trading, a market order first undergoes margin checks — does your available margin cover the position change caused by this transaction? In cross-margin mode, this check also considers the cross-collateralization of all positions in your account. This check must be synchronized within the matching loop, or else there will be a state inconsistency where "insufficient margin is discovered after the trade."

The Special Liquidation Matching Channel is the most interesting part of the perpetual futures engine. When an account's margin ratio falls below the maintenance margin, the liquidation engine takes over — it sends an immediate-or-cancel (IOC) order to the order book at the account's bankruptcy price (or a certain liquidation price) to try to close the position. What if the order book is too thin to fill this liquidation order? There are several engineering choices here: one is to access the insurance fund as a backstop, and the other is to trigger ADL (Automatic Deleveraging), where the system forcibly reduces the position of the profitable counterparty.

ADL is essentially the "final link of matching": when both the order book and the insurance fund fail, the system skips the order book and settles the position forcibly between the two accounts. This design extends the concept of "matching" from "voluntary matching" to "involuntary matching" — it is no longer traditional matching, but it must exist; otherwise, the system would go bankrupt in extreme market conditions.

The Complexity of Self-Trade Prevention (STP) is also unique to perpetual futures. In spot trading, self-trade prevention mainly prevents wash trading; in perpetual futures, the same account can hold both long and short positions (hedge mode), so the semantics of STP need to be further divided: is it based on a sub-account, user ID, or master account? Different trading platforms make different choices.

In summary, the "difficulty" of perpetual futures matching does not lie in the order book itself but in the entire state machine behind the order book that is tied to the risk engine. Designers must consider: which checks should be on the main matching path (synchronous) and which can be asynchronous; what is the execution model for liquidation; how is the insurance fund allocated; and how is the priority queue for ADL triggers sorted (usually based on "profit percentage × leverage ratio," allowing the most profitable and highest leveraged accounts to be deleveraged first).

4. Dual Path of Perpetual Matching: Hierarchical Decision, Construction, and Execution

Perpetual matching has an additional layer worth discussing separately: the liquidation path. This path merges with the matching process in the order book but follows a completely different logic before and after the merge. Understanding this hierarchical layer is crucial for the design or debugging of a perpetual engine—otherwise, the boundaries between "matching" and "liquidation" will be constantly blurred.

Breaking down liquidation into three layers:

The first layer is the trigger judgment. Using the mark price—aimed at the decision of "whether a liquidation should occur"—this layer ensures that the decision is not influenced by instantaneous order book manipulation. This layer is entirely independent of on-chain liquidity and represents a separate risk control assessment.

The second layer is order construction. After the liquidation engine determines a liquidation, it constructs an Immediate or Cancel (IOC) order to be placed in the order book.

This order differs structurally from a user's regular order in several dimensions: the price is not chosen by the user but set by the engine as the bankruptcy price; the order type is always IOC, disallowing resting in the order book; the fee follows the liquidation fee rate (0.5–1.5%) instead of the taker fee rate and flows into the insurance fund; the order placement authority belongs to the system, not the account—accounts may even have all their resting orders canceled when liquidated (to prevent self-trading that could contaminate the liquidation); the failure fallback is different—when a user's IOC order fails to fill, it disappears, while a liquidation IOC order triggers the insurance fund → Auto-Deleveraging (ADL) cascade.

The third layer is the matching execution. Once in the order book, a liquidation IOC order and a regular IOC order follow the same price-time priority rules to match against counterparty liquidity. This layer is symmetric, and the matching engine does not give special treatment to the matching priority of liquidation orders—an if-else in the matching loop would disrupt deterministic replay.

Therefore, an accurate description is: the matching loop itself is not bifurcated, but the origin, construction, fee calculation, and failure path of orders are bifurcated. From the perspective of the main matching path, liquidation and regular orders are equal; from a transactional panorama, they traverse two parallel pipelines that converge only during the matching process.

Another point worth noting—the mark price determines "at what price a liquidation should occur" (the trigger condition), but the last price (on-chain liquidity) determines "at what price a liquidation can actually be executed". When the order book is thin and liquidity is exhausted, the actual execution price of a liquidation IOC order can be significantly different from the bankruptcy price, and this gap is the "profit and loss source" of the insurance fund. The insurance fund fundamentally absorbs the deviation between the "theoretical liquidation price indicated by the mark" and the "actual execution price on-chain". If these two prices always match, the insurance fund would be unnecessary.

A more radical design (dYdX's early backstop liquidator network) simply added a layer in front of the order book called the "counterparty-agnostic path for liquidation" — allowing the backstop vault or whitelisted liquidators to take over the entire position first, bypassing the slow path of the order book. This essentially decouples "liquidation execution" from on-chain matching and provides its own matching channel for the liquidation path. This is another way to address the dual-path issue: Some trading platforms consider squeezing two paths into the same order book a compromise and instead opt to use separate matching channels.

Returning to the core complexity of perp matching: while the matching core loop itself can remain simple, the surrounding state machine — risk management, liquidation, insurance fund, ADL, and possibly a backstop liquidator network — forms a system much more complex than the order book itself.

Behind the visual illusion of an "order book that looks the same as spot" are actually two independent entry pipelines and four different exit paths. This is the true shape of the perp matching "challenge." (It is rumored that some trading platforms even have a B-book.)

Chapter Five: Options Matching - Grid Trading and Market Maker Dominance

Options are the only one of these four asset classes where the "underlying asset itself has an explosive quantity." A BTC spot market has only one order book; a BTC perpetual also has only one; but BTC options — using Deribit as an example — have several hundred active contracts at any given time, combined across three dimensions of strike × expiry × call/put. Each contract requires its own order book.

This brings about the first fundamental issue: sparsity of liquidity. Contracts that are deep in-the-money or out-of-the-money may only see a few trades in a day, with the order book often empty or only showing the two orders from market makers. This sparsity makes a pure limit order book model almost unusable — an ordinary buyer placing a limit order may have to wait for days for it to be filled.

The industry's solution is a blend of three modes:

LOB for the most liquid contracts, mainly ATM options and near-month contracts. This part is not fundamentally different from spot logic.

RFQ (Request For Quote) for illiquid contracts. Traders send out quote requests, multiple market makers respond, and the trader selects the best offer. This process operates outside the LOB, matching "quote requests vs multiple quote responses," essentially being a reverse auction.

Block Trade is used for large-scale transactions. Two counterparties agree on a price off-exchange, report the trade to the trading platform for clearing and settlement, the order book is not involved in matching, only in registration.

Multi-Leg Synchronized Matching is another core requirement for options matching. A common strategy—such as an iron condor—requires buying and selling four different options contracts simultaneously. If the four legs are matched independently on four order books, the result may be that two legs are filled while the other two are not, leaving the trader with unexpected risk exposure.

Therefore, an options matching engine must support a combo book or multi-leg atomic execution: all four legs must either be filled together or not filled at all, treated as a whole.

Deribit's approach should be considered the current industry best practice: it has a separate combo order book where combo orders can be placed independently or matched with single-leg order books through implied matching—the system will automatically synthesize combo prices from single-leg liquidity and vice versa. This is a very sophisticated design, but it also means that the main matching path must maintain synchronized state with the "virtual order book."

Illustrating a specific scenario explains why multi-leg synchronized matching is not optional. With ETH's current price at $3,000, a trader anticipates a range of [2,900, 3,100] for the next 7 days and constructs an Iron Condor: selling the 3,100 Call, buying the 3,200 Call, selling the 2,900 Put, and buying the 2,800 Put. The net income from the four legs is the strategy's maximum profit, and the maximum loss is strictly capped due to the protective legs—this is the premise of the strategy.

If the four orders are submitted independently to four different order books for matching, the most common failure scenario is as follows: the first two orders (the call spread portion) are executed, ETH jumps to $2,950 within milliseconds, and the counterparties for the last two orders (put spread portion) have invalid quotes, causing market makers to cancel or significantly adjust their orders, resulting in legs C and D not being filled. As a result, the trader ends up holding a naked call spread—completely reversing the directional exposure. The originally "range-bound benefiting" strategy turns into "bearish loss," and the maximum loss is no longer bounded.

A combo book packages the four legs as a whole: either all fill or none fill; implied matching further allows single-leg order book liquidity to be synthesized into real-time combo prices, and vice versa, the liquidity of the combo order book also flows back to the single legs, mutually reinforcing liquidity on both levels.

The Market Maker's pricing algorithm primarily uses IV Implied Volatility, rather than price (which is also unique to options). Market Makers will not quote "50000 strike call $1500"; instead, they will quote "buy at 65 vol, sell at 67 vol", and the system will calculate the actual quote based on the current underlying price using BSM (or a more complex model) every time the quote is effective.

This means that the Market Maker's quote dynamically follows the underlying asset, and the order book automatically adjusts when the underlying price changes—turning "placing an order" in options into a continuous function rather than a discrete event.

Margin Requirement Greeks also change risk management. In perp, each position is margin-ed individually; in options, Market Makers may hold several hundred contracts at once, and individually margining each contract would make capital efficiency too low to operate.

Therefore, options trading platforms usually adopt a combination margin based on Greek letters (delta, gamma, vega, theta), viewing the entire portfolio as a net exposure and calculating the margin based on net Greeks. This, in turn, affects matching— the "margin cost" of a transaction depends on whether it hedges your existing positions.

VI. Polymarket Matching: On-chain and Off-chain Hybrid Architecture

Before delving deeper, let's address a potential question: Why single out Polymarket, why not discuss AMM? Why not merge it into a generalized "DEX Matching" category?

Because Polymarket's uniqueness does not lie in the "on-chain" label. The truly unique aspect of Polymarket is the stacking of three mechanisms: [0, 1] Price Constraint + CTF Complementary Forge + UMA Outcome Oracle (similar to mark price). Together, these three elements shape a state machine form distinct from spot, perpetuals, options, and other DEXs—bounded discrete price space, liquidity sourced ex nihilo, and a finite lifecycle.

Below, we will follow these three mechanisms and the trust assumptions behind them.

Polymarket is a prediction market (the first?) built on Polygon, where all positions are ERC-1155 tokens issued using Gnosis' Conditional Token Framework (CTF). In each market—such as a binary prediction on a presidential election—two tokens are issued: YES tokens and NO tokens. At market resolution, one token is worth $1, while the other is worth $0.

The Complimentary Minting Mechanism is central to the CTF. Anyone can deposit 1 USDC and receive 1 YES + 1 NO. Likewise, anyone can burn 1 YES + 1 NO to redeem 1 USDC. This mechanism allows liquidity providers to create liquidity out of thin air—providers do not need to hold the tokens beforehand to sell, as they can mint them instantly. From the perspective of the matching engine, this is equivalent to liquidity providers having infinite initial inventory, with costs constrained by the collateral—highlighting a key difference between Polymarket and traditional CLOBs.

Off-chain Matching + On-chain Settlement form Polymarket's overall architecture. The process unfolds as follows: users sign a limit order using EIP-712, send it to Polymarket's centralized matching server, which maintains a traditional Limit Order Book (LOB). When two orders match, the server aggregates these signatures into an on-chain transaction, invoking the exchange contract to settle. Thus, matching itself is off-chain (milliseconds), while settlement is on-chain (seconds).

This architecture has a unique trust aspect: the matching server cannot front-run trades because it lacks users' private keys; however, it can review trades—rejecting the matching of certain orders.

Gas Economics Shape the Settlement Path, Not User Behavior. A common misconception is attributing the gas cost on Polymarket to users—when, in fact, the relayer (Polymarket's operator) covers the gas. Users sign orders using EIP-712, and upon matching, the relayer submits the batched trades on-chain, with Polymarket bearing the gas costs later recouped through transaction fees. Hence, for users, placing and canceling orders are free—order cancellations may not even go on-chain; they merely notify the matching server to remove the order, sharing a logical similarity with CEX cancellations.

However, this does not mean that gas is not constraining; rather, the constraint has shifted to the relayer side: the on-chain settlement cost of each trade is covered by Polymarket, and the relayer's gas budget + Polygon's throughput limit jointly determine the system's maximum trading frequency. Liquidity providers feel not the "cost of placing an order" during extreme congestion, but rather settlement delays and throughput bottlenecks—this is a congestion propagation path completely different from a centralized exchange (CEX).

The true shaping imposed by this architecture on the matching engine is: the relayer must be able to batch settle multiple trades (amortize gas), while ensuring that each transaction is independently verifiable in the settlement contract (to prevent relayer manipulation or misappropriation).

Therefore, Polymarket's exchange contract is designed to accept the structure of "multiple signature orders + one batch submission." Gas has not turned Polymarket into a "low-frequency market," but it has made its matching-settlement coupling method different from both CEXs and pure on-chain DEXs—the matching layer fully inherits the lightweight nature of a CEX (millisecond cancellation, zero gas orders), while the settlement layer inherits the verifiability constraint of an on-chain DEX.

Finality of Oracle Result Determination is the most unique aspect of prediction market matching. The other three market types are "continuous" - prices are always changing, and the market is always open. But a prediction market has a clear "termination moment": the event occurs, the result is resolved by an oracle (Polymarket uses UMA's optimistic oracle), YES or NO is determined (there are also times when there is an argument, which is not discussed in this article), and all positions are settled at 1:0 or 0:1.

This means that the matching engine must deal with a "market freeze" state machine: new orders are prohibited during the resolution window, challenges are allowed during the dispute window, and all trading activity is halted after final settlement. This state machine has no counterpart in CEX spot markets.

Price Clamped to [0, 1] is another mechanism constraint. This may seem like an advantage (no infinite liquidation), but it means that the price level space in the order book is limited—usually one cent per tick, with a maximum of 100 ticks. This is a strong constraint on the matching data structure (you can use a fixed-size array instead of a tree), but it also means that there is a limit to the precision of price discovery.

Illustrate a Specific Scenario to explain how mint/redeem shapes market-making behavior. In a market, YES is priced at $0.65 and NO is priced at $0.35 (where YES + NO must equal $1, otherwise arbitrageurs will immediately mint or redeem to rebalance). Liquidity provider M wants to provide sell-side liquidity for this market but does not have any YES tokens. M deposits 100 USDC into the CTF contract and instantly receives 100 YES + 100 NO tokens, then places a sell order for 100 YES at $0.66 and a sell order for 100 NO at $0.36.

After both orders are filled, M holds a net zero exposure, earning a bid/ask spread of 0.02 × 100 = 2 USDC. This is the standard approach to market-making on Polymarket: using mint/redeem to swap "capital efficiency" for "two-way quote spread."

Of particular note is the invariant that YES + NO = 1, which the matching engine does not need to actively maintain. This invariant is automatically guaranteed by arbitrageurs due to the market structure—this type of "market structure-imposed invariant" is absent in traditional order books, where a market maker cannot sell without holding inventory. Therefore, Polymarket's matching engine design can eliminate some of the inventory constraints that centralized exchanges (CEXs) must enforce, but the trade-off is that the mint/redeem path must be integrated as a first-class citizen into the settlement contract.

In summary, the uniqueness of Polymarket's matching is as follows: the trust assumption is a hybrid of "off-chain matching + on-chain settlement," the token model is complementarily minted CTF tokens, the price space is a bounded discrete range [0,1], the time dimension is terminal, gas fees are covered by relayers with fee reclamation. These constraints together result in a matching engine that is fundamentally different from the first three forms.

7. Origins of Differences: A Five-Dimensional Framework

Expanding upon these four forms, we can extract five dimensions to explain why matching engines differentiate across different assets:

When placing the five-dimensional framework on the axes of "Matching-Risk Coupling" and "Liquidity Density," the positions of the four forms become clear at a glance: spot markets reside in the low-coupling high-density comfort zone, perpetual markets in high-coupling high-density (the most complex engineering reality), options in high-coupling low-density (where sparse liquidity must be compensated for by RFQ + combo), and Polymarket falls in between—its coupling is elevated by on-chain settlement and its density is raised by complementary minting.

Every dimension stresses the matching engine:

Asset Form determines the order book's quantity and sparsity. Single-dimensional homogeneity (spot, perpetual) only requires one book, multi-dimensional sparsity (options) needs hundreds of books and must solve sparsity, discrete complementarity (Polymarket) needs to integrate "mint/redeem" into the matching path.

Settlement Timing determines the complexity of the state machine. Immediate synchrony (spot) equates matching with settlement; continuous accounting (perpetual, options) requires maintaining position state, margin state, PnL state, and updating after each match; ultimate resolution (Polymarket) needs the state machine to transition from "open" to "frozen" to "resolved."

Risk Topology determines risk coupling. Linear zero exposure (spot) requires minimal risk management; linear continuous exposure (perpetual) needs pre-trade margin checks and a liquidation engine; convexity (options) needs Greeks-based portfolio margin; binary boundedness (prediction) requires minimal risk management (the maximum loss is the money already paid).

Liquidity Density determines the liquidity-sourcing strategy. High-density markets can rely solely on an LOB; sparse markets must introduce supplementary mechanisms such as RFQ, AMM, and market maker incentives.

Trust Boundary determines which components must be verifiable. In a CEX, all components are within the exchange platform; in a pure DEX, all components are on-chain; in a hybrid architecture, it must be clear what must go on-chain (settlement), what can be off-chain (matching), and the attack model (unable to steal funds but auditable).

Eight, No Step Is Redundant: Matching Is a Mirror of Mechanism

Returning to the initial question—why do "matching engines" differentiate into four almost disparate machines across different markets?

Because matching has never been a standalone engineering module; it is the product of the interaction of the underlying asset's nature, settlement model, risk structure, liquidity form, and trust assumptions. The matching engine is the manifestation of these variables—you see how matching looks, and you can infer what the market's financial structure looks like in return.

The simplicity of spot matching corresponds to a clean structure of "homogeneous assets + one-time settlement + zero position rollover";

The complexity of perpetual contract matching corresponds to the engineering reality of "synthetic assets + continuous funding + risk control-matching depth coupling";

The hybrid form of option matching corresponds to the market structure of "dimension explosion + liquidity scarcity + market maker dominance";

The on-chain/off-chain split of Polymarket's matching corresponds to the engineering compromise of two security goals: "censorship resistance" and "anti-theft".

If settlement is considered the conscience of a trading platform, then the matching mechanism is the bottom line of a trading platform.

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia