著者：ダニー

バイナンスの現物市場と無期限市場を開くと、オーダーブックはほぼ同じであることがわかります。しかし、「売り」の瞬間には、舞台裏で根本的に異なる2つのステートマシンが動作しています。PERPが2つの価格セットを維持するのはなぜでしょうか？アイアンコンドルが4つのレッグすべてで同時に取引を実行する必要があるのはなぜでしょうか？ポリマーケットの手数料がp=0.5で最も高くなるのはなぜでしょうか？ユニスワップのLPが常に保有者のパフォーマンスを下回るのはなぜでしょうか？これらの質問は、一見メカニズムに関するものですが、本質的には同じことを尋ねています。マッチングエンジンは決して独立したエンジニアリングモジュールではなく、それが対象とする資産によって形作られるのです。

現物取引、永久契約、オプション、ポリマーケット、AMM（自動マーケットメーカー）という5つの形態の違いは、類似点よりもはるかに大きい。本稿では、これらの形態を分析し、「マッチメイキング」が、一見無関係に見える様々な技術体系へと分化していった要因を探る。

I. マッチングは標準コンポーネントではありません

スポット取引のマッチング実装だけを見てきた場合、「マッチングエンジン」は成熟していて、収束的で、ほとんどローテクなものだと考えるかもしれません。つまり、ソートされた注文帳、価格と時間の優先順位に基づくマッチングループ、そして一度限りの決済パスがあれば、それで終わり、というわけです。

それなら、あなたは完全に間違っています。

CoinbaseのBTC/USDTからBinanceのBTCUSDT無期限契約、DeribitのBTC-26DEC25-50000-C、そしてPolymarketの特定イベント市場へと焦点を移していくと、これら4つの市場の背後にあるマッチングエンジンは、構造的にはほぼ4つの異なる機械であることがわかります。アルゴリズム上の類似点（買い手、売り手、価格、数量など）はいくつかありますが、ステートマシン、リスク制御の結合、トランザクション境界、信頼の仮定といった側面を掘り下げていくと、その違いが非常に大きくなり、「マッチングエンジン」という用語自体が抽象的すぎるように思えてきます。

本稿の目的は、これら4つの典型的な形態を分解し、同じ基本概念が異なる目標の下で異なる工学的実体へと分化する原因となる力について考察することである。

II. スポットマッチング：最も基本的な形式

スポットマッチングは標準的なモデルであり、ほとんどすべての教科書やオープンソースプロジェクト（LMAX Disruptor、CME Globexの簡易版、および様々なオープンソースのマッチングエンジン）はここから始まっている。

コアとなるデータ構造は通常、2つの価格ツリー（買い側と売り側）で構成され、各価格ノードはFIFOキューに接続されています。マッチングループは非常に単純です。テイカーが到着すると、相手の最良価格レベルからスキャンを開始し、テイカーの数量がなくなるか、価格が指値価格を超えるまで、メイカーキューを時系列順に消費します。

主要機能の重要なポイントをいくつか特筆すべき点として挙げておきたい。

まず、資産は同質で分離可能です。買い手は決済資産（USDT）を保有し、売り手は基軸資産（BTC）を保有します。マッチングは基本的に資産の交換です。台帳上の操作は、トランザクションに紐づけられた残高の加算と減算のペアであり、決済とマッチングは同じトランザクション内で完了します。マッチングエンジンは外部依存関係をほとんど必要としません。マッチングは決済であり、下流のリンクは存在しません。

第二に、リスクは瞬時に排除されます。現物取引が完了した瞬間にすべてのポジションは消滅し、マッチングレベルでは「保有」という概念は存在しません。「ポジション」というものが存在しないため、エンジンは次の秒の価格変動によって清算されるかどうかを心配する必要がありません。

第三に、注文の種類は比較的類似している。指値注文、成行注文、IOC注文、FOK注文、ポストオンリー注文、ストップ注文――これらはすべて注文ライフサイクル管理のバリエーションである。

