科学普及 | 理解マッチエンジン、それが取引所を理解する鍵

この記事を読むのに必要な時間は 57 分

四つの市場、四つのマシン、マッチエンジンは決して標準パーツではありません。

原文のタイトル：「取引プラットフォームの無限のマネー印刷の秘密：暗号化現物、契約、オプションから予測市場のオーダーブックマッチングエンジンのアノテーション」
原著者：danny、暗号化アナリスト

Binance の現物取引と永続契約を開くと、オーダーブックはほぼ同じです。しかし、「売り注文」の瞬間、その背後にはまったく異なる2つのメカニズムがあります。

なぜ perp は2つの価格体系を維持する必要があるのですか？なぜ Iron Condor は4本の脚が一緒に取引されなければならないのですか？なぜ予測市場の手数料は p=0.5 のときに最も高価なのですか？これらの問題は表面的にはメカニズムを問っていますが、本質的には同じことを問っています——マッチングエンジンは決して独立したエンジニアリングモジュールではなく、それがサービスする資産によって形作られています。

現物取引、永続契約、オプション、予測市場といった4つの形態の間には、類似よりもはるかに深い違いがあります。この記事では、それらを分解し、ほとんど関連性のないエンジニアリング実体に分化させる力が何かを明らかにします。

一、マッチングは標準パーツではない

現物取引のマッチング実装しか見たことがない場合、あなたは「マッチングエンジン」が1つの成熟した、収斂した、ほとんど技術的含意がないものであると考えるかもしれません——注文ブックのソート、価格および時間優先のマッチングループ、および一度限りの決済パス、それでおしまい。

しかし、それは大いに誤解です。。。

CoinbaseのBTC/USDTからBinanceのBTCUSDT永続契約、さらにDeribitのBTC-26DEC25-50000-Cに移行し、最後にはPolymarketのあるイベント市場に落ち着くと、これら4つのマーケットの背後にあるマッチングエンジンは、構造的にはほぼ4つの異なるマシンです。

これらはアルゴリズムレベルでいくつかの類似性を共有していますが、状態遷移、リスク管理の結合、トランザクション境界、信頼仮説などの側面に深入りすると、その違いは「マッチングエンジン」そのものがあまりにも抽象的であると思わせるほどに大きくなります。

この記事の目的は、これら4つの典型的な形態を分解し、異なるエンジニアリング実体に変換する力について明らかにすることです。

二、現物取引マッチング：最も基本的な形態

現物取引マッチングは標準的なモデルであり、ほとんどすべての教科書やオープンソースプロジェクト（LMAX Disruptor、CME Globexの簡略版、さまざまなオープンソースのマッチングエンジン）がここから始まります。

コアデータ構造 は通常、2 つの価格ツリー（bid サイド、ask サイド）であり、各価格ノードには FIFO キューがあります。マッチングループは非常に直感的です：テイカーオーダーが到着すると、相手方の最良価格レベルからスキャンを開始し、時間順にメイカーキューを消費していき、テイカーオーダーの数量が枯渇するか、価格が制限価格を超えるまで続けます。

コアフィーチャー にはいくつかの重要なポイントがあります：

まず、資産は同種で分割可能です。バイヤーは引用資産（USDT）を持ち、売り手は基礎資産（BTC）を持っています。マッチングの本質は資産の交換です。元帳上の操作は取引にバインドされたバランスの加算と減算のペアであり、決済とマッチングは同じトランザクション内で完了します。マッチングエンジンはほとんど外部依存関係を必要としません — マッチングは決済であり、下流のリンクはありません。

次に、リスクは即時にゼロ化されます。現物取引が完了すると、すべてのポジション関係が消失し、「ポジション保有」の概念はマッチングレイヤーで続きません。エンジンは、価格変動によるロスカットの心配をする必要がありません。なぜなら、「ポジション」の概念そのものが存在しないからです。

三番目に、オーダータイプは比較的収束します。Limit、Market、IOC、FOK、Post-only、Stop など、これらは注文のライフサイクル管理上のバリエーションです。

