オラクルの定義と市場の安定性：HIP-3上に信頼できる永続的市場を構築する

2026-01-28 21:12:57

永続契約のローンチ方法の進化は根本的に変化しています。かつてはプラットフォームが取引可能な資産や条件を管理していましたが、HIP-3はその権限を定義されたパラメータ内で活動する資格のあるビルダーに再配分しました。メインネット展開以来、第三者運営の市場を通じて130億ドルを超える取引量が流れ、市場創造の真の民主化を示しています。しかし、このゲートキーパーからルールベースのシステムへの移行は、重要なパラドックスを生み出します：より柔軟な市場運営には、より厳格な運用規律が必要です。この課題の中心には、見た目は単純ながらも大きな影響を持つ概念、オラクル定義があります。

分散型リスティングの背後にあるアーキテクチャ：承認から基準へ

従来の中央集権型取引所は、不透明な内部プロセスを通じて永続契約のリスティングを管理していました。商品チームが資産を評価し、ビジネス判断を下し、それを展開します。リスク管理は取引所のインフラ内にあります。HIP-3はこのモデルを逆転させます。キュレーションされたカタログを維持する代わりに、Hyperliquidはインフラを提供します—HyperCoreはマッチングと決済を大規模に処理し、HyperEVMはスマートコントラクトを実行し、ビルダーに対してその上に市場をレイヤー化することを促します。

表面上はシンプルな仕組みです：50万HYPEトークンをステークし、DEX（自己のマージンと注文板を持つ）を展開し、無料で3つの市場を立ち上げ、その後ダッチオークションを通じて追加の市場スロットを獲得します。しかし、この構造の単純さは、実行において深い複雑さを隠しています。ビルダーは今や、市場の作成だけでなく、市場運営—価格フィード、パラメータ管理、安定性の継続的監視—も所有します。かつてはプラットフォームの責任だったものが、ビルダーの責任範囲に変わるのです。

この変化は、中心的な緊張を露呈させます：分散化には標準化が必要です。システムは明確なインターフェースと制約を確立しなければなりません。さもなければ、リスクは消えず、さまざまな能力を持つ独立した運営者間に分散し、断片化します。

オラクル定義：最初の決定の重要性

ビルダーが市場作成を開始するとき、最初で最も重要な決定はオラクル定義です。これは単に価格フィードを選ぶことではなく、市場参加者が自分のポジションが利益を生むか、清算されるか、緊急メカニズムをトリガーするかを判断するための全体的な概念フレームワークを含みます。

オラクル定義が実際に指定する内容：

HIP-3のオラクル定義は、3つの要素から構成されます：oraclePx（外部ソースからの生の価格）、オプションのmarkPx（ビルダーが提供するカスタムマーク価格）、externalPerpPx（中央取引所の永続価格の加重中央値）。これらは交換可能な入力ではなく、HIP-3のリスク計算階層においてそれぞれ異なる役割を果たします。

oraclePxは資金調整料の基準となり、価格範囲のリファレンスとなります。markPxは、ビルダーのリレイヤーがオンチェーンとオフチェーンのシグナルを組み合わせて計算します。externalPerpPxはフォールバックのリファレンスを提供します。HIP-3はこれらを中央値計算によって実際のマーク価格に組み込みます：まずローカルの注文板中央値、その後ビルダー提供の外部マークと組み合わせ、最後にexternalPerpPxと比較します。この多源アプローチは、理論上、いずれかの価格源が清算を決定づけることを防ぎます。

理論上。

なぜオラクル定義が技術よりも重要なのか：

オラクル定義の技術的構成は、それを維持するビルダーの運用能力ほど重要ではありません。中央集権的リレイヤーサーバーに依存するオラクル定義を選択したビルダーは、そのサーバーの可用性、安全性、更新頻度といった制約を引き継ぎます。もしリレイヤーの秘密鍵が漏洩したり、DDoS攻撃で価格更新が妨げられたりすると、oraclePxは停滞します。mark価格が更新できなくなると、システムはローカルの注文板中央値に戻ります—流動性が最も薄く、操作リスクが最も高まる瞬間です。

2025年12月14日のtrade.xyzでの事件は、このダイナミクスを示しています。攻撃者は約398XYZ100コントラクト（約1000万ドル相当）のショートポジションを蓄積し、意図的に不均衡を作り出しました。価格は外部ソースから乖離し、注文板の深さ不足により崩壊しました。ロングポジションの保有者は連鎖的な清算に直面し、約1300万ドルのポジションが閉じられました。仕組みは技術的には機能し—清算は実行された—が、システムは損失を最も準備不足の参加者に移し、最初の歪みを防ぎませんでした。