具体的なシナリオを以下に示します。BTC/USDT 市場で、50,001 × 1.5 BTC の売り注文 (メーカー A が 09:30:00.100 に注文) と 50,002 × 3.0 BTC の売り注文 (メーカー B が 09:30:00.200 に 1.0 BTC の注文、メーカー C が 09:30:00.300 に 2.0 BTC の注文) があります。4.0 BTC の成行買い注文が届きます。マッチングサイクルは次のとおりです。まず、メーカー A の 50,001 BTC の 1.5 BTC がすべて取得されます。次に、次の価格レベルでは、FIFO順序が適用され、BがCより優先されます。まず、メーカーBから50,002 BTCで1.0 BTCすべてが取得され、次にメーカーCから1.5 BTCの一部が取得されます（0.5 BTCは注文板に残ります）。同じトランザクションで、テイカーアカウントは200,006.5 USDTを差し引き、4.0 BTCを追加します。3つのメーカーアカウントは、これに応じて逆方向に更新されます。この一連の操作は、単一のデータベーストランザクション内で完了します。マッチングは決済に相当します。BのトランザクションがCのトランザクションより優先されるのは、価格（同じレベル）によるものではなく、Bが先にリストされたためであることに注意する価値があります。これは、価格と時間の優先順位の実際的な現れです。

スポット取引のマッチングエンジニアリングにおける課題は、ロジックではなくパフォーマンスにある。すなわち、数百万TPS（1秒あたりのトランザクション数）下でマイクロ秒レベルのレイテンシを維持する方法、ホットパスとコールドパスのキャッシュ局所性を処理する方法、そして決定論的なリプレイを実現する方法である。しかし、これらは最適化の問題であり、メカニズムの問題ではない。

III. 永久契約マッチング：リスクコントロールエンジンの介入

バイナンスの無期限契約注文板のスクリーンショットを現物注文板のスクリーンショットと並べて表示しても、肉眼では違いが分からないかもしれません。しかし、その内部構造を見ると、全く異なる様相が見えてきます。

重要な変更点は、マッチングエンジンが決済の終着点ではなく、単なる事象の発生源（いわゆるドミノ効果）であるという点です。

PERPにおける各マッチングは、価格更新、ポジション更新、証拠金再計算、未実現損益の更新、および潜在的な清算トリガーといった複雑な下流チェーンをトリガーします。PERPではマッチングエンジンとリスクエンジンが密接に連携しており、この連携方法がシステム全体の特性を決定づけています。

デュアルプライスシステムは、PERP初の独自の構造です。マッチング自体は「最終取引価格」に基づいて行われますが、維持証拠金、清算トリガー、およびUPnLの計算には、複数のスポット市場指数と資金調達調整から合成される「マーク価格」が使用されます。これは操作防止設計です。マッチング価格とマーク価格が同じ場合、攻撃者は少額の資金で注文板を極端な価格に操作し、すべての逆ポジションの清算を即座に引き起こす可能性があります。デュアルプライスシステムは、この攻撃対象領域を排除します。

具体的なシナリオを用いて、二重価格の役割を説明しましょう。トレーダーは、1 BTCの50倍にあたる合計60,000 BTCを、初期証拠金1,200 USDT、維持証拠金300 USDTで取引を開始します。ある時点で、大量の成行注文により注文板が瞬時に58,500の最終価格まで下落し、最終価格に基づく未実現損失は1,500 USDTとなり、マージンコールが発生します。しかし、同時にマーク価格（現物指数とファンディング調整で加重平均）は59,400となり、マーク価格に基づく未実現損失は600 USDTとなります。口座残高600は維持証拠金300を上回っているため、清算は発生しません。数秒後、最終価格は59,400に戻り、トレーダーは急騰によって全滅することはありません。注文板と清算価格が同じ場合、攻撃者は注文板が弱い時に少額の資金を使って価格を極端な水準まで押し上げ、反対ポジションの清算を連鎖的に引き起こし、その後、より低い価格で買い戻すという事態を招きかねません。これはBitMEXの初期の頃によく見られた現象です。デュアルトラックシステムは「精度を高めるため」ではなく、「攻撃を回避するため」に導入されたものです。

