Builder必読：HIP-3市場のリスク識別と軽減方法

HIP-3（Hyperliquid改進提案3）がメインネットに導入されてから3ヶ月、サードパーティのビルダーが展開したカスタムマーケットの取引累計量は既に130億ドルを突破しています。この数字の背後にあるものは何でしょうか？それはプラットフォームの権力の浸透です。かつて中央集権型取引所が独占していた「新規上場」の権限が、オープンな標準インターフェースに改造されたのです。ビルダーは50万HYPEトークンを担保に預けるだけで、Hyperliquidの統一された取引・清算基盤上に永続契約のマーケットを展開できます。

しかし、権力の浸透とともにリスクも外に移動します。これらのリスクをどう認識し、運用中に問題の兆候をいち早く察知するかは、すべてのビルダーが習得すべきコア能力です。

アーキテクチャの基礎：HIP-3のリスク源を理解する

HIP-3のリスクを識別するには、まずそのアーキテクチャ設計を理解する必要があります。

HIP-3はHyperliquidの二層アーキテクチャに基づいています。HyperCoreはコントラクト取引に最適化されたカスタムL1ブロックチェーンで、毎秒20万件の注文処理と決定性のある最終性を持ちます。HyperEVMはアプリケーション層で、スマートコントラクトを動かせます。この構成の巧みさは、マッチング、清算、決済をプロトコルが一元的に提供し、ビルダーはゼロから取引システムを構築する必要がない点にあります。

しかし、その反面、ビルダーの責任範囲は明確であると同時に脆弱でもあります。すなわち：**責任が明確（市場の定義と運営）である一方、責任が完全に外部委託されている（リスク管理の権限がビルダーに集中）**ということです。

ビルダーは50万HYPEを担保に預け、二つの大きな責任を負います：

• 市場定義：オラクル価格源、コントラクト仕様（レバレッジ、最小注文単位など）、担保資産の選択
• 市場運営：価格の継続的供給、証拠金表の調整（レバレッジ上限）、必要に応じた市場の停止

市場が立ち上がると、担保ロックは30日間解除申請ができません。つまり、運用の不手際は検証者の罰没投票の対象となりますが、その前にビルダーは問題の存在を認識しておく必要があります。

3層の価格設定メカニズム：Oracle価格の健全性をどう判断するか

HIP-3で最も重要かつリスクが生じやすいのは、価格供給の仕組みです。ビルダーはsetOracleインターフェースの3つの価格入力を理解する必要があります。

oraclePx（必須）：ビルダーのrelayerサーバーが総合計算し、資金費用のアンカーとなる値。 markPx（任意）：ビルダーが提出する0～2組の外部マーク価格候補値。mark priceの候補。 externalPerpPx（必須）：CEXの永続契約からの加重中央値。mark priceの突然の乖離を防ぐため。

最終的なmark priceは、喂価を直接使うのではなく、「ローカルの注文簿の最良Bid/Ask/Lastの中央値」とmarkPxの中央値の「中間値」を取る仕組みです。これが意味するのは何でしょうか？

これには複数の失効ポイントが存在します：

• relayerがオフラインまたはDDoS攻撃を受けた場合、oraclePxの喂価が中断
• markPxのアルゴリズムに欠陥があれば、アービトラージの標的に
• ローカル注文簿が薄いとmedian計算が価格を歪める

setOracleの制約条件は厳格に見えます：

• 更新頻度：2回の呼び出し間隔≥2.5秒、10秒未更新なら自動的にlocal mark priceに退避
• 振れ幅制限：markPxの変動は±1%以内、価格は当日の始値の10倍範囲内にクランプ

しかし、これらの制約は、株式などの非24時間取引資産には大きな保護効果が薄れます。

非24時間資産の潜在リスク：取引停止期間の価格設定の罠

BTCのような24時間取引資産では、ビルダーはCEXやDEXの継続的な価格源に依存できます。しかし、株式などの非全天候資産では、休市期間中の価格判断はどうすれば良いのでしょうか？