具体例を挙げる。BTC/USDT で、売り一定板に 50,001 × 1.5 BTC（メイカー A が 09:30:00.100 にオーダーを出し）、売り二定板に 50,002 × 3.0 BTC（メイカー B が 09:30:00.200 に 1.0 を出し、メイカー C が 09:30:00.300 に 2.0 を出す）。

4.0 BTC の成行買い注文が到着した場合、マッチングループは次のようになります：まず A が最初に 50,001 で全体の1.5 BTC を約定し、次に次の板（FIFO 順）に移動し、B が最初に 50,002 で1.0 BTC を全約定し、次に C の1.5 BTC のうちの一部を約定します（C が 0.5 残します）。

テイカーアカウントは同じトランザクションで 200,006.5 USDT を差し引き、4.0 BTC を入手し、3 つのメイカーアカウントが対応する逆方向の更新を行います。この一連の操作は、1 つのデータベーストランザクションで完了し、マッチングは決済です。B が C よりも先に成立した理由は価格ではなく（同価位）、挂パフォリティの実際の具現化です。

現物取引のマッチングエンジンにおける難点は実際には論理ではなく、パフォーマンスにあります：何百万もの取引処理を1秒未満のレイテンシで処理する方法、ホットパスとコールドパスのキャッシュロケーションをどのように扱うか、デターミニスティックリプレイをどのように実現するか。しかし、これらは最適化の問題であり、メカニズムの問題ではありません。

3. 永続契約のマッチング：リスク管理エンジンの侵入

Binanceの永続契約のオーダーブックのスクリーンショットを現物取引のオーダーブックの隣に置くと、肉眼では区別がつかないかもしれません。しかし、その下には別の景色が広がっています。

重要な変更点は次のとおりです：マッチングエンジンは清算の終点ではなく、単なるイベントソースです。（別名：ダミノ効果）

永続契約の各マッチング完了は、複雑なダウンストリームリンクをトリガーします：マーク価格の更新、ポジションの更新、証拠金再計算、未実現損益のリフレッシュ、可能性のある強制ロス売りトリガー。マッチングエンジンとリスクエンジンはここで深く結合しており、その結合方法がシステム全体の性質を決定します。

デュアルプライスシステムは永続契約の最初のユニークな構造です。マッチング自体は引き続き「最終取引価格」に基づいていますが、証拠金維持、強制ロス売りトリガー、UPnL計算には「マーク価格」が使用されます。「マーク価格」は、複数の現物市場の指標にファンディング調整を加えたものです。これは操作を防ぐデザインです：マッチング価格とマーク価格が一致すれば、攻撃者はオーダーブックを極端な価格に引き上げて、逆ポジションの強制ロス売りを一斉に引き起こすことができます。デュアルトラック制度はこの攻撃面を排除します。

具体例を挙げて、デュアルプライスの役割を説明します。あるトレーダーが1 BTCを50倍のレバレッジでロングポジションを持ち、60,000で参入し、初期証拠金1,200 USDT、維持証拠金300 USDTです。ある時点でオーダーブックが巨額の成行注文によって瞬時に最終価格が58,500に下落しました─最終価格で計算すると未実現損失は1,500 USDTで、ポジションがロスカットされました。

しかし、同時にマーク価格（複数の現物指数の加重平均 + ファンディング調整）は59,400であり、マーク価格で計算すると未実現損失は600 USDT、口座の純資産は600 USDTであり、維持証拠金の300 USDTを上回っており、ロスカットはトリガーされません。数秒後、最終価格が59,400に戻り、このトレーダーはロスカットされませんでした。

マッチングエンジンと強制清算が最終取引価格を共有する場合、攻撃者はオーダーブックが脆弱な瞬間にわずかな資金で価格を極端な位置に引き上げ、逆ポジションの連鎖的清算を引き起こし、さらに低価格で巻き戻すことができます。これは BitMEX が初期に頻繁に発生したイベントのタイプです。二元性の目的は「正確さのため」ではなく、「攻撃を回避するため」です。