取引前のリスク管理も重要なポイントです。現物取引では、注文は到着後すぐにマッチングされますが、PERPでは、注文はまず証拠金チェックを受ける必要があります。つまり、利用可能な証拠金で、この取引によって生じるポジション変動をカバーできるかどうかをチェックするのです。クロスマージン取引システムの場合は、このチェックで口座内のすべてのポジションの相互ヘッジも考慮されます。このチェックはマッチングサイクル内で同期的に完了する必要があります。そうしないと、「取引後に証拠金不足が発覚する」といった矛盾が生じます。

PERPエンジンの最も興味深い部分は、強制清算のための特別なマッチングチャネルです。口座の証拠金率が維持ラインを下回ると、強制清算エンジンが作動し、口座の破産価格（または特定の保護価格）でIOC注文を注文板に送信してポジションを決済しようとします。注文板が少なすぎてこの強制清算注文を処理できない場合はどうなるでしょうか？いくつかのエンジニアリングオプションがあります。1つはセーフティネットとして保険基金に接続する方法、もう1つはADL（ポジションの自動削減）をトリガーする方法です。ADLでは、システムが利益を上げている取引相手のポジションを強制的に削減します。

ADLは基本的に「マッチングプロセスの最終段階」です。注文帳と保険基金の両方が破綻した場合、システムは注文帳をスキップし、2つの口座間で直接強制決済を行います。これは「マッチング」の概念を「任意マッチング」から「強制マッチング」へと拡張する設計であり、従来の意味でのマッチングには当てはまりませんが、極端な市場状況下ではシステムが破綻してしまうため、存在は不可欠です。

自己取引防止（STP）の複雑さもPERP特有のものです。現物取引では、STPは主に注文の強制決済を防ぎますが、PERPでは、同じアカウントでロングポジションとショートポジションを同時に保有できるため（ヘッジモード）、STPの意味論をさらに洗練させる必要があります。サブアカウント、ユーザーID、マスターアカウントのどれに基づいてSTPが機能するのか？取引所によって異なるアプローチが採用されています。

要約すると、PERPマッチングの難しさは、オーダーブック自体にあるのではなく、リスクエンジンと連携するオーダーブックの背後にあるステートマシン全体にある。設計者は、どのチェックがメインのマッチングパス（同期）上にあるか、どのチェックが非同期でよいか、強制清算にどの実行モデルを使用するか、保険資金をどのように配分するか、ADLトリガーキューをどのように優先順位付けするか（通常は「利益率×レバレッジ比率」でソートされ、最も収益が高く、最もレバレッジの高い投資家が最初に清算されるようにする）を明確に定義する必要がある。

IV. 永続的なマッチングへの2つのアプローチ：階層的な意思決定、構築、および実行

PERPのマッチング処理には、特に議論すべきもう一つの層があります。それは、強制清算パスがマッチング段階で通常の注文と統合されるものの、統合前後のロジックが全く異なる点です。この層を理解することは、PERPエンジンの設計やデバッグにおいて非常に重要です。そうでなければ、「マッチング」と「清算」の境界が曖昧になってしまうでしょう。

強制解体を3つの段階に分けて考えてみましょう。

第1層はトリガー判定です。マーク価格が用いられますが、これは「清算するかどうか」の判断が、注文板の瞬間的な操作に影響されないようにするためです。この層は市場の厚みとは完全に独立しており、独立したリスク管理判定です。

第 2 層は注文の構築です。清算エンジンが清算を決定すると、IOC 注文を構築して注文板に送信します。この注文は、ユーザーの通常の注文とは構造的にいくつかの点で異なります。価格はユーザーが選択するのではなく、破産価格に基づいてエンジンによって設定されます。タイプは常に IOC であり、注文板内の残りは許可されません。手数料はテイカーレートではなく清算レート (0.5～1.5%) であり、保険基金に流れます。注文発注権限はアカウントではなくシステムに属します。アカウントが清算されると、まず注文板内の保留中のすべての注文が強制的にキャンセルされます (自己取引が清算を汚染するのを防ぐため)。フォールバックが異なります。ユーザーの IOC を取得できない場合は消滅しますが、清算された IOC を取得できない場合は、保険基金 → ADL の連鎖的な影響が引き起こされます。