現状の方法は、「前回の終値と内部注文簿の圧力を用いた特殊な価格設定メカニズム」に依存しています。具体的には、mark priceは前回の終値から±10%（例：レバレッジ10倍なら±10%）の範囲内に制限されます。

この仕組みの問題点は何でしょうか？外部市場に流動性のアンカーがない場合、内部注文簿の深さ自体が薄くなりやすい点です。大口委託が入ると、休市中に価格の虚偽の振れが生じやすくなります。特に、多頭ポジションが集中しているときに顕著です。

2025年12月14日、trade.xyzのXYZ100-USDC市場（NASDAQ100に対比）は操作されました。攻撃者は約10M USDCの空売りポジションを作成し（398ポジション）、意図的に価格を押し下げ、多くのロングポジションを短時間で一斉清算させ、最終的に約13M USDCのロングポジションが強制清算されました。

この根本的な問題は：

• 休市期間中の外部価格のアンカーが欠如
• 内部深さが十分でなく、価格発見の外的要因に耐えられない
• 清算が始まると、価格のフィードバックがさらに下落を拡大させる

オラクルリスク：中央集権的脅威と脱アンカーの危険性

ビルダーが展開するrelayerサーバーは、根本的に中央集権的リスクを孕みます。秘密鍵の漏洩、DDoS攻撃、アルゴリズムの誤りなど、いずれも喂価の中断や操作を引き起こす可能性があります。

オラクルリスクを識別するための4つの重要なシグナル：

1. 喂価遅延または中断

   • 監視：オンチェーンで観測できる最後のsetOracle呼び出しのタイムスタンプ
   • アラート閾値：10秒以上未更新なら自動的にlocal markに退避。脱アンカーのリスクが急上昇
   • 対応策：予備relayerに切り替え、ヘルスアラートを発出

2. 価格の脱アンカー

   • 監視指標：
     • oracle priceとCEX perpの中央値の乖離
     • mark priceとoracle priceの差
     • ローカル注文簿と外部市場の乖離
   • 識別方法：2つ以上の指標が閾値超えした場合に脱アンカーと判定
   • 対応策：max leverageの段階的引き下げ、より厳格なclampの導入

3. 非24時間資産のギャップオープン

   • 監視：休市期間中の内部価格と開盤価格の予想差
   • 参考源：Blue Ocean ATS（アフターマーケット取引）や週末CFD报价
   • 判定：開盤前にギャップリスク>5%を検知したら早期警告

4. フェイク流動性

   • 監視：注文簿の深さとアクティブ注文比（アクティブ注文量/未約定注文量）
   • 識別：深さが短時間で急上昇後に突然消失
   • 対応策：OI上限を即時引き下げ、新規ポジション増加を制限

パラメータ設定の落とし穴：ビルダーが見落としやすいリスク

多くのビルダーはパラメータを設定すれば安心と思いがちですが、実際には動的調整こそが運用の肝です。

重要な設定リスク：

1. レバレッジの過剰設定 流動性の低い市場では、max leverageを高く設定しすぎると、ADL（自動レバレッジ除去）の発動確率が高まります。ポジションが急速に増大し、多数派の損益が極値に近づくと、価格変動により連鎖的な清算が起きやすくなります。

2. margin tableの突然の調整 一夜にしてすべてのユーザーの維持証拠金比率を変更することは、瞬時に多くのアカウントを「安全」から「清算可能」へと変化させ、集団的な強制清算を引き起こします。この操作は事前に通知し、段階的に行う必要があります。

3. haltTradingの濫用 ビルダーはhaltTradingを呼び出して市場を停止し、すべての注文をキャンセルし、現在のmark priceで決済できます。しかし、この「両刃の剣」を不適切に使うと、攻撃者の一時的な利益確定を助長します。攻撃者は十分な対抗注文がなくとも、mark priceで決済させることで利益を確保できるからです。

4. クロスマージンモード（将来のリスク） 現状、HIP-3は逐次証拠金（逐倉）のみをサポートしています。将来的に全倉（クロスマージン）をサポートすると、流動性の低い市場のリスクが高流動性市場に伝播します。公式の成熟した解決策が出るまでは、ビルダーは試すべきではありません。