プリトレードリスク管理は別の重要な挿入ポイントです。現物取引では、テイク注文が到着すると直接マッチングされます。一方、永続契約では、テイク注文はまず証拠金チェックをパスする必要があります。つまり、あなたの利用可能証拠金がこの取引によるポジションの変化をカバーできるかどうかです。クロスマージンモードの場合、このチェックにはアカウント内のすべてのポジションの相殺も考慮する必要があります。このチェックはマッチングサイクル内で同期して完了する必要があります。そうでないと、「取引後に証拠金が不足していることがわかった」という不整合な状態が発生します。

特別な強制清算マッチングチャネルは永続契約のエンジンの最も興味深い部分です。アカウントの証拠金率が維持マージンに下落すると、強制清算エンジンが引き継ぎます。エンジンはアカウントの破産価格（または保護価格）でIOC注文をオーダーブックに送信し、ポジションを決済しようとします。オーダーブックが十分に厚くない場合、この強制清算注文を実行できない場合はどうすればよいですか？ここでいくつかのエンジニアリングオプションがあります。1つは保険基金にアクセスして兜底すること、もう1つはADL（自動減額）をトリガーして、システムが利益を上げている相手方のポジションを強制的に削減します。

ADLは本質的に「マッチングの最後の手段」です。オーダーブックや保険基金が機能しなくなった場合、システムはオーダーブックをスキップし、直接2つの口座間で強制決済を行います。これは、「マッチング」の概念を「自発的なマッチング」から「非自発的なマッチング」に拡張したデザインです。これはすでに従来のマッチングには属していないが、これが存在しなければ、システムは極端なマーケット環境で破綻します。

自己取引防止（STP）の複雑化も永続契約特有のものです。現物取引では、自己取引防止は主にウォッシュトレードを防ぐためです。一方、永続契約では、同じアカウントでロングポジションとショートポジションを同時に持つことができるため、STPのセマンティクスを細分化する必要があります。サブアカウントごとに、ユーザーIDごとに、またはマスターアカウントごとに行うのか？異なる取引プラットフォームは異なります。

要約すると、永続契約のマッチングの「難しさ」はオーダーブックそのものではなく、オーダーブックの後ろにあるリスクエンジンにバインドされた状態機構全体にあります。デザイナーははっきり考えなければなりません。どの検査がマッチングのメインパス上（同期）で行われるか、どれが非同期で行われるか、強制清算の実行モデルはどのようになりますか？保険基金はどのように構成されますか？ADLトリガーの優先度付きキューはどのようにソートされますか（通常は「利益率 × レバレッジ倍率」の順に並べ替えられ、最も利益が出ていて、レバレッジが最も高い人が最初に処理されます）。

四、永続的マッチングエンジンのデュアルパス：決定、構築、実行のレイヤリング

永続的なマッチングには、議論に値するさらなるレイヤーが存在し、このパスはマッチングフェーズと通常のオーダーの収束において共有されるが、その前後では完全に異なる論理が適用されます。このレイヤーの理解は、永続的なエンジンの設計やデバッグにとって極めて重要です。さもなければ、「マッチング」と「清算」の境界が何度も混同されるでしょう。

強制ロスカットを3つのレイヤーに分解してみましょう：

第1レイヤーはトリガー判定です。マーク価格を使用し、これは「清算すべきかどうか」という意思決定を取引所の深さに瞬時に左右されないようにします。このレイヤーは取引所の深さとは無関係であり、独自のリスク管理判断です。

第2レイヤーはオーダー構築です。清算が決定された後、強制ロスカットエンジンはIOCオーダーを構築し、オーダーブックに送信します。

このオーダーとユーザーの通常のオーダーは、何つかの側面で構造的に異なります。価格はユーザーが選択したものではなく、エンジンが破産価格を制限価格として決定します。タイプは常にIOCであり、ブック内に保持されません。手数料は清算手数料（0.5〜1.5％）が適用され、テイカー手数料ではなく保険基金に流れます。発注権限はアカウントではなくシステムに属し、アカウントは強制ロスカットされる際には自身がブックに掲載したすべてのオーダーを強制的に取消します（清算汚染を防ぐため）。失敗時のフォールバックは異なり、ユーザーのIOCオーダーは約定されなければ消えますが、強制ロスカットのIOCオーダーは約定されないと保険基金→ADLのカスケードがトリガーされます。

