Author: danny

Open Binance's spot and perpetual markets; the order books are almost identical. But at the moment of "selling," behind them are two fundamentally different state machines. Why does PERP maintain two sets of prices? Why must Iron Condor execute trades on all four legs simultaneously? Why are Polymarket's fees highest at p=0.5? Why do Uniswap's LPs always underperform their holders? These questions, superficially about the mechanism, essentially ask the same thing—the matching engine is never an independent engineering module; it is shaped by the assets it serves.

The differences between the five forms—spot trading, perpetual contracts, options, polymarkets, and AMMs—are far more profound than their similarities. This article breaks them down to see what forces have caused "matchmaking" to diverge into seemingly unrelated engineering entities.

I. Matching is not a standard component

If you've only looked at the matching implementation of spot trading, you might think that a "matching engine" is a mature, convergent, and almost low-tech thing—a sorted order book, a price-time priority matching loop, plus a one-time settlement path, and that's the end of the story.

Then you are very wrong.

When you shift your focus from Coinbase's BTC/USDT to Binance's BTCUSDT perpetual contract, then to Deribit's BTC-26DEC25-50000-C, and finally to a specific event market on Polymarket, you'll find that the matching engines behind these four markets are structurally almost four different machines. They share some algorithmic similarities—they all have buyers, sellers, prices, and quantities—but when you delve into aspects like state machines, risk control coupling, transaction boundaries, and trust assumptions, the differences become so significant that the term "matching engine" itself seems overly abstract.

What this article aims to do is to break down these four typical forms and see what forces cause the same underlying concept to differentiate into different engineering entities under different targets.

II. Spot Matching: The Most Basic Form

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

The core data structure typically consists of two price trees (bid side and ask side), with each price node connected to a FIFO queue. The matching loop is very straightforward: when a taker arrives, it starts scanning from the opponent's best price level, consuming the maker queue in chronological order until the taker quantity is exhausted or the price exceeds the limit price.

Several key points of the core features deserve special mention:

First, the assets are homogeneous and separable. The buyer holds the quote asset (USDT), and the seller holds the base asset (BTC). Matching is essentially an asset swap. The operations on the ledger are a pair of balance additions and subtractions bound in a transaction, and settlement and matching are completed within the same transaction. The matching engine requires almost no external dependencies—matching is settlement, and there are no downstream links.

Second, the risk is instantly eliminated. The moment a spot transaction is completed, all positions disappear; the concept of "holding" does not continue at the matching level. The engine doesn't need to worry about whether you will be liquidated due to price fluctuations in the next second, because there is no such thing as "position".

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

Here's a specific scenario. In the BTC/USDT market, there's a sell order of 50,001 × 1.5 BTC (maker A places an order at 09:30:00.100), and a sell order of 50,002 × 3.0 BTC (maker B places an order at 09:30:00.200 for 1.0 BTC, and maker C places an order at 09:30:00.300 for 2.0 BTC). A market buy order of 4.0 BTC arrives. The matching cycle is as follows: first, all of 1.5 BTC from maker A at 50,001 BTC is taken; then, in the next price level, the FIFO order applies—B precedes C. First, all of 1.0 BTC from maker B at 50,002 BTC is taken, then a portion of 1.5 BTC from maker C is taken (0.5 BTC remains in the order book). In the same transaction, the taker account deducts 200,006.5 USDT and adds 4.0 BTC; the three maker accounts update accordingly in reverse. This series of operations is completed within a single database transaction; matching is equivalent to settlement. It's worth noting that B's transaction precedes C's is not due to price (same level), but because B was listed first—this is a practical manifestation of price-time priority.

The challenges in spot trading matching engineering lie not in the logic, but in performance: how to maintain microsecond-level latency under millions of TPS, how to handle cache locality of hot and cold paths, and how to achieve deterministic replay. However, these are optimization problems, not mechanism problems.

III. Perpetual Contract Matching: The Intrusion of the Risk Control Engine

If you place a screenshot of Binance's perpetual contract order book next to the spot order book, you might not see the difference with the naked eye. But the underlying structure reveals a completely different picture.