多次元リスク監視体系：価格からポジションまでの包括的アラートフレームワーク

リスクはあらゆる場所に存在します。ビルダーは多次元・多層のリアルタイム監視体系を構築すべきです。

価格側監視

レベル1アラート（喂価異常）：

• 指標：setOracle呼び出し間隔>5秒
• アクション：relayerの健全性を確認し、予備ノードに切り替え
• 出力：全relayer情報を含む警告

レベル2アラート（価格脱アンカー）：

• 指標：oracleとCEX perpの偏差>2%、かつ5秒以上継続
• アクション：setOpenInterestCapsを呼び出し、OI上限を引き下げ
• さらに：margin tableのmax leverageも段階的に低減

レベル3アラート（長期偏移）：

• 指標：脱アンカー状態が30秒以上続く
• アクション：clamp機能を有効化し、価格変動を強制制限
• 最終的に：ビルダーがhaltTradingを呼び出し、市場停止を判断

盘口側監視

深さの抽出信号：

• 監視：±2%の価格範囲内の実質的な注文深さ（depth_band）
• 警告：depth_bandの低下とともにBid-Askスプレッド拡大、アクティブ注文比（impact_ratio）の上昇
• 判定：これらが同時に起きると、市場流動性の急激な悪化を示す
• 対応：OI上限を引き下げ、新規ポジション増加を制限

フェイク注文の識別：

• シグナル：深さが短時間で急上昇後に突然消失
• 対応：OIを現在の水準に制限（増加禁止）、価格の脱アンカーが深刻な場合は市場停止も検討

ポジション側監視

ポジション側の目的は「価格予測」ではなく、「市場が取引駆動からポジションの博弈に変わったかどうか」の識別です。

OI過剰の兆候：

• 計算：OIの名目額 / 24時間の取引量の名目額
• 判定：この比率が急上昇すると、市場の激しい変動が近いことを示す
• 対応：警告を出し、レバレッジを引き下げる準備をする

多数派の損益信号：

• 指標：多くのポジション保持者（LongまたはShort）の平均建値、ポジション規模、現在の損益比率
• 警告：多数派の損益が極値（例：ロングが20%以上の含み益）に近づくと
• 含意：外部ショックがあれば、清算の連鎖を加速させる
• 対応：事前にレバレッジを引き下げ、極端な損失拡大を防止

リスク検証：予言機を監査・再計算可能に

監視だけでは不十分です。ビルダーは喂価の過程自体を「検証可能」にする必要があります。

価格証明体系の構築：

1. 公開アルゴリズムとデータソース

   • setOracleのロジックとパラメータを公開
   • すべてのデータソースとその重みを明示
   • 更新頻度と変動制限も公開

2. チェーン外検証可能な証明の生成

   • setOracle呼び出しごとにProofを生成
     • Inputs：原始データとタイムスタンプ
     • 計算：中間結果
     • Outputs：最終的にオンチェーンに記録されるoracle price
   • Proofをシリアライズし、proofHashにしてビルダーが署名

3. 定期的にMerkleRootをオンチェーンに書き込み

   • すべてのproofHashをMerkle Treeに格納
   • 1時間または1日ごとにMerkleRootを公開
   • これにより、任意の喂価が真実かどうか検証可能

4. オープンソースの検証ツール提供

   • ユーザーは時間やtxハッシュを入力し、完全なデータを取得
   • 署名、タイムスタンプ、MerkleRootの検証
   • oracle priceとオンチェーンデータの再計算と比較

この体系の意義は、ビルダーのrelayerが攻撃された場合でも、ユーザーがオフチェーンで異常を検出し、プロトコルの責任追及の証拠を得られることにあります。

リスクの隔離：資産ごとにカスタマイズした戦略

異なる資産タイプはリスク特性が全く異なるため、監視閾値も資産ごとに調整すべきです。

24時間取引資産（BTC、ETHなど）：