第3層はマッチングの実行です。注文板に登録された清算済みIOCと通常のIOCは、カウンターパーティの流動性を獲得するために、まったく同じ価格・時間優先順位ルールに従います。この層は対称的です。マッチングエンジンは、清算済み注文のマッチング優先順位を「特別扱い」しません。マッチングループには、このようなif-else文を含めるべきではありません。そうしないと、決定論的なリプレイが妨げられてしまうからです。

したがって、正確な記述は次のようになります。マッチングサイクル自体は2つのセットに分割されませんが、注文元、構築、請求、および失敗の経路が2つのセットに分割されます。主要なマッチング経路の観点から見ると、強制清算と通常の注文は同等ですが、取引全体の観点から見ると、これらは2つの並行した経路をたどり、マッチング段階でのみ合流します。

もう一つ重要な点は、マーク価格は「清算が行われるべき価格」（トリガー条件）を決定するが、最終価格（市場の厚み）は「実際に清算が行われる価格」を決定するということである。注文板が薄く市場の厚みが枯渇している場合、清算対象となった国際石油会社（IOC）が注文板に沿って買い上げられる実際の取引価格は、破産価格よりもはるかに悪くなる。この差が保険基金の「損益の源泉」となる。保険基金は基本的に、「マークによって示される理論上の清算価格」と「市場で実際に執行された取引価格」との乖離を吸収する。もし両者が常に一致していれば、保険基金は不要となるだろう。

より革新的な設計（HyperliquidのHLP、dYdXの初期のバックストップ清算ネットワークなど）では、注文板の前に「清算市場」レイヤーを追加するだけで、専門のマーケットメーカーが合意された割引価格でポジション全体を先取りし、注文板の遅いプロセスを回避できます。基本的に、これは「清算執行」を取引所のマッチングプロセスから完全に分離し、清算パスに独自のマッチングチャネルを与えます。これは、デュアルパス問題への別の解決策です。一部の取引所は、両方のパスを同じ注文板に詰め込むことを妥協とみなし、単に異なるマッチングチャネルの使用を許可しています。

PERPのマッチングの複雑さの核心に戻ると、メインのマッチングループ自体はシンプルに保たれていても、リスク管理、清算、保険基金、ADL、そして場合によってはバックストップ清算ネットワークといった周辺ステートマシンは、オーダーブック自体よりもはるかに複雑なシステムを構成している。「オーダーブックは現物市場と同じように見える」という視覚的な錯覚の裏には、2つの独立したエントリーチャネルと4つの異なる出口経路が存在する。これがPERPマッチングの「難しさ」の真の姿である。（一部の取引所ではBブックを導入しているという噂もある。）

V. オプションマッチング：グリッドベースおよびマーケットメーカー主導

オプションは、これら4種類の原資産の中で唯一、「原資産自体の数量が爆発的に増加する」カテゴリーです。BTCの現物市場にはオーダーブックが1つしかなく、BTCの無期限契約にもオーダーブックは1つしかありません。しかし、BTCオプション（例えばDeribit）では、ストライク価格、満期日、コールオプション／プットオプションの組み合わせにより、常に数百もの有効な契約が存在します。各契約には独立したオーダーブックが必要です。

これは、最初の根本的な問題、すなわち流動性の不足につながります。イン・ザ・マネーまたはアウト・オブ・ザ・マネーの契約は、1日に数回しか取引されない場合があり、オーダーブックは空であるか、マーケットメーカーからの保留注文が2件しかないことがよくあります。この流動性の不足により、純粋なLOBモデルはほとんど使い物になりません。指値注文を出した典型的な買い手は、注文が約定するまでに数日待たなければならない可能性があります。

業界の解決策は、3つのモデルを組み合わせたハイブリッド型である。

LOBは、流動性の高い契約、主にATMオプションと期近の契約に使用されます。この部分は、スポット取引のロジックと根本的に異なるものではありません。

RFQ（見積依頼）は、流動性の低い契約に使用されます。トレーダーが見積依頼を提出すると、複数のマーケットメーカーが応答し、トレーダーは最適なものを選択します。このプロセスはLOB（上場請求書）とは別に運用され、「問い合わせ注文と複数の見積応答」を照合する、いわば逆オークションのようなものです。

ブロック取引は、非常に大規模な注文に使用されます。取引相手2社は取引所外で価格に合意した後、取引を取引所に報告し、登録と決済が行われます。注文板はマッチングには関与せず、登録のみに関与します。

