予測市場のビルダーと長く話していると、議論がきれいに2つに分かれることに気づきます。スタックの前面（マッチング、UX、流動性）と、背面（解決、決済、オラクル）です。前面の問題はエンジニアリング時間と資本で解けます。背面の問題は暗号経済設計で解く必要があり、予測市場プラットフォームが実際に生きるか死ぬかはそこで決まります。
この記事は、事業上のケースをすでに理解している運営者とエンジニア向けです。まだなら市場分析から始めてください。ここでは決済レイヤーが実際にどう動くかを説明します。
この数字は約6年にわたるオプティミスティック・オラクル設計の見出し結果です。圧倒的多数の解決は投票を必要としません。システムが、不正な提案者より正直な提案者を安くするよう設計されているからです。以下では、それがどう実現され、どこで壊れ、実出来高を扱う運営者に何を意味するかを説明します。
決済問題を明確に述べる
すべての予測市場契約は、寿命の終わりに1つだけ仕事を持ちます。正しかった側に支払いを出すことです。そのためには、契約は実際に何が起きたかを知らなければなりません。問題は、スマートコントラクトに目がないことです。CNNを見ることも、CPI発表を読むことも、スポーツスコアを確認することもできません。真実を教える外部メカニズムに依存します。
その外部メカニズムがオラクルです。すべての予測市場はオラクルの上にあります。オラクルはシステム全体の信頼仮定です。「契約はOpenZeppelinに監査されている」が人々の思うほど十分でない理由もここにあります。契約が完璧でも、オラクルがゲーム可能ならプラットフォームは失敗します。
この文脈のオラクルが満たすべき性質は3つあります。
- 正確性。 報告された結果が現実と一致すること。
- ライブネス。 結果が妥当な時間内に報告されること。市場が無期限にぶら下がってはいけません。
- 検閲耐性。 単一の主体が真の結果の記録を妨げられないこと。
この3つのトレードオフ空間が、オラクル設計の全領域です。
中央集権型解決：単純、速い、脆い
最も古く単純な方法は、運営者または指定された市場公正チームが直接市場を解決することです。Kalshiはこれを行っています。取引所が事前公開されたデータソースを参照し、文書化された解決方針を適用し、結果を投稿します。
これは次の場合にうまく機能します。
- データソースが明確で利用可能（例：BLSのCPI発表）。
- 運営者に規制されたアイデンティティがある（Kalshiの場合はCFTC）。
- 解決方針が事前公開され、後から動かない。
次の場合には失敗します。
- データソースが曖昧または争われている。
- 運営者が結果に金融上の利害を持つ。
- 解決方針が遡及的に書き換えられる。
中央集権型解決は、高度に規制され範囲の狭い契約空間には適しています。しかし、予測市場出来高の多くを生むロングテール市場には構造的に不向きです。スポーツのエッジケース、地政学イベント、測定ではなく解釈が必要な事実があるからです。
オプティミスティック・オラクルのパターン
2020年にUMAが普及させたオプティミスティック・オラクルは、単一の信頼された解決者を、ゲーム理論的な主張とチャレンジのプロセスに置き換えます。構造は一度見れば直感的です。
Step 1. 提案。 誰でも保証金を出して市場に結果を提案できます。「Will the Fed cut rates in July?の契約はYESで解決すると主張する」。提案者は担保（通常は数百ドルのUSDC）を付けて提出します。
Step 2. チャレンジ期間。 タイマーが始まります。実マネー市場では通常2時間、高額市場ではより長くなります。この期間中、誰でも自分の保証金を出して提案に異議を唱えられます。
Step 3. 2つの経路。
- 異議なし。 チャレンジ期間内に誰も異議を唱えなければ、提案結果が確定します。提案者の保証金は返還され、提案作業への小さな報酬が支払われます。
- 異議あり。 誰かが保証金付きで異議を唱えると、問いはUMAトークン保有者の投票へエスカレーションします。投票がどちらが正しいかを決めます。負けた側の保証金は勝った側とプロトコルへ支払われます。勝った側は保証金を回収し報酬を得ます。
経済性は意図的に非対称です。正直な提案者は異議を期待しません。見ている全員が結果が真であることを確認でき、真の結果に異議を唱えれば保証金を失うからです。正直な異議者は、提案結果が明らかに間違っているときだけ異議を唱えます。軽率な異議にも保証金コストがかかるからです。
実務上、ほぼすべての解決はオプティミスティック経路で確定します。紛争経路は主に、オプティミスティック経路を正直に保つ可信な脅しとして存在します。
紛争はどうエスカレーションするか
面白い失敗モードは紛争そのものです。本当の不一致が投票に達すると、プロトコルは3つのサブ問題を処理しなければなりません。
- 投票の完全性。 UMAの投票はcommit-revealを使うため、投票者は互いの選択をコピーできません。投票者はハッシュ化した票をコミットし、後で公開します。これにより単純な談合を防ぎます。
- シェリングポイント解決。 投票者は他の正直な投票者の多数派と同じ票を入れることで報酬を得ます。プロトコルは、よく定義された契約には自然に焦点（「明らかな」答え）が生まれると仮定します。これは契約仕様の良さと同じだけうまく機能します。曖昧な契約は曖昧な解決を生みます。
- 最終裁定者へのエスカレーション。 非常に高額な紛争では、UMAは複数ラウンドのエスカレーションを持ちます。投票が曖昧なら、より高いクォーラムと長い投票期間で再実行できます。実務で使われるのは年に数回程度です。
紛争市場のプロトコルレベルコストは高いです。異議者と提案者の双方が資本をロックします。UMA投票者は実際の注意を使います。きれいなプラットフォームは紛争を生まない市場を書くことで紛争を避けます。契約仕様という、書類仕事に見える規律こそ、会場が持つ最重要の運用レバーです。
多くのプラットフォームが間違える理由
運営者構築で最もよく見る間違いは、解決を「手動で照合すればよい」バックオフィス問題として扱うことです。週50市場なら動きます。週5,000市場では壊れます。
繰り返し現れる失敗モードは3つです。
曖昧な契約の失敗。 市場の文言が曖昧です（例：「2026年に紛争は終わるか」。何を「終わる」とするか定義がない）。2つの結果が防御可能になります。市場は紛争へ行き、紛争は長引き、トレーダーは信頼を失い、運営者の評判は戻らない傷を負います。
データソース移動の失敗。 市場が指定したデータソースが市場期間中に改名、再構成、または有料化されます。契約は存在しないソースを指し、解決は手動で再構築されます。
利害衝突の失敗。 運営者または運営者に近い誰かが市場にポジションを持っています。解決が不透明だと、実際に運営者が何をしたかに関係なく公のスキャンダルになります。見え方だけでプラットフォームの信用は壊れます。
3つすべてに対する最もきれいな防御は、解決経路が運営者の裁量に依存しないよう契約を設計することです。オプティミスティック・オラクルのパターンはこれに構造的に適しています。運営者は解決者ではなく、データソースは市場作成時に命名され固定され、紛争メカニズムは公開されています。
| 失敗モード | 中央集権解決者 | オプティミスティック・オラクル |
|---|---|---|
| 曖昧な契約 | High exposure | Disputes; correctly identifies bad spec |
| データソース移動 | Manual reconcile | Replay through dispute |
| 運営者の利害衝突 | Existential | Structurally separated |
| 悪意ある解決のコスト | Trust collapse | Bond + vote rewrite |
| 単純市場の速度 | Faster | Same (no dispute path) |
Kuestが決済レイヤーで行うこと
Kuestのアプローチは、Polymarketの本番アーキテクチャからオプティミスティック・オラクルのパターンを継承し、複数運営者デプロイ向けに適応しています。実務上は次の通りです。
- UMAベースの紛争フロー。 解決提案はアドホックな運営者判断ではなく、UMAのオプティミスティック・オラクルの仕組みに従います。
- 市場レベルのルールとソースメタデータ。 各市場は明示的なルールと任意の解決ソースURLを持ち、イベントルールパネルで見られます。
- 管理フローでの公開前品質チェック。 イベント作成ワークフローは必須フィールドをチェックし、ローンチ前に解決ソースURL形式を検証します。
- プラットフォームデータでの紛争可視性。 市場ペイロードは紛争状態フィールド（例：解決が争われたか）を公開するため、運営者は解決健全性を監視できます。
このすべての目的は、解決を退屈にすることです。解決が最も刺激的な出来事になっているプラットフォームは、ユーザーを失いかけています。
負荷下での紛争経済性
注目すべき微妙な点があります。オプティミスティック・オラクルの紛争経済性は理論だけではありません。実際の敵対的出来高で負荷テストされており、モデルがどこで持ち、どこで圧力を受けるかをデータが示しています。
2023年以降のPolymarketで最大の紛争市場には共通の形があります。基礎イベントが現実世界で本当に争われている契約に集中しています。契約仕様が悪いのではなく、合理的な観察者が何が起きたかについて意見を分けるケースです。2つの解釈があり得る地政学イベント、カウント期限が重なる選挙イベント、試合後レビューで結果が数時間後に変わるスポーツイベントなどです。紛争メカニズムは問いを投票へ強制することでこれらを処理しますが、投票自体は世界の本当の曖昧さを反映します。プロトコルはできる限りのことをします。世界がまだ解決していない事実をプロトコルが解決することはできません。
運営者にとっての実務的な意味は、紛争経路をシステム失敗として扱うべきではないということです。これは現実世界の不可避な曖昧さを扱うために設計されたメカニズムです。紛争へ行き、その後正しく決済される市場は、システムが壊れているのではなく、意図通りに機能しているのです。
運営者側の規律は、紛争率を構造的に説明できる範囲に保つことです。会場の紛争率が0.1〜0.3%（Polymarketの長期率と同程度）なら、市場を書けている可能性が高いです。1%超なら、解決レイヤーではなく市場仕様の問題です。
紛争モデルには成熟した運営者が織り込むソフトなエッジもあります。UMA投票者が解決する間、紛争市場は数日間ぶら下がることがあります。ポジションに資本を縛られ、別用途で現金を必要とするトレーダーにとってはUX問題です。多くの運営者は、重要でない市場の最大紛争期間を制限し、予測可能性と引き換えに小さなプロトコル手数料オーバーヘッドを受け入れます。
運営者にとっての意味
Kuest上で運営する、または代替プロトコルと比較する運営者には、ここから3つの含意が直接出ます。
- 契約仕様に思っている以上の時間を使う。 市場文言の曖昧さはすべて解決エクスポージャーを作ります。私たちと働く運営者は、市場仕様をジュニアではなくシニアの役割として扱います。
- 決済モデルを継承し、自作しない。 自家製オラクルのコストは巨大で、失敗モードは壊滅的です。代替であるUMA型の解決-as-a-serviceは成熟し、監査され、実戦で検証されています。2026年にカスタムオラクルを作る理由は、オラクル設計自体が主要商品でない限りほぼありません。
- 紛争率を先行指標として見る。 会場の紛争率が約0.5%を超えるのは、契約仕様が緩くなっているシグナルです。ユーザー信頼の劣化に数週間先行します。多くの運営者はこの指標を見ていませんが、見るべきです。
決済レイヤーは、会場が本物の会場か好奇心の対象かを最も直接的に決めるスタック部分です。良いニュースは、重い作業はすでに終わっているということです。