第3レイヤーはマッチングの実行です。オーダーブックに入った後、強制ロスカットのIOCオーダーと通常のIOCオーダーは、価格と時間に基づく優先順位ルールに従って相手の流動性を消化します。このレイヤーは対称的であり、マッチングエンジンは強制ロスカットオーダーのマッチング優先度を特別扱いしません。マッチングサイクルにはこのような if-else は存在しないべきであり、そうでなければ決定論的なリプレイが崩壊します。

したがって、正確な記述は次のとおりです：マッチングサイクル自体は2つに分かれてはいませんが、オーダーの源泉、構築、請求、失敗パスは2つに分かれています。マッチングの主なパスから見ると、強制ロスカットオーダーと通常のオーダーは平等です。取引全体を見れば、それらは2つの平行したパスを歩み、マッチングフェーズでのみ交差します。

ここにもう1つ注目すべきポイントがあります——マーク価格が「どの価格で清算すべきか」を決定します（トリガー条件）が、ラストプライス（取引所の深さ）が「実際にどの価格で清算できるか」を決定します。オーダーブックが薄く、深さが不足すると、強制ロスカットのIOCは簿上で執行された実際の約定価格が破産価格とは大きく異なります。この差額が保険基金の「損失または利益の元」です。保険基金は本質的に、マーク価格が示す「理論的な清算価格」と「取引所での実行価格」との差異を吸収するものです。この2つが常に一致している場合、保険基金は存在しないでしょう。

より先進的なデザイン（dYdX の初期のバックストップ・リキデーターネットワーク）は、シンプルに、オーダーブックの前に「清算パスに独立した対向方チャネル」を追加しました。これにより、バックストップ・ボールトまたはホワイトリストのリキデーターが、取引所の遅いパスを迂回してポジション全体を優先的に引き継ぎます。これは、単純に「強制清算の実行」を取引所のマッチングから完全に独立させ、清算パス自体のマッチングチャネルを提供するものです。これは双方向パスの問題に対する別の解決策であり、一部の取引プラットフォームは、2つのパスを同じオーダーブックに詰め込むことは妥協であると考え、それらが異なるマッチングチャンネルを使用するようにします。

perp マッチングの複雑性の核心に戻ります。マッチングのメインループそのものはシンプルに保たれる可能性がありますが、リスク管理、清算、保険基金、ADL、おそらくはバックストップ・リキデーターネットワークなど、その周囲のステートマシンは、オーダーブック自体よりも複雑なシステムを構築しています。

「オーダーブックが現物と同じように見える」視覚錯覚の背後には、実際には2つの独立したエントリーポイントパスと4つの異なるエグジットパスがあります。これがperpマッチングの「難しさ」の実際の形状です。（一部の取引プラットフォームではbブックも作成されたとのことです）

五、オプションマッチング：グリッドとメーカー主導

オプションは、これらの4つの資産クラスの中で唯一、「アセット自体に数量の爆発がある」カテゴリです。BTC現物市場には1つのオーダーブックしかありません。BTC永続先物にも1つしかありません。しかし、BTCオプション（Deribitを例に取る）は、いつでも数百の活動契約が存在し、行使価格×満期×コール/プットの3つの次元で組み合わされます。各契約には独自のオーダーブックが必要です。

これには根本的な問題が伴います：流動性が乏しい。深くITMまたはOTMの契約は、1日に何回も取引される場合があり、オーダーブックには頻繁に空白や市メーカーの2つの注文しかないことがよくあります。この希薄性により、純粋なLOBモデルはほぼ使用できません——通常の購入者が指値注文を出すと、数日待たなければ取引が成立しない場合があります。

業界の解決策は、3つのモデルを組み合わせたものです：

LOBは、流動性が最も深い契約に使用されます、主にATMオプションと近月契約です。この部分は現物取引ロジックと本質的には同じです。