The key change is that the matching engine is not the end point of settlement, but merely a source of events. (aka, a domino effect)

Each PERP match triggers a complex downstream chain: price update, position update, margin recalculation, unrealized profit/loss refresh, and potential liquidation triggers. The matching engine and risk engine are deeply coupled in PERP, and this coupling method determines the character of the entire system.

The dual-price system is PERP's first unique structure. Matching itself is still driven by the "last traded price," but maintenance margin, liquidation triggers, and UPnL calculations use the "mark price," which is synthesized from multiple spot market indices plus a funding adjustment. This is an anti-manipulation design: if the matching price and the mark price were the same, an attacker could use a small amount of capital to manipulate the order book to an extreme price, instantly triggering the liquidation of all inverse positions. The dual-price system eliminates this attack surface.

Let's illustrate the role of dual prices with a specific scenario. A trader enters with 50x more BTC (1 BTC), totaling 60,000, with an initial margin of 1,200 USDT and a maintenance margin of 300 USDT. At a certain moment, a large market order instantly drives the order book down to the last price of 58,500—an unrealized loss of 1,500 USDT based on the last price, resulting in a margin call. However, at the same moment, the mark price (weighted by the spot index plus funding adj) is 59,400, resulting in an unrealized loss of 600 USDT based on the mark price. The account equity of 600 is greater than the maintenance margin of 300, so liquidation is not triggered. A few seconds later, the last price returns to 59,400, and the trader is not wiped out by the spike. If the order book and liquidation share the same last price, an attacker could use a small amount of capital to push the price to an extreme level when the order book is weak, triggering a chain reaction of liquidations on the opposite position, followed by a buyback at a lower price—this was a type of event that frequently occurred in the early days of BitMEX. The dual-track system is not "for precision," but "to avoid being attacked."

Pre-trade risk control is another crucial point. In spot trading, orders are matched directly upon arrival; in PERP, orders must first undergo a margin check—can your available margin cover the position changes resulting from this trade? If it's a cross-margin trading system, this check also considers the mutual hedging of all positions in your account. This check must be completed synchronously within the matching cycle; otherwise, inconsistencies will arise, such as "insufficient margin discovered only after the trade."

The special matching channel for forced liquidation is the most interesting part of the PERP engine. When an account's margin ratio falls below the maintenance line, the forced liquidation engine takes over—it sends an IOC order to the order book at the account's bankruptcy price (or a certain protection price) to attempt to close the position. What if the order book is too thin to handle this forced liquidation order? There are several engineering options: one is to connect to the insurance fund for a safety net, and the other is to trigger ADL (automatic reduction of positions), where the system forcibly reduces the profitable counterparty's position.

ADL is essentially the "last link in the matching process": when both the order book and insurance fund fail, the system skips the order book and performs a forced settlement directly between the two accounts. This is a design that extends the concept of "matching" from "voluntary matching" to "involuntary matching"—it no longer belongs to the traditional sense of matching, but it must exist, otherwise the system will go bankrupt under extreme market conditions.

The complexity of Self-Transaction Prevention (STP) is also unique to PERP. In spot trading, STP mainly prevents order liquidation; in PERP, the same account can hold both long and short positions simultaneously (hedge mode), so the semantics of STP need to be further refined: is it based on sub-account, user ID, or master account? Different exchanges choose different approaches.

In summary, the difficulty of PERP matching lies not in the order book itself, but in the entire state machine behind the order book that is tied to the risk engine. Designers must clearly define: which checks are on the main matching path (synchronous) and which can be asynchronous; what execution model to use for forced liquidation; how to allocate insurance funds; and how to prioritize ADL trigger queues (usually sorted by "profit percentage × leverage ratio," ensuring that the highest-earning and highest-leveraged investors are liquidated first).

IV. The Two-Path Approach to Perpetual Matchmaking: Layered Decision-Making, Construction, and Execution