オプション取引のマッチングにおけるもう一つの重要な要件は、複数レッグ同時マッチングです。アイアンコンドルなどの一般的な戦略では、4つの異なるオプション契約を同時に売買する必要があります。4つのレッグがそれぞれ異なるオーダーブックで個別にマッチングされると、2つのレッグが約定しても残りの2つが約定しないという結果になり、トレーダーにとって望ましくないリスクにさらされる可能性があります。そのため、オプション取引のマッチングエンジンは、コンボブックまたは複数レッグアトミック執行をサポートする必要があります。つまり、4つのレッグすべてが約定するか、約定しないかのいずれかであり、単一の単位として扱われます。

Deribitのアプローチは、現在の業界標準とみなされています。Deribitは独立したコンボ注文板を備えており、コンボ注文は単独で発注することも、単一レッグ注文板と暗黙的にマッチングさせることもできます。システムは単一レッグの流動性からコンボ価格を自動的に合成し、その逆も同様です。これは非常に独創的な設計ですが、同時に「仮想注文板」の状態同期をメインのマッチング経路で維持する必要があることも意味します。

複数のレッグを同時にマッチングすることがなぜ選択肢にならないのかを、具体的なシナリオで説明しましょう。ETH は現在 3,000 で取引されています。トレーダーは、今後 7 日間で価格が [2,900, 3,100] の範囲内で変動すると予測し、アイアン コンドルを構築します。3,100 のコールを売り、3,200 のコールを買い、2,900 のプットを売り、2,800 のプットを買います。これら 4 つのレッグからの純利益はポートフォリオの最大利益を表し、最大損失は保護レッグによって厳密に制限されます。これが戦略が成功するための前提です。4 つの注文がマッチングのために 4 つの異なるオーダー ブックに個別に送信されると、最も一般的な失敗シナリオは、最初の 2 つの注文 (コール スプレッド) が約定し、ETH が数ミリ秒以内に 2,950 に急上昇し、後の 2 つの注文 (プット スプレッド) のカウンターパーティの見積もりが無効になり、マーケット メーカーが注文をキャンセルするか、大幅な調整を行い、C と D が約定されないことです。その結果、トレーダーはネイキッドコールスプレッドを保有することになり、方向性エクスポージャーは完全に反転し、元の「変動からの利益」戦略は「弱気な賭けによる損失」となり、最大損失はもはや制限されません。コンボブックは4つのレッグを1つのユニットにパッケージ化します。4つすべてが成功するか、どれも成功しないかのどちらかです。暗黙のマッチングにより、シングルレッグのオーダーブックの流動性がリアルタイムでコンボクォートに統合され、逆に、コンボオーダーブックの流動性がシングルレッグに戻り、2つの流動性レイヤーが互いに補完し合います。

マーケットメーカーは、価格設定アルゴリズムにおいて、価格そのものよりも主にインプライド・ボラティリティ（IV）を使用します（これはオプション特有の機能です）。マーケットメーカーは「50,000ストライクのコールオプション、1,500ドル」といった注文を出すのではなく、「65ボラティリティで買い、67ボラティリティで売る」といった注文を出します。システムは、気配値が有効になるたびに、現在の原資産価格に基づいてBSM（またはより複雑なモデル）を使用して実際の価格を計算します。つまり、マーケットメーカーの気配値は原資産価格に動的に追従し、原資産価格が変化すると注文板も自動的に調整されるため、オプションにおける「保留注文」は離散的なイベントではなく、連続的な関数となります。

グリークスに基づくポートフォリオ証拠金計算は、リスク管理にも変化をもたらします。PERPでは、各ポジションごとに証拠金計算が行われますが、オプションでは、マーケットメーカーが同時に数百もの契約を保有している場合があり、各契約ごとに個別に証拠金を計算するのは運用効率が悪すぎます。そのため、オプション取引所では通常、グリークス（デルタ、ガンマ、ベガ、シータ）に基づくポートフォリオ証拠金計算を採用し、ポートフォリオ全体を単一の純エクスポージャーとして扱い、純グリークスで証拠金を計算します。これは、マッチングにも影響を与えます。つまり、取引の「証拠金コスト」は、その取引が既存のポジションをヘッジするかどうかによって決まるのです。