RFQ（レクエストフォーコート）は、流動性が乏しい契約に使用されます。 トレーダーが見積もりリクエストを送信し、複数の市メーカーが応答し、トレーダーが最適なものを選択します。このプロセスはLOBの外で実行され、マッチングは「リクエスト対複数の見積もり回答」であり、基本的に逆オークションです。

Block trade（ブロック取引）は大口取引に使用されます。2つの対向する当事者がオーバーカウンターで価格を合意し、取引を取引プラットフォームに報告して清算し、注文ブックはマッチングに参加せず、登録のみに参加します。

マルチレッグ同期マッチングはオプションのマッチングの別の中心要件です。一般的なストラテジー、たとえばアイアンコンドルなど、4つの異なるオプション契約を同時に売買する必要があります。もし4本の脚がそれぞれ異なるオーダーブックで個別にマッチングされると、その結果は2本の脚が取引され、残りの2本が取引されず、取引者のリスク露出はまったく望んでいないものになります。

そのため、オプションのマッチングエンジンはコンボブックまたはマルチレッグアトミック実行をサポートする必要があります。4本の脚はすべて取引されるか、すべて取引されないか、全体として処理されます。

Deribitのアプローチは現在の業界のベンチマークと言えるでしょう：独自のコンボオーダーブックがあり、コンボオーダーは単独でオーダーでき、また単脚オーダーブックと暗黙のマッチングを行うことができます。システムは自動的に単脚の流動性からコンボ価格を合成し、その逆も行います。これは非常に精巧な設計ですが、マッチングの主要ルートでは「仮想オーダーブック」の状態同期を維持する必要があります。

具体例を挙げて、なぜマルチレッグ同期マッチングがオプションでは選択肢ではないかを説明します。ETHの現在価格は3,000で、トレーダーは将来7日間の価格が[2,900, 3,100]の範囲で推移すると予測し、アイアンコンドルを構成します：3,100コールを売り、3,200コールを買い、2,900プットを売り、2,800プットを買います。4本の脚のネット収入は戦略の最大利益であり、最大損失は保護脚があるため厳密に制限されます。これは戦略の基本条件です。

各オーダーを4つのオーダーブックに個別に提出すると、最も一般的な失敗シナリオは次のとおりです：最初の2本の脚（コールスプレッド部分）が取引され、ETHが瞬時に2,950に跳ね上がり、残りの2本の脚（プットスプレッド部分）の相手方の価格がすでに無効になっており、メーカーがキャンセルするか大幅に調整します。C、Dは取引されません。その結果、トレーダーは裸のコールスプレッドを持っています。方向性の露出が完全に逆転し、元々の「振幅収益」の戦略が「低下損失」に変わり、最大損失ももはや制限されません。

コンボブックは4本の脚を1つのまとまりとして処理します：すべてが成立するか、すべてが成立しないか。暗黙のマッチングにより、単脚オーダーブックの流動性がリアルタイムでコンボ価格に合成され、その逆も行われます。両方の流動性が互いに補完されます。

メーカーの価格設定アルゴリズムは主にIV 暗黙のボラティリティ を使用しますが、価格ではありません（これはオプション特有のものです）。メーカーは「50000ストライクコール$1500」を提示しません。代わりに、「65ボラティリティで買い、67ボラティリティで売り」と提示します。システムは各価格提供が有効になるたびに、現在の基礎価格を使用してBSM（またはより複雑なモデル）に基づいて実際の価格を計算します。

これはメーカーの価格が基礎の動きに追随することを意味し、基礎価格の変動時に注文ブックが自動的に調整されるため、「注文を提示」がオプション内では離散的なイベントではなく連続関数になるということです。

ギリシャ文字に変換されたポートフォリオ証拠金 により、リスク管理も異なるものになります。Perpでは、各ポジションの証拠金が独立して計算されます。一方、オプションでは、メーカーは数百の契約を同時に保有している可能性があり、個々の契約の証拠金を計算すると資本効率が低すぎて運用できなくなります。