There's another layer in PERP's matching process that deserves special discussion: the forced liquidation path merges with regular orders in the matching stage, but the logic before and after the merger is completely different. Understanding this layer is crucial for designing or debugging the PERP engine—otherwise, the boundaries between "matching" and "liquidation" will be repeatedly blurred.

Let's break down the forced demolition into three layers:

The first layer is the trigger judgment. The mark price is used—the purpose is to prevent the decision of "whether to liquidate" from being affected by the instantaneous manipulation of the order book. This layer is completely independent of the market depth and is an independent risk control judgment.

The second layer is order construction. After the liquidation engine decides to liquidate, it constructs an IOC order and sends it to the order book. This order differs structurally from a user's ordinary order in several dimensions: the price is not selected by the user but is set by the engine based on the bankruptcy price; the type is always IOC and rest in book is not allowed; the fee is the liquidation rate (0.5–1.5%) instead of the taker rate, and flows to the insurance fund; the order placement authority belongs to the system, not the account—when an account is liquidated, all its pending orders in the book will be forcibly cancelled first (to avoid self-trading contaminating the liquidation); the fallback is different—if a user's IOC cannot be acquired, it disappears, but if a liquidated IOC cannot be acquired, it triggers a cascading effect of insurance fund → ADL.

The third layer is the matching execution. Once in the order book, liquidated IOCs and regular IOCs follow the exact same price-time priority rules to acquire counterparty liquidity. This layer is symmetrical; the matching engine does not "specially treat" the matching priority of liquidated orders—the matching loop should not have such if-else statements, otherwise it would disrupt the deterministic replay.

Therefore, the precise description is: the matching cycle itself is not divided into two sets, but the order source, construction, billing, and failure path are divided into two sets. From the perspective of the main matching path, forced liquidation and ordinary orders are equal; from the perspective of the overall transaction, they follow two parallel channels, only merging at the matching stage.

Another important point is that the mark price determines "at what price liquidation should occur" (the trigger condition), but the last price (market depth) determines "at what price liquidation can actually occur." When the order book is thin and market depth is exhausted, the actual transaction price at which liquidated IOCs are bought up along the order book is far worse than the bankruptcy price. This gap is the "source of profit and loss" for the insurance fund. The insurance fund essentially absorbs the discrepancy between "the theoretical liquidation price given by the mark" and "the actual transaction price executed on the market." If the two were always consistent, the insurance fund would be unnecessary.

More radical designs (Hyperliquid's HLP, dYdX's early backstop liquidator network) simply add a "liquidation market" layer in front of the order book—allowing specialized market makers to preemptively take over entire positions at an agreed discount, bypassing the slow path of the order book. Essentially, this completely separates "liquidation execution" from the on-exchange matching process, giving the clearing path its own matching channel. This is another way to answer the dual-path problem: some exchanges consider cramming both paths into the same order book a compromise, and simply allow them to use different matching channels.

Returning to the core of PERP's matching complexity: while the main matching loop itself can remain simple, the surrounding state machines—risk control, clearing, insurance funds, ADL, and possibly a backstop liquidator network—constitute a system far more complex than the order book itself. Behind the visual illusion that the "order book looks the same as the spot market" lies two independent entry channels and four different exit paths. This is the true shape of the "difficulty" of PERP matching. (It's rumored that some exchanges have even implemented a B-book.)

V. Options Matching: Grid-based and Market Maker-led

Options are the only category among these four types of underlying assets where the "underlying asset itself experiences an explosive increase in quantity." A BTC spot market has only one order book; a BTC perpetual contract also has only one; but BTC options—taking Deribit as an example—have hundreds of active contracts at any given time, resulting from a combination of strikes, expiries, and calls/puts. Each contract requires an independent order book.

This leads to the first fundamental problem: liquidity scarcity. Deep in-the-money or out-of-the-money contracts may only have a few trades per day, and the order book is often empty or contains only two pending orders from market makers. This scarcity makes the pure LOB model almost unusable—a typical buyer placing a limit order may have to wait several days for it to be executed.

The industry's solution is a hybrid of three models:

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