このシナリオは、オラクル定義が市場外時間中も安定した外部価格のアンカーを想定している場合に、はるかに起こりやすくなります。

24/7資産と非24/7資産の分断：オラクル定義の重要性

HIP-3の柔軟性により、あらゆる資産をリストできることは、オラクル定義の要件にカテゴリー的な違いをもたらします。

24/7資産（永続暗号資産）：

ビットコインやイーサリアムなどの24時間取引可能な資産については、複数のCEX/DEXの価格フィードやPythのような特殊なオラクルサービスに依存できます。これらの資産は複数の取引所で継続的に取引されており、ビルダーは複数の価格源を集約し、中央値を計算し、外れ値を検出できます。一つのソースが乖離しても、他のソースが即座にアンカーとなります。

24/7資産のオラクル定義は依然として難しいです—重み付けされたソースの選択、更新頻度の管理、取引所の停止対応などが必要ですが、根底にある外部市場は一貫したシグナルを提供し続けます。

非24/7資産（株式やコモディティ）：

株式永続契約のオラクル定義は、根本的に異なる前提を必要とします。市場時間中は、Pythのようなサービスからの価格フィードが安定した外部アンカーを提供します。しかし、ニューヨーク証券取引所が閉じるとき、ビルダーは次の選択を迫られます：価格フィードを停止（取引を制限）するか、「前回の終値」に基づいて内部市場シグナルだけで価格付けを続行します。

多くのビルダーは、trade.xyzに似た内部価格付けメカニズムを採用しています—最後の外部オラクル価格と内部注文板のダイナミクスを組み合わせ、過度な乖離を防ぐために制限（通常は1/max_leverageの変動）を設けるものです。これは数学的には妥当ですが、運用上は危険です。

市場閉鎖中は、注文板の深さは縮小し、市場参加者はクォートを減らし、流動性は著しく低下します。オラクル定義が「前回終値の1/10以内の変動」（10倍レバレッジの場合）と制限を設けても、流動性がなくなると、その範囲内での価格変動が不釣り合いに大きくなることがあります。市場が月曜日の朝に再開し、外部データが再アンカーされると、ギャップが生じます。これが連鎖的な清算や、最悪の場合はADL（自動ポジション縮小）イベントを引き起こし、損失を埋めるために利益の出ている取引が強制的に閉じられることになります。

反論できるオラクル定義フレームワークの構築

安定した市場を運営しようとするビルダーは、失敗モードを予測したオラクル定義戦略を必要とします。

市場閉鎖中の補助的価格アンカー：

非24/7資産については、市場閉鎖中でも外部価格シグナルを導入することで、オラクル定義は大きく改善されます。選択肢としては：

Blue Ocean ATSやアフターマーケット取引所： これらは通常取引時間外でも継続的な価格発見を提供し、「前回終値」よりも新しいシグナルを提供します。ビルダーはこれらのデータをオラクル定義に重み付けして、操作が難しい参照点を作ることができます。
IGなどの週末CFD見積もり： これらは翌週の市場期待を予測し、スポット価格の代替にはなりませんが、「予想開場ギャップ」の方向性を示す指標として役立ちます。

これらの情報源は、市場閉鎖中でも利用可能であり、スポット市場とは構造的に異なります。オラクル定義は、それらをリファレンスやリスクシグナルとして扱い、無条件の同等物としないことが重要です。

透明性と監査性のある価格導出の設計：

現在のオラクル定義の最大の脆弱性は、リレイヤーの中央集権化です。価格フィードがビルダーのプライベートサーバーからのみ出ている場合、そのサーバーは単一障害点となり攻撃対象となります。ビルダーは、外部の第三者が価格の真正性を監査できる仕組みを構築すべきです。

具体的には：

価格ソースの公開
それらを組み合わせるアルゴリズムの詳細
各入力のサンプリングタイムスタンプ
最終的なマーク価格の計算過程と結果を含む暗号証明（proof）を生成し、
これをproofHashとしてリレイヤーが署名し、
定期的にこれらのハッシュをMerkle木にまとめてオンチェーンに公開する。