VI. ポリマーケットマッチング：オンチェーンとオフチェーンを組み合わせたハイブリッドアーキテクチャ

さらに深く掘り下げる前に、まず一つの疑問点を取り上げてみましょう。なぜPolymarketは別々にリストアップされているのでしょうか？また、なぜAMMについては議論されていないのでしょうか？「DEXマッチング」という包括的なカテゴリに統合しないのはなぜでしょうか？

Polymarketの独自性は、「オンチェーン」というラベルにあるのではありません。Polymarketを真にユニークなものにしているのは、[0, 1]価格クランプ、CTF補完的ミント、UMA結果決定（マーク価格に類似）という3つのメカニズムの組み合わせです。これら3つのメカニズムが一体となって、スポット、パーペチュアル、オプション、その他のDEXとは異なるステートマシン構造、つまり、離散的で境界のある価格空間、ゼロから生成される流動性、そして明確なライフサイクルを生み出します。

以下の議論では、これら3つのメカニズムと、それらの背後にある信頼の前提に焦点を当てる。

Polymarketは、Polygon上に構築された予測市場（あるいは、おそらく世界初？）であり、すべてのポジションはGnosisの条件付きトークンフレームワーク（CTF）によって発行されるERC-1155トークンで保有されます。大統領選挙の二者択一予測などの市場では、YESトークンとNOトークンの2つのトークンが発行されます。市場終了時には、一方のトークンは1ドル、もう一方は0ドルの価値になります。

補完的な発行メカニズムは、CTFの中核を成すものです。誰でも1 USDCを預け入れることで、1 YES + 1 NOを受け取ることができます。また、誰でも1 YES + 1 NOを焼却することで、1 USDCを償還することもできます。このメカニズムにより、マーケットメーカーは「何もないところから」市場に流動性を提供できます。マーケットメーカーは販売前にトークンを保有する必要がなく、即座に発行して販売できます。マッチングエンジンの観点から見ると、これはマーケットメーカーが初期在庫を無制限に保有しているものの、コストはマージンによって制限されているのと同等です。これは、Polymarketと従来のCLOBとの重要な違いです。

Polymarketの全体的なアーキテクチャは、オフチェーンのマッチングとオンチェーンの決済を組み合わせたものです。具体的なプロセスは以下のとおりです。ユーザーはEIP-712を使用して指値注文に署名し、Polymarketの中央集中型マッチングサーバーに送信します。サーバーは従来のLOB（ロジスティックアセットブロック）を保持し、2つの注文が一致すると、サーバーは2つの署名をオンチェーントランザクションにパッケージ化し、取引所コントラクトを呼び出して決済を完了します。したがって、マッチング自体はオフチェーン（ミリ秒単位）で行われますが、決済はオンチェーン（秒単位）で行われます。

このアーキテクチャは、信頼レイヤーにおいて独自の機能を備えています。マッチングサーバーはユーザーの秘密鍵を持っていないため、トランザクションを偽造することはできません。しかし、トランザクションを検証し、特定の注文のマッチングを拒否することは可能です。

決済経路を左右するのはガス料金であり、ユーザーの行動ではありません。よくある誤解として、Polymarketのガス料金をユーザーが負担しているというものがありますが、実際にはガス料金はリレイヤー（Polymarketの運営者）が負担しています。ユーザーはEIP-712を使用して注文を発注し、リレイヤーが注文を照合してトランザクションのバッチをブロックチェーンに送信します。ガス料金はPolymarketが負担し、その後トランザクション手数料を通じて回収されます。つまり、ユーザーにとって注文の発注とキャンセルは無料です。キャンセルはブロックチェーンに記録されず、単にマッチングサーバーに注文の削除を通知するだけであり、論理的にはCEXでの注文キャンセルと何ら変わりません。

これはガスに拘束力がないという意味ではなく、単に制約がリレイヤー側に移ったという意味です。各トランザクションのオンチェーン決済コストはPolymarketが負担し、リレイヤーのガス予算とPolygonのスループット制限によってシステムの最大トランザクション頻度が決定されます。マーケットメーカーは、極端な混雑時に「高額な注文発注」を経験するのではなく、決済遅延とスループットのボトルネックを経験します。これは、CEXとは全く異なる混雑伝達経路です。