RFQ (Request For Quote) is used for contracts with sparse liquidity. Traders submit a quote request, multiple market makers respond, and the trader chooses the best one. This process operates outside of LOB (Listed Invoices), matching "inquiry orders vs. multiple quote responses," essentially a reverse auction.

Block trades are used for very large orders. Two counterparties agree on a price off-exchange, then report the trade to the exchange for registration and settlement. The order book does not participate in matching, but only in registration.

Multi-leg simultaneous matching is another core requirement of options matching. A common strategy—such as iron condor—requires buying and selling four different option contracts simultaneously. If the four legs are matched independently on four different order books, the result might be that two legs are filled while the other two are not, leading to undesirable risk exposure for the trader. Therefore, options matching engines must support combo book or multi-leg atomic execution: all four legs are either filled or not filled, treated as a single unit.

Deribit's approach is considered the current industry standard: it has a separate combo order book, where combo orders can be placed independently or impliedly matched with single-leg order books—the system automatically synthesizes combo prices from single-leg liquidity and vice versa. This is a very ingenious design, but it also means that the state synchronization of the "virtual order book" must be maintained on the main matching path.

Let's illustrate why multi-leg simultaneous matching is not an option with a specific scenario. ETH is currently priced at 3,000. A trader predicts the price will fluctuate within the [2,900, 3,100] range over the next 7 days and constructs an Iron Condor: sell 3,100 Calls, buy 3,200 Calls, sell 2,900 Puts, and buy 2,800 Puts. The net income from these four legs represents the portfolio's maximum profit, and the maximum loss is strictly capped due to the protective legs—this is the premise for the strategy to succeed. If the four orders are submitted independently to four different order books for matching, the most common failure scenario is: the first two orders (call spread) are executed, ETH jumps to 2,950 within milliseconds, and the counterparty quotes for the latter two orders (put spread) become invalid, the market maker cancels the orders or makes significant adjustments, and C and D are not executed. As a result, the trader holds a naked call spread—the directional exposure is completely reversed, the original "profit from fluctuations" strategy becomes "loss on bearish bets," and the maximum loss is no longer bounded. Combo books package the four legs into a single unit: either all four succeed or none succeed; implied matching further allows the liquidity of a single-leg order book to be synthesized into a combo quote in real time, and conversely, the liquidity of a combo order book will flow back to the single leg, with the two layers of liquidity complementing each other.

Market makers primarily use Implied Volatility (IV) in their pricing algorithm, rather than price (a feature unique to options). Market makers don't place "50,000 strike call $1,500" orders; instead, they place "buy at 65 vol, sell at 67 vol." The system calculates the actual price using the BSM (or a more complex model) based on the current underlying price each time a quote becomes effective. This means that market makers' quotes dynamically follow the underlying price, and the order book automatically adjusts as the underlying price changes—making "pending orders" a continuous function rather than a discrete event in options.

Greeks-based portfolio margining also changes risk management. In PERP, each position has its own margin calculation; in options, market makers may hold hundreds of contracts simultaneously, and calculating the margin for each contract individually would be too inefficient for operations. Therefore, options exchanges typically use portfolio margining based on Greek letters (delta, gamma, vega, theta), treating the entire portfolio as a single net exposure and calculating margin in net Greeks. This, in turn, affects matching—the "margin cost" of a trade depends on whether it hedges your existing positions.

VI. Polymarket Matching: A Hybrid On-Chain and Off-Chain Architecture

Before delving deeper, let's address a potential question: Why is Polymarket listed separately, and why isn't AMM discussed? Instead of merging it into a generalized "DEX matching" category?

Polymarket's uniqueness doesn't lie in its "on-chain" label. What truly makes Polymarket unique is the combination of three mechanisms: [0, 1] price clamping + CTF complementary minting + UMA outcome determination (similar to mark price). Together, these three mechanisms create a state machine structure distinct from spot, perp, options, and other DEXs—a discrete and bounded price space, liquidity generated from nothing, and a definite lifecycle.

The following discussion will focus on these three mechanisms and the trust assumptions behind them.