• 強み：外部価格源の連続的なアンカー
• 重要監視：relayerの安定性、oracleとCEX perpの偏差
• 閾値：比較的緩やか（脱アンカー>3%で警告）

非24時間資産（株式など）：

• 弱み：休市期間中の外部アンカー欠如
• 重要監視：開盤前のギャップ予測、休市中の虚偽変動
• 閾値：より厳格（脱アンカー>1%で警告）
• 参考源：Blue Ocean ATS（夜間取引）や週末CFD报价
• 特別対応：リスク高い時間帯（終値前1時間、始値後30分）にレバレッジを制限

清算とADL：極端な事態のリスク連鎖理解

清算自体はリスクではなく、その先の「連鎖反応」がリスクです。HIP-3はHyperCoreの清算ロジックを踏襲し、ポジションの純資産が維持証拠金を下回った場合に清算を行います。システムはまず注文簿を使った市価での清算を試みますが、注文簿の深さ不足により、実際の清算価格がmark priceから乖離し、"清算ギャップ"が生じることがあります。

このギャップが拡大すると、ADL（自動レバレッジ除去）機能が作動します：

• 対抗側のポジションを選び、利益を持つポジションから減仓
• mark priceで強制的に縮小し、ギャップを埋める
• 利益側のポジションの利益を使ってギャップを補填し、システムの不良債権化を防ぐ

しかし、ADLの発動は、市場が極端な状態にあることを示します。これが起きると、利益側は少なくとも利益を削られ、信頼性が低下し、さらなるリスクを誘発します。

ビルダーはどうやってADLの兆候を察知するか？

• 監視：ポジション集中度、OI規模、注文簿の深さ
• シグナル：OI / 深さの比率が急上昇
• 予防：レバレッジを事前に引き下げ、極端な損失拡大を防止

追責の未来：標準化・検証・監督の三位一体

HIP-3の革新は、「権力を下に落とすとともに、責任も書き込む」点にあります。

検証者は、運用の不手際を行ったビルダーに対し、投票による罰金・没収を行います。罰金の割合は深刻さに応じて決まります：

• 無効状態や長時間のダウンタイム：最大100%の担保没収
• 一時的なダウンタイム：最大50%
• パフォーマンス低下：最大20%

没収された担保は、被害者への補償ではなく、焼却されます。これにより、ビルダーの信用と資産は大きく傷つき、運用の抑止力となるのです。

ただし、罰金の効果を高めるには、次の前提条件が必要です：

1. リスクが十分に観測可能であること：包括的な監視体系
2. 責任追跡が可能であること：検証可能な喂価証明
3. 判定が実行可能であること：投票メカニズムの透明性と効率性

まとめ：展開できるだけでなく、安定して運用できる状態へ

HIP-3は、プラットフォームの承認を不要にし、第三者のマーケット取引量が既に130億ドルを超えたことから、その方向性の実現性を証明しています。ただし、その代償は、「プラットフォーム側のリスク管理を一部外部に委ねる」ことです。

ビルダーの視点では、「どうやって市場リスクを認識し、いち早く対応するか」が重要です。具体的には：

1. リスク源の理解：アーキテクチャ、価格設定、パラメータ、流動性の多角的理解
2. 監視体系の構築：価格、盘口、ポジションの全次元でリアルタイム警告
3. 検証メカニズムの実装：喂価の透明化と証拠の追跡
4. 緊急対応策の準備：レバレッジ引き下げ、OI制限、市場停止

長期的な安全性の鍵は、ビルダーが信頼できる予言機の導入、適切なパラメータ設定、継続的な市場状態の監視を実現できるかどうかにかかっています。

HIP-3は、「上場をより自由にする」ためのものではなく、「標準化された運用を可能にする」ための枠組みです。最終的に安定して動かすには、ビルダーのリスク理解と実行力が問われます。

もし、HIP-3を基にした市場参入規範の設計、パラメータテンプレートの策定、警告システムの構築、またはリスク監査・安全性の継続的支援を必要とする場合は、BlockSecなどの専門セキュリティチームが深い技術コンサルと監査サービスを提供します。