このアーキテクチャがマッチングエンジンに及ぼす真の制約は、リレイヤーが複数のトランザクションをバッチで決済（ガスを償却）できるようにすると同時に、各トランザクションが決済契約内で独立して検証可能であることを保証する（リレイヤーが資金を改ざんしたり不正流用したりすることを防ぐ）必要があることです。そのため、Polymarketの交換契約は「複数の署名済み注文 + 1つのバッチ送信」の構造を受け入れるように設計されています。ガスによってPolymarketが「低頻度市場」になるわけではありませんが、マッチングと決済の結合方法はCEXと純粋なオンチェーンDEXの両方とは異なります。マッチング層はCEXの軽量性（ミリ秒単位の注文キャンセル、ガスなしの注文発注）を完全に継承し、決済層はオンチェーンDEXの検証可能性の制約を継承します。

予測市場のマッチングにおける最も特徴的な点は、オラクル結果の確定性です。他の3種類の市場は「継続的に稼働」しており、価格は常に変動し、市場は常に開いています。しかし、予測市場には明確な「終了点」があります。イベントが発生し、オラクル（PolymarketはUMAの楽観的オラクルを使用）によって結果が解析され、YESまたはNOが決定され（議論の余地がある場合もありますが、ここでは触れません）、すべてのポジションが1:0または0:1で決済されます。つまり、マッチングエンジンは「市場凍結」状態マシンを処理する必要があります。解析ウィンドウ内では新規注文を禁止し、紛争ウィンドウ内では異議申し立てを許可し、最終決済後にはすべての取引活動を停止します。この状態マシンは、CEXの現物取引には存在しません。

価格が[0, 1]の範囲に制限されることも、もう一つの制約です。これは（無限のマージンコールを防ぐ）利点のように思えますが、注文板の価格帯が限られていることを意味します。通常は1段階あたり1セントで、最大100段階までです。これはマッチングデータ構造に対する強い制約となります（ツリー構造の代わりに固定サイズの配列を使用できます）が、同時に価格発見の精度にも上限があることを意味します。

具体的なシナリオを用いて、ミント/リディームがマーケットメイキングの行動をどのように形成するかを説明しましょう。ある市場では、YESが$0.65、NOが$0.35で取引されています（YES + NOは$1でなければなりません。そうでなければ、裁定取引者は価格を均一化するためにすぐにミントまたはリディームを行うでしょう）。マーケットメーカーMはこの市場に売り側の流動性を提供したいのですが、YESを保有していません。そこで、CTF契約に100 USDCを預け入れ、即座に100 YES + 100 NOを取得します。次に、100 YESを$0.66で、100 NOを$0.36で売却します。両方の取引が完了すると、Mのネットエクスポージャーは0となり、0.02 × 100 = 2 USDCのスプレッドを獲得します。これは、Polymarketにおけるマーケットメイキングの標準的な手法です。ミント/リディームを使用して、「資本占有」を「双方向価格スプレッド」に置き換えています。

不変マッチングエンジンであるYES + NO = 1は、積極的なメンテナンスを必要としない点を詳細に分析する価値があります。これは、裁定取引業者を通じて市場構造によって自動的に保証されます。このような「市場構造に内在する不変条件」は従来のLOBには存在せず、マーケットメーカーは「在庫なしでは販売できない」のです。したがって、Polymarketのマッチングエンジン設計は、CEXで必要とされる在庫制約チェックの一部を排除しますが、その代償として、発行/償還パスを決済契約の第一級要素として統合する必要があります。

Polymarketのマッチングメカニズムの独自性をまとめると、信頼性の前提は「オフチェーンマッチング＋オンチェーン決済」のハイブリッドであり、トークンモデルはCTFの補完的な発行メカニズム、価格空間は境界のある離散的な[0,1]、時間次元には終わりがあり、ガスはリレイヤーが負担し、トランザクション手数料を通じて回収される、という点になります。これらの制約が組み合わさることで、これまでの3つのタイプとは全く異なるマッチングエンジンが実現します。