Polymarket is a prediction market (or perhaps the first?) built on Polygon, where all positions are held in ERC-1155 tokens issued by Gnosis's Conditional Token Framework (CTF). A market—such as a binary prediction for a presidential election—issues two tokens: a YES token and a NO token. At the market's close, one token is worth $1, and the other is worth $0.

The complementary minting mechanism is the core of CTF. Anyone can deposit 1 USDC and receive 1 YES + 1 NO. Anyone can also burn 1 YES + 1 NO and redeem 1 USDC. This mechanism allows market makers to provide liquidity to the market "out of thin air"—market makers do not need to hold tokens before selling; they can mint and sell instantly. From the matching engine's perspective, this is equivalent to market makers having an unlimited initial inventory, but with costs constrained by margin—a key difference between Polymarket and traditional CLOBs.

Polymarket's overall architecture combines off-chain matching with on-chain settlement. The specific process is as follows: a user signs a limit order using EIP-712 and sends it to Polymarket's centralized matching server; the server maintains a traditional LOB (Logistic Asset Block); when two orders match, the server packages the two signatures into an on-chain transaction and calls the exchange contract to complete the settlement. Therefore, matching itself is off-chain (milliseconds), but settlement is on-chain (seconds).

This architecture has a unique feature at the trust layer: the matching server cannot forge transactions because it does not have the user's private key; however, it can vet transactions—rejecting the matching of certain orders.

Gas economics shapes settlement paths, not user behavior. A common misconception is attributing Polymarket's gas costs to users—in reality, the gas is paid by the relayer (Polymarket's operator). Users place orders using EIP-712, the relayer matches the orders and submits the batch of transactions to the blockchain, the gas is borne by Polymarket, and then recovered through transaction fees. This means that for users, placing and canceling orders is free—cancellations don't even go onto the blockchain; they simply notify the matching server to remove the order, logically no different from canceling an order on a CEX.

This doesn't mean gas has no binding force; it simply means the constraint has shifted to the relayer side: the on-chain settlement cost for each transaction is borne by Polymarket, and the relayer's gas budget plus Polygon's throughput limit jointly determine the system's maximum transaction frequency. Market makers don't experience "expensive order placement" during extreme congestion; instead, they experience settlement delays and throughput bottlenecks—a completely different congestion transmission path from CEXs.

The real shaping effect this architecture places on the matching engine is that it must enable the relayer to settle multiple transactions in batches (amortizing gas) while ensuring that each transaction is independently verifiable within the settlement contract (preventing the relayer from tampering with or misappropriating the funds). Therefore, Polymarket's exchange contract is designed to accept a structure of "multiple signed orders + one batch submission". Gas does not make Polymarket a "low-frequency market", but it makes its matching-settlement coupling method different from both CEXs and pure on-chain DEXs - the matching layer fully inherits the lightweight nature of CEXs (millisecond order cancellation, zero-gas order placement), while the settlement layer inherits the verifiability constraints of on-chain DEXs.