したがって、オプション取引プラットフォームでは通常、delta、gamma、vega、thetaに基づいたポートフォリオ証拠金を採用し、すべてのポートフォリオをネットヘッジポジションと見なして、ネットのギリシャ値に基づいて証拠金を計算します。これはまたマッチングに影響を与えます。「証拠金コスト」は取引が既存のポジションをヘッジしたかどうかに応じて決まります。

6. Polymarket マッチング：オンチェーンとオフチェーンのハイブリッドアーキテクチャ

以前に探究する前に、1つの疑問に答えましょう：なぜPolymarketだけを挙げ、なぜAMMについて話さないのか？その代わりにそれを一般化した「DEXマッチング」カテゴリに組み込まないのか？

それはPolymarketの特異性が「オンチェーン」のラベルにあるわけではないからです。Polymarketの真にユニークな点は、3つのメカニズムの重ね合わせです：[0, 1] 価格クリッピング + CTF コンプリメンタリー・メインテインメント + UMA リゾルト判定（mark priceに類似）。これら3つが共に、現物、perp、オプション、他のDEXと異なる状態機構の形態を形作っています。価格空間が離散的かつ有界であり、流動性がどこからもたらされていない、そしてライフサイクルに終点がある。

以下では、これら3つのメカニズムとそれらの背後にある信頼仮説に基づいて展開します。

Polymarket は、Polygon 上に構築された最初の予測市場であり、すべてのポジションは ERC-1155 トークンであり、Gnosis の Conditional Token Framework（CTF）によって発行されています。市場は、たとえば大統領選挙の2択予測など、2種類のトークンを発行します：YES トークンと NO トークン，市場の終了時に 1種類のトークンは $1 の価値があり、もう1種類は $0 の価値があります。

相補的鋳造メカニズム は CTF の中核です。誰でも 1 USDC を預け入れると、1 YES + 1 NO を受け取ります。誰もが 1 YES + 1 NO を燃やすことができ、1 USDC を償還できます。このメカニズムの存在により、メーカーは市場に流動性を提供することができ、メーカーはトークンを所持していなくても売却することができます。これにより、メーカーはまずトークンを保持する必要はなく、その後即座に鋳造して売却することができます。マッチングエンジンの観点からは、このことは、メーカーに無限の初期在庫があるように見えますが、コスト制約は保証金にあります。これは、Polymarket が従来の CLOB との重要な違いです。

オフチェーンマッチング + オンチェーン決済 が Polymarket の全体的なアーキテクチャです。具体的なフロー：ユーザーは EIP-712 で署名されたリミット注文を送信し、Polymarket の中央集権的マッチングサーバーに送信します。サーバーは伝統的なLOBを維持しています。2つの注文がマッチすると、サーバーはこれら2つの署名を1つのオンチェーン取引にパッケージ化し、取引を完了するために交換スマートコントラクトを呼び出します。つまり、マッチングそのものはオフチェーン（ミリ秒単位）で行われますが、決済はオンチェーン（秒単位）で行われます。

このアーキテクチャには、信頼レベルに特有の1つの特徴があります：マッチングサーバーは取引を偽造できません、なぜならユーザーの秘密鍵を持っていないからです。ただし、マッチングサーバーは取引を審査することができます。つまり、特定の注文を拒否できます。

Gas エコノミクスは、ユーザーの行動ではなく決済経路を形成します。一般的な誤解は、Polymarket のガスコストをユーザーに帰属すると考えることですが、実際にはガス代はリレーサー（Polymarket のオペレーター）が負担しています。ユーザーは EIP-712 で注文に署名し、リレーサーはマッチング後に取引をバッチ処理してオンチェーンに提出し、ガス代はPolymarket が負担し、その後手数料収入で回収されます。したがって、ユーザーにとっては、オーダーのプレースメントとキャンセルは無料です。キャンセルはオンチェーンには一切登録されず、単にマッチングサーバーに注文が削除されたことを通知するだけであり、ロジック的には CEX のキャンセルと本質的に同じです。