このアプローチは、「ビルダーの価格サーバーを信頼する」から、「ビルダーの手法を検証する」へとオラクル定義の信頼性を変換します。過去の価格データを取得し、公開されたアルゴリズムを用いて結果を再計算し、ビルダーのフィードが宣言されたソースと一致しているかを確認できます。

オラクル定義が崩れるとき：監視と介入

優れた設計のオラクル定義も、極端な市場ストレス下では失敗します。HIP-3運用のビルダーは、崩壊を未然に検知する監視体制を整える必要があります。

価格側の監視：オラクルドリフトの検知：

relayerの更新停止は最初の兆候です。オンチェーンの観測値を監視し、連続した更新が10秒以上空いた場合はレベル1のアラートを出す。
価格の乖離：外部ベンチマークからの徐々の乖離も問題です。複数の外部ソースとビルダーのオラクルを比較し、X%以上の乖離があればアラートを上げる。

レベル1ではopen interestの上限設定、
レベル2ではレバレッジの段階的削減、
レベル3では緊急停止（haltTrading）を発動します。

注文板の監視：流動性崩壊の検知：

深さ（depth_band）、スプレッド（spread）、インパクト比（impact_ratio）を追跡し、深さが縮小しつつスプレッドとインパクト比が拡大している場合は危険信号です。
これにより、清算リスクの高まりを早期に察知します。

レベル1ではopen interestの成長制限、
レベル2では高リスクポジションのレバレッジ制限。

ポジション集中の監視：投機連鎖の検知：

実質的なヘッジから純粋な投機への移行を監視します。
OIのノミナル額と24時間取引量の比率を追跡し、OIが取引量を大きく上回る場合は、過剰な片側エクスポージャーの兆候です。
これにより、清算連鎖の前兆を察知し、閾値超過時にアラートを出し、必要に応じてOI上限を引き下げます。

ガバナンスとステーキング：オラクル定義の責任追及

HIP-3の仕組みは、ビルダーの責任をステーキングにより担保します。

ビルダーは常に50万HYPEをステークし続ける必要があります。
バリデーターは、不正な市場状態や長期ダウンタイム、パフォーマンス低下を引き起こす行動に対して、ステークを差し止める投票を行えます。

この仕組みは、オラクル定義の選択に具体的な金銭的結果をもたらします。

単一の中央集権的価格フィードを受け入れたり、ドリフト監視を怠ったり、オフ時間の価格リスクを無視したりするビルダーは、清算連鎖を引き起こす可能性があります。
監視や市場崩壊がValidatorの投票によって直接追跡可能な場合、彼らはステークの差し止めを行うことができます。

これにより、オラクル定義は技術的な決定からガバナンスの決定へと変わります。
Validatorは、差し止め投票を通じてビルダーのオラクル選択を暗黙のうちに承認または罰します。
長期的には、堅牢なオラクル定義を実装するビルダーは生き残り、手抜きのビルダーは差し止め投票を蓄積します。

ただし、完璧ではありません。
Validatorが技術的な判断を公平に行えない場合や、運用の質と無関係に投票する場合もあります。
それでも最低限の責任追及の閾値を設けることになります。

より広い意味：分散化はリスクの再配分

HIP-3の核心的な革新は、リスクの排除ではなく、再配分にあります。
中央集権的取引所は、価格フィードの維持や操作防止、清算管理といった運用リスクを内部に抱えていますが、HIP-3はこれらの責任をビルダーに外部化します。
プロトコルはインフラを提供し、ビルダーは運用の卓越性を担います。

これは、ビルダーが実際に何に責任を持つかを理解している場合にのみ機能します。
オラクル定義は、最も過小評価されている攻撃面の一つです。
単純に価格フィードを選ぶだけに見えますが、実際にはフィードの選択、リレイヤーの管理、オフ時間の価格付け、フォールバックの仕組み、検証フレームワーク、継続的な監視、ガバナンス責任まで含まれます。

いい加減なオラクル定義に基づく市場は失敗します。
慎重に設計され、適切な監視と透明な検証メカニズムを備えた市場は、かなりの取引活動を維持できます。
HIP-3市場を通じて130億ドルの取引量が示すように、十分なビルダーは存在します。しかし、失敗した市場や、オラクル定義の失敗に起因する清算連鎖は、無警戒なトレーダーからプラットフォーム運営者や高度な裁定業者へと資本を移します。

HIP-3に参加するビルダーは、オラクル定義を単なる技術的な実装の詳細と捉えるのではなく、市場の信頼性を左右する根本的な設計決定と考えるべきです。