The finality of oracle results is the most unique aspect of prediction market matching. The other three types of markets are "continuously running"—prices are always changing, and the market is always open. But prediction markets have a definite "termination point": an event occurs, the result is parsed by the oracle (Polymarket uses UMA's optimistic oracle), a YES or NO is determined (there are also times when it can be argued, which will not be discussed here), and all positions are settled at 1:0 or 0:1. This means the matching engine must handle a "market frozen" state machine: prohibiting new orders within the parsing window, allowing challenges within the dispute window, and stopping all trading activity after final settlement. This state machine has no equivalent in CEX spot trading.

The price being clamped to [0, 1] is another constraint. This seems like an advantage (preventing margin calls to infinity), but it means the order book has a limited space for price tiers—usually 1 cent per tier, with a maximum of 100 tiers. 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 there's an upper limit to the precision of price discovery.

Let's illustrate how mint/redeem shapes market-making behavior with a specific scenario. In a certain market, YES is quoted at $0.65 and NO at $0.35 (YES + NO must equal $1, otherwise arbitrageurs would immediately mint or redeem to level the price). Market maker M wants to provide sell-side liquidity to this market but doesn't have any YES. He deposits 100 USDC into a CTF contract, instantly obtaining 100 YES + 100 NO. He then sells the 100 YES at $0.66 and the 100 NO at $0.36. After both trades are executed, M holds 0 net exposure and earns a spread of 0.02 × 100 = 2 USDC. This is the standard practice of market making in Polymarket: using mint/redeem to replace "capital occupation" with "two-way price spread".

It's worth analyzing in detail that the invariant matching engine, YES + NO = 1, doesn't require active maintenance; it's automatically guaranteed by the market structure through arbitrageurs. This kind of "market structure-inherent invariant" doesn't exist in traditional LOBs, and market makers can't "sell without having inventory." Polymarket's matching engine design thus eliminates some of the inventory constraint checks required by CEXs, but at the cost of integrating the mint/redeem path as a first-class citizen into the settlement contract.

To summarize the unique characteristics of Polymarket's matching mechanism: the trust assumption is a hybrid of "off-chain matching + on-chain settlement," the token model is a complementary minting mechanism of CTF, the price space is a bounded discrete [0,1], the time dimension has an end, and gas is borne by the relayer and recovered through transaction fees. These constraints combined create a matching engine that is completely different from the previous three types.

VII. Where do the differences come from: A five-dimensional framework

By examining these four models, we can extract five dimensions to explain why matching engines differentiate under different targets:

By placing the five-dimensional framework on the two dimensions of "matching-risk control coupling degree" and "liquidity density", the positions of the four forms become clear: spot trading is in the comfort zone of low coupling and high density, perpetual trading is in the high coupling and high density zone (the most complex engineering reality), options trading is in the high coupling and low density zone (sparseness must be compensated for by RFQ + combo), and polymarket trading is in the middle - the coupling degree is increased by on-chain settlement, and the density is increased by complementary minting.

Each dimension puts pressure on the matching engine:

The asset type determines the number and sparsity of order books. Single-dimensional homogeneous assets (spot, perp) only require one book, while multi-dimensional sparse assets (options) require hundreds of books and must address sparsity. Discrete complementary assets (polymarket) require integrating "mining/redemption" into the matching path.

The settlement sequence determines the complexity of the state machine. Real-time synchronization (spot market) makes matching equal to settlement; continuous accounting (PERP, options) requires maintaining the position status, margin status, and PnL status, and updating them after each matching; final resolution (Polymarket) requires the state machine to transition from "open" to "frozen" to "resolved".

Risk topology determines the degree of risk control coupling. Linear zero position (spot) requires almost no risk control; linear continuous exposure (perp) requires pre-trade margin checks and a liquidity engine; convexity (options) requires Greeks-based portfolio margin; binary bounded (prediction) requires almost no risk control (the maximum loss is the money already paid).

Liquidity density determines the liquidity sourcing strategy. High-density markets can rely solely on LOBs (Liquidity on Banking); sparse markets must introduce supplementary mechanisms such as RFQs (Request for Quotations), AMMs (Average Market Makers), and market maker incentives.

Trust boundaries determine which components must be verifiable. In a CEX, all components are internal to the exchange; in a pure DEX, all components are on-chain; in a hybrid architecture, it is necessary to clearly define what must be on-chain (settlement), what can be off-chain (matching), and what the attack model is (unable to steal money but auditable).

8. No step is superfluous: Matching is a mirror of the mechanism.

Returning to the initial question—why do "matching engines" diverge into four almost different machines in different markets?

Because matching is never an independent engineering module; it is the product of the combined effects of five variables: the nature of the underlying asset, the settlement model, the risk structure, the liquidity profile, and the trust assumptions. The matching engine is the appearance of these variables—whatever you see in the matching process, you can infer the financial structure of the market.

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

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

The hybrid form of options matching corresponds to a market structure of "dimensional explosion + sparse liquidity + market maker dominance";

Polymarket's on-chain and off-chain splitting corresponds to an engineering compromise between the two security goals of "no censorship" and "anti-theft".

If clearing is the conscience of an exchange, then the matching mechanism is its bottom line.