VII．違いはどこから生じるのか：5次元フレームワーク

これら4つのモデルを検証することで、マッチングエンジンが異なるターゲット間で差別化を図る理由を説明する5つの側面を抽出できます。

5次元フレームワークを「マッチングリスク制御結合度」と「流動性密度」の2つの次元に配置することで、4つの形態の位置が明確になります。現物取引は結合度が低く密度が高い快適な領域にあり、永久取引は結合度が高く密度が高い領域（最も複雑なエンジニアリングの現実）にあり、オプション取引は結合度が高く密度が低い領域（疎らさはRFQ + コンボで補償する必要がある）にあり、ポリマーケット取引はその中間に位置し、結合度はオンチェーン決済によって増加し、密度は補完的なミントによって増加します。

それぞれの寸法が、対応するエンジンに負荷をかける。

資産の種類によって、注文板の数と疎性が決まります。一次元で均質な資産（現物、永久先物）は注文板が1つで済みますが、多次元で疎な資産（オプション）は数百の注文板が必要となり、疎性への対応が求められます。離散的な補完資産（ポリマーケット）は、マッチングパスに「マイニング／償還」機能を組み込む必要があります。

決済シーケンスによってステートマシンの複雑さが決まります。リアルタイム同期（スポット市場）では、マッチングと決済が同一になります。継続的な会計処理（PERP、オプション）では、ポジションの状態、証拠金の状態、損益の状態を維持し、マッチングごとに更新する必要があります。最終解決（ポリマーケット）では、ステートマシンが「オープン」から「凍結」を経て「解決済み」へと遷移する必要があります。

リスクトポロジーは、リスク管理の結合度を決定します。線形ゼロポジション（スポット）は、リスク管理をほとんど必要としません。線形連続エクスポージャー（パーペチュアル）は、取引前の証拠金チェックと流動性エンジンを必要とします。凸性（オプション）は、グリークスに基づくポートフォリオ証拠金を必要とします。バイナリー境界（予測）は、リスク管理をほとんど必要としません（最大損失は既に支払った金額です）。

流動性の密度によって、流動性調達戦略が決定されます。流動性の密度が高い市場では、LOB（流動性オンボード）のみに頼ることができますが、密度が低い市場では、RFQ（見積依頼）、AMM（平均マーケットメーカー）、マーケットメーカーへのインセンティブといった補完的な仕組みを導入する必要があります。

信頼の境界は、どのコンポーネントを検証可能にする必要があるかを決定します。中央集権型取引所（CEX）では、すべてのコンポーネントが取引所内部にあります。純粋な分散型取引所（DEX）では、すべてのコンポーネントがオンチェーンにあります。ハイブリッドアーキテクチャでは、オンチェーンでなければならないもの（決済）、オフチェーンで可能なもの（マッチング）、および攻撃モデル（資金を盗むことはできないが監査可能）を明確に定義する必要があります。

8. 無駄なステップはない：マッチングはメカニズムの鏡である。

最初の疑問に戻りますが、なぜ「マッチングエンジン」が、異なる市場でほぼ異なる4つの機種に分岐するのでしょうか？

マッチングは決して独立したエンジニアリングモジュールではなく、基礎となる資産の性質、決済モデル、リスク構造、流動性プロファイル、および信頼に関する前提条件という5つの変数の複合的な影響によって生じるものです。マッチングエンジンはこれらの変数の現れであり、マッチングプロセスで何が見られるかによって、市場の金融構造を推測することができます。

スポットマッチングのシンプルさは、「同質資産＋一括決済＋ゼロポジション継続」という明確な構造に対応している。

永久契約マッチングの複雑さは、「合成資産＋継続的なエクスポージャー＋リスク管理－マッチングの密接な連携」という工学的現実に対応する。

オプションマッチングのハイブリッド形式は、「次元爆発＋流動性の低さ＋マーケットメーカーの支配」という市場構造に対応する。

Polymarketのオンチェーンとオフチェーンの分離は、「検閲なし」と「盗難防止」という2つのセキュリティ目標の間の技術的な妥協点に対応するものです。

清算が取引所の良心だとすれば、マッチングメカニズムはその取引所の最終目標と言えるだろう。