しかし、これは gas が制約力を持たないことを意味するものではありません。代わりに、制約が relayer 側に移されました。各取引のチェーン上決済コストは Polymarket が負担し、relayer の gas 予算 + Polygon のスループット上限がシステムの最大取引頻度を共同で決定します。流動性提供者が極端な混雑時に感じるのは「オーダーが高価」ではなく、決済の遅延とスループットのボトルネックです。これは、CEX とはまったく異なる混雑の伝播経路です。

このアーキテクチャがマッチエンジンに課す実際の形状は、次のようなものです：relayer が複数の取引を一括決済できるようにする必要があります（gas の分散），同時に各取引が決済契約で独立して検証可能である必要があります（relayer による改ざんや不正横領を防ぐため）。

したがって、Polymarket の取引所契約は、「マルチシグオーダー + バッチ提出の単一取引」構造を受け入れるように設計されています。Gas によって Polymarket が「低頻度市場」になったわけではありませんが、そのマッチング-決済の結合方法は、CEX および完全なオンチェーン DEX とは異なります。マッチング層は完全に CEX の軽量化を継承しています（ミリ秒でのキャンセル、ゼロ gas オーダー）、一方で決済層はオンチェーン DEX の検証可能性制約を継承しています。

オラクル結果の最終性は予測市場のマッチングがもっとも特異な特徴です。他の3つの市場はすべて「持続的」です。価格は常に変動し、市場は常に開いています。しかし、予測市場には明確な「終了時刻」があります：イベントが発生し、結果がオラクル（Polymarket は UMA の楽観的オラクルを使用）によって解決され、YES または NO が判定されます（討論がある場合もありますが、本文では触れません）。すべての保有ポジションは 1:0 または 0:1 で決済されます。

これは、マッチングエンジンが「市場の停止」ステートマシンを処理することを意味します：解決ウィンドウ内では新しいオーダーを禁止し、紛争ウィンドウ内では異議を唱えることを許可し、最終的な決済後にすべての取引活動を停止します。このステートマシンはCEXスポット市場には対応するものではありません。

価格は [0, 1] の範囲に制限されています。これは利点のように見えます（無限に清算されることはありません）、しかし、これはオーダーブックの価格段階のスペースが限られていることを意味します。通常、1セントごとに価格が区切られ、最大100の段階があります。これはマッチングデータ構造にとって強い制約ですが、価格発見の精度に上限があることも意味します。

具体的シナリオを挙げて、mint/redeem がどのようにメイクテイキング行動を形成するかを説明します。ある市場で YES が $0.65、NO が $0.35 を提示しています（YES + NO は必ず $1 になるため、そうでない場合はアービトラージャーが即座に mint または redeem を行い平準化します）。メイクテイクショップ M はこの市場に売りテイキングを提供したいが、手元に YES がありません。M は100 USDC を CTF コントラクトに預け入れ、100 YES + 100 NO を即座に受け取り、100 YES を $0.66 で売り、100 NO を $0.36 で売りました。

両方の取引が成立した後、M は純ポジションを持たず、両方向の価格差の利益 0.02 × 100 = 2 USDC を得ました。これが Polymarket のメイクテイキングの標準的なプレイです：mint/redeem を使用して、「資本の占有」を「両建て価格のスプレッド」に変えます。

特に分析する価値があるのは、YES + NO = 1 というこの不変条件をマッチングエンジンが積極的に維持する必要がなく、市場構造がアービトラージャーによって自動的に保証されることです。このような「市場構造に組み込まれた不変条件」は、従来のLOBBには存在せず、メイクテイクショップは「手元に在庫がない状態でも売却できる」ことは不可能です。したがって、Polymarket マッチングエンジンの設計では、CEX が必要とする在庫の制約チェックの一部が削除され、その代わりに mint/redeem パスが決済契約に統合される必要があります。

Polymarket マッチングの特異性をまとめると：信頼の前提条件は、「オンチェーンマッチング + オンチェーン決済」のハイブリッドであり、トークンモデルは CTF の相互補完的な発行であり、価格空間は [0,1] の有界離散であり、時間次元は終局的であり、ガスはリレーヤーが負担し手数料回収によって補われます。これらの制約を合わせると、従来の三つとはまったく異なる形態のマッチングエンジンが生まれます。

