予測市場の内部構造：画面、取引、コントラクト、データ

予測市場のウェブサイトは、複数の役割を持つシステムへの入口です。画面は市場を提示し、取引システムは注文をマッチングし、コントラクトは資産の移動を決済し、データサービスはその結果を読める形にします。オラクルは、設定された結果確定手続きに従って市場の最終的な答えを提供します。

それぞれの処理は異なる場所で行われます。ボタンを押すこと、注文が受理されること、取引が決済されることは別の段階です。この境界を理解すると、市場が見えていても取引できない理由や、完了したトランザクションがポートフォリオに反映されるまで時間がかかる理由が分かります。

「PolymarketとKuestの仕組み」の第二回です。価格と支払額にまだなじみがなければ、予測市場の価格は何を意味するのかからお読みください。

四つの層と四つの責任

PolymarketのAPI概要も、この分担を反映しています。Gammaは市場の発見、CLOBは注文とリアルタイムの市場状態、Data APIはアカウントと市場の活動を扱います。WebSocketは更新を配信しますが、基礎となる決済ルールを置き換えません。

ページのURLはポジションの識別子ではない

イベント は関連する市場を表示用にまとめたものです。二択の市場は、結果を判定できる具体的な問いを立て、YESとNOを別々の結果として扱います。一つのイベントに複数の市場が含まれるため、ページのURLだけでは注文の対象を指定できません。Polymarketの市場とイベントのモデルを参照してください。

Conditional Tokens Framework、つまりCTFでは、質問IDが結果確定に使う入力を識別します。条件IDはオラクルのアドレス、質問ID、結果スロット数から導出されます。結果ポジションのIDは、担保とコレクションの経路にも依存します。これらのIDを互いに置き換えて使うことはできません。

Polymarketのオンチェーンデータガイドは、こうしたCTFのID導出とProtocol V2のIDを区別しています。別のサイトでタイトルが一致していても、同じ資産である証拠にはなりません。

一つの注文をシステム全体で追う

最初に画面が市場を見つけ、結果のIDと取引設定を取得します。クライアントが注文を組み立て、適切な署名者がその条件を承認します。注文への署名と、ブロックチェーンへのトランザクション送信は別の操作です。

署名済みの指示は、中央指値注文板であるCLOBに届きます。サービスは受理条件を確認し、条件の合う注文を探します。受理された注文でも、すぐに執行できなければ未約定のまま残ることがあります。マッチングは取引ルールに基づく売買の合意であり、まだ資産が引き渡された証拠ではありません。

次が決済です。実行サービスが、Polygon上の対象コントラクトにトランザクションを送ります。決済経路は承認された取引を検証し、実行に成功した場合に資産を更新します。APIが先にマッチングを報告していても、失敗したトランザクションが成功した購入になるわけではありません。

Polymarketは注文のライフサイクルを説明し、それとは別に、連携するアプリにはポジションを確認する前に約定の決済を待つよう案内しています。トランザクションが取り込まれ、必要な確認状態に達したかが重要であり、注文IDだけでは不十分です。

最後にインデクサーが記録済みの変更を処理し、APIが更新された表示用データを提供します。ここで画面にポジションと活動履歴を示せます。各段階には個別の状態表示が必要で、曖昧な「成功」の一言にまとめるべきではありません。

コントラクトは単体ではなく、役割ごとの集合

CTFを使うシステムは、複数のコントラクト群で責任を分担します。以下の名称は役割を表し、実際のコントラクトと権限は経路によって異なります。

取引の決済と市場の結果確定は、別の問いに答えます。 決済が判断するのは、その取引で資産を移動できるかです。結果確定が判断するのは、市場ルールがどの支払を意味するかです。現在のPolymarketの結果確定ドキュメントは、UMAを使う市場とChainlink TWAPを使う上下動市場を区別しています。マッチングエンジンが取引価格を選ぶことで、その答えを決めるわけではありません。

バージョンも重要です。Polymarketは現在、CTFとProtocol V2のポジションシステムを説明しています。Protocol V2はPositionManagerを、CTFはConditional Tokensを使います。コントラクト一覧にも異なる決済コンポーネントが記載されています。「Exchange V2」と「Protocol V2」は同じ意味ではありません。市場のバージョン、残高を記録する仕組み、経路をセットで確認してください。

データは台帳を使いやすくするが、遅れることがある

インデクサーはコントラクトのイベントを検索可能な記録に変えます。APIはその記録を、市場メタデータ、価格、計算結果と組み合わせることがあります。アプリには便利なデータですが、その更新時点はトランザクションのレシートやリアルタイムの注文配信と一致するとは限りません。

Polymarketのオンチェーンデータガイドは、転送と取引約定のイベントを説明しています。その記録に、オフチェーンで板に残っている注文がすべて含まれるわけではありません。同様に、インデクサーを「注文板サブグラフ」と呼んでも、それがリアルタイムの板になるわけではありません。現在の気配値と過去の約定は別の記録です。

ポートフォリオが古く見えるなら、更新時点をトランザクションと該当台帳に照らして確認します。気配値が消えたなら、現在の注文板を調べます。これは別の調査です。カタログの再読み込みだけでは、注文が未約定なのか、資金が不足しているのかの証明にはなりません。

リレイヤーは送信を助けるが、依存関係はなくならない

リレイヤーは、ウォレットのデプロイや承認など、対応する操作を送信できます。Polymarketのウォレットドキュメントは、これらの呼び出しについて、アカウントがネイティブのガストークンを持たずに操作できるスポンサー方式を説明しています。ガスは消費されており、その費用が別の場所で支払われているのです。

ウォレット用リレイヤーと、取引のマッチング・決済サービスは役割が異なります。可用性、対応する呼び出し、費用負担の方針を確認する必要があります。すべての取引がウォレット用リレイヤーを通るとは限らず、スポンサー方式だからといって、資産の管理、アップグレード権限、オラクルの正しさが証明されるわけでもありません。

Kuestの特徴：独自の画面から共通の取引経路を使える

Kuestの公開アーキテクチャガイドは、運営者のブランドとカタログを、共通の取引インフラと区別しています。運営者は読者やコミュニティ向けに市場を選び、互換性のある共通の実行サービスを利用できます。

同じKuestのサービスと資産を使う独自ブランドのサイトは、異なるカタログを表示しながら共通の売買注文にアクセスできます。運営者は取引の実行基盤を再利用しつつ、特定の読者やコミュニティ向けの体験を構成できます。

運営者は市場をトレーダーに提示し、マーケットメイカーは注文を通じて売買の意向を提供します。これらの参加者の役割は、注文をマッチングし、決済するサービスとは別です。市場を作るだけでは、取引相手や約定可能な数量は用意されません。

Kuestの共通サービスは、その注文板をPolymarketの板と統合しません。また、ミラーされた問いだからといって、プラットフォーム間で残高を移動できるわけではありません。

上記のコントラクト群は責任の説明であり、デプロイ対象の完全な一覧ではありません。市場を運営する前に、実際のネットワーク、コントラクトアドレス、公開コード、権限、対応するポジションシステムを確認してください。元のプロジェクトの監査が、別のデプロイや独自の変更まで自動的に対象とするわけではありません。

運営者にとって有用な確認は具体的です。このサイトが表示する市場資産は何か、どのサービスが注文を受け付けるか、どのコントラクトが決済するか、表示中の記録はどれくらい新しいか。独自ブランドを導入するなら、これらの答えを見つけやすくしましょう。

自分の読者やコミュニティに、この体験を提供したいですか。Kuestのガイド付き設定で独自の予測市場を作成できます。