7. 異なる点はどこから来るのか：5次元フレームワーク

これらの四つの形態を広げて考えると、異なる資産でのマッチングエンジンが分化する理由を説明するために、5つの次元を抽出できます。

この5次元フレームワークを「マッチング-リスク管理の結合度」と「流動性密度」の2つの次元に配置すると、四つの形態の位置が一目瞭然になります。現物取引は低結合度で高密度の快適な領域にあり、永続契約は高結合度で高密度（最も複雑なエンジニアリングリアリティ）、オプション取引は高結合度で低密度（まれな状況を補うために RFQ + コンボが必要）、Polymarket はその中間に位置しています。結合度はオンチェーン決済によって引き上げられ、密度は相互補完的な発行によって引き上げられています。

各次元はすべてマッチエンジンに圧力をかけています：

資産形態 は、オーダーブックの数と希薄性を決定します。単一ディメンション均質（Spot、Perp）には1つのブックだけが必要ですが、多次元希薄（Option）には数百のブックが必要であり、希薄性を解決する必要があります。離散補完（Polymarket）は、「鋳造/償還」をマッチングパスに統合する必要があります。

清算時系列 は、ステートマシンの複雑さを決定します。リアルタイム同期（Spot）では、マッチングが決済に等しくなります。継続的記帳（Perp、Option）では、ポジション状態、証拠金状態、PnL状態を維持し、各マッチング後に更新する必要があります。最終的な解決（Polymarket）では、ステートマシンが「開始」から「凍結」から「解決」に移行する必要があります。

リスクトポロジー は、リスク結合度を決定します。線形ゼロポジション（Spot）では、ほとんどリスク管理が必要ありません。線形継続的露出（Perp）では、プリトレードマージンチェックと清算エンジンが必要です。凸性（Option）では、ギリシャ文字に基づいた組合せ証拠金が必要です。2値有界（Prediction）では、ほとんどリスク管理が必要ありません（最大損失は支払われた金額だけです）。

流動性密度 は、流動性ソース戦略を決定します。高密度市場では、LOBだけで構成できます。希薄市場では、RFQ、AMM、リキッドィティプロバイダーインセンティブなどの補助メカニズムを導入する必要があります。

信頼境界 は、どのコンポーネントを検証可能であるとするかを決定します。CEXでは、すべてのコンポーネントが取引プラットフォーム内にあります。完全なDEXでは、すべてのコンポーネントがチェーン上にあります。ハイブリッドアーキテクチャでは、何をチェーン上に配置する必要があるか（決済）、何をオフチェーンに配置できるか（マッチング）、どのような攻撃モデルがあるか（お金を盗むことはできませんが監査は可能です）を明確にする必要があります。

8. 余分なステップはない：マッチングはメカニズムの鏡像です

最初の質問に戻ります——なぜ「マッチングエンジン」は異なる市場でほぼ異なる4つのマシンに分かれるのでしょうか？

それは、マッチングが決して独立したエンジニアリングモジュールではなく、資産自体の性質、清算モデル、リスク構造、流動性形態、および信頼仮説という5つの変数の総合効果の産物だからです。マッチングエンジンはこれらの変数の姿です。マッチングがどのように見えるかを見れば、逆にその市場の金融構造がどのようなものかを推測できます。

現物マッチングのシンプルさは、「同質アセット + 一回の決済 + ゼロのポジション延長」というクリーンな構造に対応しています；

永続契約のマッチングの複雑さは、「シンセティックアセット + 持続的ポジション + リスク管理 - マッチング深度の結びつき」というエンジニアリングの現実に対応しています；

オプション取引のマッチングのハイブリッド形態は、「ディメンション爆発 + 流動性のまばらさ + メーカー主導」の市場構造に対応しています；

Polymarketのマッチングはオンチェーンとオフチェーンの分裂に対応しており、「無検閲」と「防盗」の2つのセキュリティ目標のエンジニアリング的妥協です。

決済が取引プラットフォームの良心であるとすれば、マッチングメカニズムは取引プラットフォームの底線です。