Hyperliquid改善提案3（HIP-3）[1]は、Hyperliquidにおける永久市場の作成およびスケーリング方法に根本的な変更をもたらします。HIP-3は、市場リスティングプロセスをサードパーティビルダーに開放することにより、リスティングを裁量的でプラットフォームが制御するアクションから、プロトコルレベルの、許可されたインターフェースへと移行させます。

メインネット展開以来、ビルダーが展開した市場は、約3ヶ月で130億ドル以上の取引量を生成し、HIP-3が市場拡大のスケーラビリティと柔軟性を実質的に向上させることができることを実証しました。しかし、この移行は単に権力を分散させるだけでなく、責任を再配分します。以前は中央集権的なプラットフォーム運用によって吸収または軽減されていたリスクは、現在、ビルダーが直接負担します。

その結果、HIP-3の下での中心的な問いは、市場がローンチできるかどうかではなく、時間とともに安全に運用できるかどうかになりました。本レポートは、ビルダー中心の視点からHIP-3を分析し、市場がどのように定義され運用されるか、ビルダーが直面するリスク、そしてそれらのリスク、特にオラクル関連のリスクをどのように軽減できるかに焦点を当てます。

0x1 背景

Hyperliquidのアーキテクチャ[2]は、実行およびリスクインフラストラクチャを市場定義から切り離すことで、このモデルから逸脱しています。そのデュアルレイヤー設計は以下から構成されます。

• HyperCore：デリバティブ取引に最適化された、デリバティブ取引専用に構築されたレイヤー1ブロックチェーンで、統一されたマッチング、清算、決済を提供します。
• HyperEVM：拡張可能なロジックとビルダーインタラクションを可能にするEVM互換アプリケーションレイヤーです。

このアーキテクチャにもかかわらず、Hyperliquidのネイティブ永久市場（バリデーター運用パーペチュアルとも呼ばれます）のリスティングプロセスは、依然として従来のCEXアプローチに似ています。新しい契約のリスティングは主にコアチームによって推進され、デリスティングはバリデーター投票によって決定されます。

HIP-3は、ビルダー展開による永久市場を可能にすることで、このリスティングプロセスを分散化するために導入されました。市場定義とプロトコル強制実行の分離を正式化し、ビルダーが市場を定義および運用できるようにし、プロトコルがハードな実行とリスク境界を強制します。そのため、HIP-3は、完全に分散化されたパーペチュアルリスティングプロセスに向けた重要なマイルストーンを表しています。

0x2 ビルダーの責任：定義と運用

HIP-3の下では、ビルダーの責任は2つのフェーズにわたります：市場定義と市場運用。まず、エンドツーエンドのローンチワークフローの概要を説明し、次に、市場が本番環境で安定しているかどうかを判断する重要な焦点領域を強調します。

0x2.1 市場ローンチフロー：定義と運用

HIP-3の下では、市場のローンチは単一のアクションではありません。以下の完全な市場ローンチワークフローで示されるように、それは市場定義（ステップ1から4）と市場運用（ステップ5）の2つの異なるフェーズにわたるプロセスです。

市場定義フェーズ中、ビルダーはまずメインネットで500,000 HYPEをステークする必要があります。ステーク要件を満たした後、ビルダーは1つの永久DEXを展開でき、これは独自の証拠金システム、注文板、およびデプロイ担当者制御の設定を備えた独立した取引ドメインを形成します。DEXレベルでは、ビルダーはそのDEX上のすべての市場の担保として使用される引用資産を選択します。選択された引用資産は、許可不要なステータスを維持する必要があります。このステータスを失うと、対応するDEXが無効になります。次に、ビルダーはオラクル仕様、シンボルやレバレッジ制限などの契約パラメータ、および証拠金テーブルを含む、コア市場パラメータを定義します。最初の3つの市場は直接展開できますが、追加の市場はダッチオークションを通じてスロットを取得する必要があります。

ダッチオークション：各ラウンドは31時間続き、毎回開始価格は前回の最終価格（最後の落札価格/最低価格）の2倍になります。

市場がライブになったら、ビルダーは市場運用フェーズに入ります。このフェーズには、setOracleインターフェースを介したオラクル価格の継続的な更新、レバレッジと証拠金構成の維持、流動性と未決済建玉の監視、および必要に応じた取引停止やポジション決済などの緊急アクションの実行が含まれます。

実際には、HIP-3の下での最も深刻な失敗のほとんどは、市場定義中ではなく、ストレスのかかった市場条件下での長期運用中に発生します。重要なことに、ビルダーの責任は、市場を停止した直後には終了しません。アンステークは、すべての市場が決済された後にのみ可能になり、アンステーク期間中はステークはスラッシュ可能のままです。

0x2.2 重要な焦点領域：価格設定とソルベンシー

ビルダーは、市場定義と市場運用全体にわたって、互いに連動する2つの焦点領域に直面します：オラクル構成と価格形成、およびストレス下での市場ソルベンシー。これらの2つの領域は密接に連携しています。価格設定の失敗は、プロトコルレベルのリスク制御を通じてソルベンシーストレスに迅速に伝播する可能性があるためです。

0x2.2.1 オラクル構成と価格形成

Hyperliquidは2つの価格を定義します。

• オラクル価格：主要な外部取引所からのスポット中間価格の加重中央値で、Hyperliquidの内部市場データから独立するように設計されており、主に資金調達のアンカーとして使用されます。
• マーク価格：オラクル価格やローカル市場データを含む複数の入力から導出される内部リスク価格で、未実現損益（PnL）およびリスク制御に使用されます。

要するに、オラクル価格は資金調達をアンカーし、マーク価格は証拠金チェック、清算、およびTP（テイクプロフィット）とSL（ストップロス）トリガーを推進します。

HIP-3の下では、オラクル価格とマーク価格の役割は変わりませんが、計算メカニズムが変更されます。

1. setOracleへの入力
   • oraclePx（必須）：HyperCoreでの定義と同じです。
   • markPx（オプション）：0〜2の外部計算マーク価格候補。
   • externalPerpPx（必須）：マーク価格の急激な乖離を防ぐための参照値。

ビルダーは通常、リレ​​ーノードを展開して価格を供給します：oraclePxは複数の外部ソースから計算され、markPxはリレ​​ーによってカスタムアルゴリズムで計算され、externalPerpPxは複数のCEXからのパーペチュアル中間価格の加重中央値から計算されます。

2. 実際のマーク価格
   • ローカルマークを計算します：「最高買い値、最高売り値、最終取引」の中央値。
   • ローカルマークとmarkPx（0〜2の値）を一緒に取り、中央値を取って新しいマーク価格を取得します。
3. setOracleの制約
   • 更新頻度：呼び出し間隔は少なくとも2.5秒。markPxが10秒間更新されない場合、ローカルマーク価格にフォールバックします。
   • 振幅制限：markPxは更新あたり±1％までしか変更できません。すべての価格は、その日の開始価格の10倍以内にクランプされます。

なぜ資産タイプがHIP-3の価格設定において重要なのか

HIP-3の下では、あらゆるタイプの資産の永久市場がローンチできます。これらの資産は、一般的に24時間年中無休の資産（常時取引可能）と、24時間年中無休ではない資産（特定の市場時間のみ取引可能で、それらの時間外はスポット取引なし）に分類できます。取引時間の違いは、価格の調達方法と維持方法を根本的に決定します。

24時間年中無休の資産（例：BTC）の場合、CEX、DEX、または信頼できるオラクルサービスからデータを集約することで、比較的安定した価格を継続的に取得できます。

24時間年中無休ではない資産（例：株式）の場合、十分な流動性と信頼できる外部市場価格は、公式の取引時間中にのみ利用可能です。HIP-3でそのような資産の継続的な取引を維持するために、市場時間外には別の価格設定メカニズムを使用する必要があります。

trade.xyzの株式パーペチュアル市場を例にとると：

1. 市場時間中、Pythのような外部オラクルサービスによって安定したオラクル価格が提供されます。
2. 市場時間外、価格は資産の最後の決済価格に基づいて調整され、注文板からの内部の買い/売り圧力が組み合わされます。マーク価格は、最後の決済価格の**±1 / max_leverage**の範囲内で変動するように制約されます（例：テスラ：10倍レバレッジ→±10％）。

0x2.2.2 ストレス下での市場ソルベンシー

Hyperliquidは、市場ソルベンシーを維持するために、清算とADL（自動レバレッジ解消）の2つのメカニズムを採用しています。HIP-3の下では、清算とADLはHyperCoreの設計にほぼ従います。主な違いはプロトコルレベルの制限です：HLP（Hyperliquidity Provider）は、プロトコルウォールトとして機能し、HIP-3市場でのリスクの高いポジションを引き継ぐことはできません。その結果、HyperCoreで市場清算とADLの間にポジションを吸収できる中間ウォールトバッファーが、HIP-3には存在しません。

ストレスのかかった市場条件下でのこの清算からADLへの経路の重要性を考慮すると、清算とADLを詳細にレビューします。ここで議論されるすべてのソルベンシーメカニズムは、HIP-3市場で現在サポートされている唯一の証拠金モードである分離証拠金を想定しています。

1. 清算

ポジションの純資産価値（分離ポジション価値）が維持証拠金要件を満たすのに不十分になると、清算がトリガーされ、清算可能になります。清算関連のすべてのチェックは、特定の執行価格ではなく、マーク価格に基づいています。

清算価格の計算式は以下のとおりです。

ここで：

• side：ロングポジションの場合は1、ショートポジションの場合は-1
• lは維持証拠金率です。

MAINTENANCE_LEVERAGEの値は、ポジションに対応する証拠金ティアによって決定されます。そのティアから、維持証拠金率mmrが得られます。

証拠金ティアが構成されている場合、清算価格でのポジションの額面値に対応するティアのmmrを適用します。

• margin_available（分離）：isolated_margin - maintenance_margin_required

ポジションが清算可能になると、システムはまず注文板での成行注文を通じてポジションを決済しようとします。実行がリスクを安全な範囲内に戻すことに成功した場合、残りの証拠金はトレーダーに返却されます。

ただし、注文板の深さが不十分な場合や価格ギャップがある場合、実際の平均執行価格はマーク価格よりも著しく悪くなる可能性があり、「清算不足」を引き起こします。

分離ポジション価値とは、現在のマーク価格における分離ポジションの純資産価値を指し、未実現損益を考慮した後の、そのポジションに割り当てられた証拠金を表します。

ADL（自動レバレッジ解消）

極端なシナリオでは、ADL（自動レバレッジ解消）メカニズムが最終的なバックストップとして機能します。

ADLは、分離ポジション価値がマイナスになった場合にトリガーされます。システムは、損益とレバレッジによって利益の出ているカウンターパーティをランク付けし、前のマーク価格（ADLがトリガーされる前の記録されたマーク価格）でこれらのポジションを強制的に削減または決済します。勝者の利益を使用して赤字を相殺することで、プロトコルはソルベントを維持し、不良債権を発生させません。

ソートインデックスは次のように計算されます。

ここで、notional_positionは、|position_size| × mark_priceとして計算される、現在のマーク価格におけるポジションの額面価値を指します。account_valueは、マーク価格でのアカウントの株式資本（つまり、担保価値+未実現損益）を意味します。

例：

• ADLがトリガーされる前、システムのマーク価格 = 3,000。
• setOracleの制約により、新しいマーク価格は**2,970（-1％）**にしか更新できません。
• ただし、注文板のビッド側は非常に薄いです。清算成行注文が板にヒットした後、実際の平均執行価格 = 2,910（3,000に対して-3％）となります。
• ロングポジションの損失は2,910で決済され、分離ポジション価値がゼロを下回る可能性があり、不足が発生してADLをトリガーします。
• ADLは次に反対側（利益の出ているショート）のポジションを選択し、前のマーク価格=3,000で強制的に削減/決済し、不足を**「勝者の利益が受動的に少なくなる」**ことにシフトします。

0x3 ビルダーのリスクランドスケープ

HIP-3の下では、リスクはもはやビルダーにとって抽象的または純粋に理論的なものではありません。ステークとバリデーターによって管理されるスラッシングを通じて、運用上の失敗や誤設定は直接経済的ペナルティに変換される可能性があります。その結果、スラッシングがどのようにトリガーされるか、そしてどのような種類のビルダーの行動がそれを引き起こすかを理解することが、ビルダーのリスクモデルの中心となります。したがって、このセクションでは、まずスラッシングメカニズムを説明責任のフレームワークとして説明し、次にHIP-3の下でビルダーが直面する2つの主要なリスク源を分析します。

0x3.1 スラッシングメカニズムと説明責任

HIP-3は、ステークとバリデーターによって管理されるスラッシングを通じて説明責任を強制します。スラッシングは厳密に結果に基づいています。Hyperliquidは、悪意のある行動、運用上の間違い、秘密鍵の漏洩、またはサードパーティの依存関係の失敗を区別しません。

ステーク要件：メインネットでは、ビルダーは500k HYPEをステークした状態を維持する必要があります。ビルダーがすべての市場を停止した場合でも、30日間維持する必要があります（取引が停止しても責任はすぐに消えません）。

ビルダーの行動が不正な状態、長時間のダウンタイム、または著しいパフォーマンス低下を引き起こした場合、スラッシングがトリガーされる可能性があります。深刻度に応じて、スラッシングは部分的なステーク削減から完全なステーク燃焼まで範囲が異なります。この設計により、ビルダーは市場の完全なランタイム動作に対して経済的責任を負います。

スラッシングの割合はバリデーターの投票によって決定され、参照上限があります。

• 不正な状態/長時間のダウンタイム：最大100％
• 短いダウンタイム：最大50％
• パフォーマンス低下：最大20％

スラッシュされたトークンは燃焼され、再配布されません。

HIP-3の下では、ビルダーのリスクは主に2つのソースから生じます：内部パラメータの誤設定と外部オラクル依存関係。次のセクションでは、これらの2つのソースを詳細に調べ、それらがスラッシング結果にどのように変換されるかを説明します。

0x3.2 内部パラメータの誤設定によるリスク

誤設定リスクには、低流動性市場での過剰なレバレッジ、不適切な証拠金テーブル設計、多数のポジションを清算可能にするパラメータの突然の変更、および取引停止などの緊急制御の不適切な使用が含まれます。

これらのリスクは、ほとんど決定論的で回避可能です。十分な注意、レビュー、および運用の規律があれば、ほとんどの内部構成エラーは回避できます。重要ではありますが、HIP-3の下で最も構造的に困難なリスクではありません。

1. setOracle

オラクル価格は通常、ビルダーのリレ​​ーサーバーから取得されますが、これは中央集権化リスクをもたらします。秘密鍵が漏洩したり、リレ​​ーがDDoS攻撃を受けたりすると、市場のオラクル価格が悪意を持って操作されたり、長期間乖離したままになる可能性があります。

2. haltTrading

ビルダーは、haltTradingを介して市場内のすべての注文をキャンセルし、現在のマーク価格でポジションを決済できます。この操作は慎重に使用する必要があります。たとえば、市場が悪意を持って操作されていると検出され、haltTradingがマーク価格で決済するために呼び出された場合、攻撃者の未実現利益を直接実現する可能性があり（攻撃者は反対注文を見つけるのに苦労するかもしれませんが）、不良債権につながる可能性もあります。

3. setMarginTableIds & InsertMarginTable

• InsertMarginTable：証拠金要件と資産クラスの最大レバレッジを指定する新しい証拠金テーブルを定義します。
• setMarginTableIds：市場を指定されたmarginTableIdにバインドします。

低流動性/市場メイキングが不十分な市場では、最大レバレッジを高く設定すると、ADLがトリガーされる確率が高まります。

突然marginTableIdを切り替えることは、ユーザーポジションの維持証拠金率を変更することに相当し、多くの口座が同時に安全から清算可能になり、連鎖的な清算を引き起こす可能性があります。

4. setMarginModes

HIP-3は現在、分離証拠金のみを許可しており、将来的にはクロス証拠金をサポートする可能性があります。高流動性市場と低流動性市場の両方をホストするDEX内では、クロス証拠金は、非流動性市場での損失が流動性市場に波及するリスク伝染を可能にします。したがって、公式チームが成熟したソリューションを提供するまで、ビルダーがクロス証拠金を導入することは推奨されません。

0x3.3 外部オラクル依存関係によるリスク

24時間年中無休の資産の場合、主なリスクは外部オラクルサービスの精度と安定性、および前述のリレ​​ーサーバーの中央集権化リスクにあります。これらの外部依存関係の中断、遅延、または操作は、価格設定の整合性と下流のリスク制御に直接影響を与える可能性があります。

24時間年中無休ではない資産の場合、リスクサーフェスは大幅に広くなり、主に非取引時間中にオラクル価格がどのように取得または計算されるかに集中しています。

trade.xyzを例にとると、市場時間外には、価格は最後の利用可能な外部オラクル価格と内部市場価格の組み合わせから派生します。週末には、株式パーペチュアル市場はしばしば流動性が大幅に低下します—注文板が薄くなり、マーケットメーカーの引用が縮小します—外部オラクル価格はアンカーを提供するために利用できません。価格変動にハードキャップが課されていても（例：1 / max_leverage）、この制約は低ボラティリティ資産にとっては緩すぎることがあります。この範囲内の価格変動であっても、大規模な清算やADLイベントをトリガーする可能性があります。

2025年12月14日、trade.xyzのXYZ100-USDC市場—NASDAQ-100を追跡する永久契約—が操作されました。攻撃者は398 XYZ100（額面で約1000万USDCの露出）をショートし、深刻な価格乖離を引き起こしました。多数のロングポジションが清算され、清算自体がさらに価格を押し下げ、最終的にロングサイドの清算で約1300万USDCが発生しました。

this is probably the first such move under the ‘growth mode’ regime on the weekend. Someone slammed the market, dropping the price of XYZ100 by more than 3% in a minute and liquidating roughly $3M worth of positions pic.twitter.com/XttBHfTB0D

— bart.hl (equity perps era) (@bartdothl) December 14, 2025

一方、市場時間外には、継続的で外部にアンカーされたオラクル価格の不在により、市場は「最後の外部価格 + 内部注文板」によって形成される制約された内部価格帯に依存せざるを得なくなります（例：trade.xyzは最大変動を1/max_leverageに制限します）。

最も重大なリスクは、市場再開の移行時に発生します。外部市場は、明確で権威ある参照価格を突然提供できます。この価格が、市場時間外の内部価格設定と著しく乖離している場合、システムは2つの不都合な経路に直面します。価格がクランプされたままになり、外部の公正価値と取引可能な価格との間に深刻な乖離が生じるか、システムが外部アンカーに急速に戻り、突然の価格再設定をトリガーします。どちらのシナリオも、短い時間枠内に清算圧力を集中させ、極端な場合はADLイベントの急増につながる可能性があります。

0x4 ビルダーのリスク制御

構成規律だけではリスクを排除できません。最も効果的な軽減戦略は、オラクル依存関係の失敗への露出を減らすことに焦点を当てています。

0x4.1 安定したオラクルの選択

株式などの24時間年中無休ではない資産の場合、主な課題は市場時間外の価格設定にあります。これらの期間中、安定した外部にアンカーされた価格参照は乏しく、市場は操作や希薄な流動性下での内因性のドリフトの影響を受けやすくなります。

現在、業界のアプローチは一般的に2つの方向に分かれます。

• 1. 市場時間外のオラクル更新の停止と取引の制限。 たとえば、Lighterプロトコルは、基盤となる市場が閉鎖されている場合にのみ、削減のみの注文を受け付けます。Ostiumなどのプロトコルは、市場時間外の最大レバレッジをさらに削減し、新しい制限を超えるポジションを強制的に清算します。
• 2. trade.xyzで見られる「内部価格設定」メカニズムの採用。プロトコルは、外部データが利用できない場合に内部流動性と価格設定アルゴリズムに依存することで、時間外でも継続して動作します。

これら2つのアプローチは、セキュリティとユーザーエクスペリエンスの間の根本的なトレードオフを反映しています。最初のアプローチは厳格なリスク制御を優先しますが、取引の継続性とユーザーエクスペリエンスを大幅に低下させます。2番目のアプローチは継続的な取引を維持しますが、外部参照がないため、内部価格が資産の根本価値から乖離するリスクが増加します。

市場時間外には、プロトコルの価格設定は、純粋な内部価格への完全な退化を避けるべきです。代わりに、外部参照アンカーを導入することで、価格乖離とギャップリスクを減らすことができます。可能な参照には以下が含まれます。

• Blue Ocean ATS。アフターアワーズ/ナイト取引会場として、クローズ期間中の継続的な価格参照の程度を提供できます（「最終決済価格」よりもタイムリー）、クローズ期間のオラクル価格を生成したり、価格乖離の監視ベースラインとして機能したりします。
• IG Weekend CFD Quotes。週末のCFD引用は、「週末の市場期待」を反映する代替価格シグナルを提供でき、クローズ期間中に外部アンカーまたは監視比較として適しており、開場ギャップの可能性のある方向と magnitude を事前に検出するのに役立ちます。

これらのソースの共通の特徴は、市場時間外に価格シグナルを提供できることです。しかし、それらは基盤となるスポット市場と同じ市場構造を共有していないため、無条件の代替としてよりも、アンカー、参照、または早期警告シグナルとして適しています。

0x4.2 価格検証

HIP-3の下では、オラクル価格はビルダー運用リレ​​ーサーバーから取得され、これは中央集権化に関する懸念をもたらします。これを軽減するために、ビルダーは、RedStoneが価格とデータソースおよび暗号証明をバンドルする方法と同様に、任意のユーザーまたは機関がオフチェーンで価格設定の正確性と公正性を検証できる価格検証フレームワークを実装することが奨励されています。

1. データ透明性

• アルゴリズム仕様：価格設定アルゴリズムと計算ロジックを公開します。
• データソースリスト：すべてのソースは公開され、ビルダーの操作に耐性があり、詳細なインターフェースとパラメータで文書化されている必要があります。
• 価格送信ルール：setOracleの権限、トリガー条件、更新頻度、およびボラティリティ制限。

2. 価格証明

各setOracle呼び出しに対して、対応する証明を生成します。これには以下が含まれます。

• 入力：サンプリングタイムスタンプでの各データソースからの生の（または正規化された）応答。
• 計算：計算ステップごとの再現可能な中間値。
• 出力：オンチェーンで送信されたオラクル価格。

各証明はproofHashにシリアライズされ、その後oracleUpdaterによって署名されます。

3. オンチェーンコミットメント

• マークルツリーにproofHashエントリのシーケンシャルリストを維持します。
• 定期的に（例：毎時または毎日）マークルツリーのルートをオンチェーンに公開します。

4. 検証

• オープンソースツールまたはWebページを提供し、ユーザーが時間範囲またはsetOracleトランザクションハッシュを入力できるようにします。
• 署名、タイムスタンプ、マークルツリーなどを検証します。
• 比較のために、公開アルゴリズムを使用してオラクル価格を再計算します。

0x4.3 リスク監視

価格検証により、setOracleは再計算可能で監査可能になり、価格フィードが信頼できるかどうかを確認できます。しかし、それはライブ市場の悪化から保護することはできません。フィードの中断、価格の乖離、および流動性の低下は、大量の未決済建玉（OI）と組み合わされると、局所的な異常をシステムリスク（連鎖的な清算やADLイベントなど）に容易にエスカレートさせる可能性があります。

したがって、市場の異常は可能な限り早期に検出され、観測可能なシグナルに変換され、リスクを管理可能な範囲内に封じ込める時間枠内に処理される必要があります。

監視を断片的なものではなく実行可能なものにするために、シグナルを3つのレイヤーに整理し、それぞれが異なる障害モードと応答優先度に対応させます。

• 価格サイド監視は、ソースでリスク制御を無効にする可能性のあるオラクルフィードの失敗と価格乖離を検出するため、最高優先度として扱われ、通常はリレ​​ーフェイルオーバー、未決済建玉キャップ、およびレバレッジ削減によって処理されます。
• 注文板サイド監視は、清算スリッページと不足リスクを増幅する流動性の引き出しと偽造された深さを捉えるため、介入は増分エクスポージャーの制限と、脆弱性が増加した場合のレバレッジ解消の強制に焦点を当てます。
• ポジションサイド監視は、市場を連鎖に対して脆弱にする急激な未決済建玉の増加と片側集中を追跡します。これは通常、価格と流動性のシグナルよりも優先度が低く、主に、より厳しいキャップと増強されたアラートを通知する早期警告レイヤーとして機能します。

次のセクションでは、各レイヤーを、対応する監視ポイントと推奨アクションとともに詳細に説明します。

0x4.3.1 価格サイド監視

1. オラクルフィードの失敗

メトリック：

• オンチェーンの観測可能な値を使用して、フィードが停止しているかどうかを判断します。

しきい値：

• レベル1：（∆t > 5秒）— リレ​​ープロセスが停止またはブロックされている可能性があります。
• レベル2：（∆t > 15秒）— オンチェーン価格は深刻な価格乖離を起こし、ますます市場駆動型になる可能性があります。

アクション：

• レベル1：リレ​​ーのヘルスチェックを実行し、バックアップリレ​​ーに切り替え、ヘルス診断付きのアラートを発行します。
• レベル2：setOpenInterestCapsを呼び出してOIキャップを削減します。

2. 価格乖離

メトリック：

• シグナルA（d1）：マーク価格とオラクル価格の間の偏差。

• シグナルB（d2）：注文板の中間価格とオラクル価格の間の偏差。

• シグナルC（d3）：マーク価格と中間価格の間の偏差。

• シグナルD（ext_diff）：オラクル価格と外部参照価格の間の偏差。

しきい値ロジック：

• レベル1：A、B、Dのうち少なくとも2つがしきい値を超えている。
• レベル2：X秒間、A、B、C、Dのうち少なくとも3つがしきい値を超えている。

アクション：

• レベル1：setOpenInterestCapsを介してOIキャップを削減します。
• レベル2：証拠金テーブルを段階的に更新して最大レバレッジをティアごとに削減し、リレ​​ーにクランプメカニズムを有効にします。
• レベル3：レベル2の条件下で持続的なアラート。次に、ビルダーはhaltTradingを呼び出すかどうかを評価します。

0x4.3.2 注文板サイド監視

1. 流動性引き出し

メトリック：

• depth_band(±x%)：中間価格の±x%以内の注文板の流動性。
• spread = bestAsk - bestBid：スプレッドの広がりを測定するための価格スプレッド。
• aggressiveVolume_Δt：Δt内のテーカーボリューム（取引サイドで集計）。
• impact_ratio：市場の脆弱性を示す指標（値が高いほど、価格インパクトの脆弱性が大きくなることを示します）。

リスクパターン：

• depth_bandが減少し、spreadとimpact_ratioが増加する。

アクション：

• レベル1：setOpenInterestCapsを呼び出してOI cap = current OIを設定し、増分ポジションを制限します。
• レベル2：setMarginTableIdsを介してレバレッジを強制的に解消し、高レバレッジ、高リスクポジションを清算します。

2. 偽造された流動性

リスクパターン：

• 短い時間枠内でのdepth_bandの突然のスパイクとその後の崩壊。

アクション：

• レベル1：setOpenInterestCapsを呼び出してOI cap = current OIを設定します。
• レベル2：深刻な価格乖離と組み合わされている場合、市場の停止を検討します。

0x4.3.3 ポジションサイド監視

ポジションサイド監視は、価格の方向を予測しようとしません。代わりに、バランスの取れた取引活動から片側ポジションの蓄積への移行を特定します。OIが急激に増加し、ポジションが高度に集中し、多数側の損益が極端に達すると、たとえ軽微な外部ショックであっても、連鎖的な清算やADLイベントを引き起こす可能性があります。

そのため、ポジションサイドのアクションは通常、価格サイドおよび注文板サイドの介入よりも優先度が低いです。

1. 過剰な短期OI

メトリック：

• OI_notional：未決済建玉額面。
• Volume_24h_notional：24時間額面取引量。

急速に増加する比率は、アクティブな回転から投機的なポジション構築へのシフトを示しており、しばしば急激なボラティリティの前兆となります。

アクション：

• レベル1：しきい値を超えた場合にアラートをトリガーします。

2. 多数側損益

多数側とは、観測ウィンドウ内のポジション保有者が多い側（ロングまたはショート）を指します。

メトリック：

• avgEntry_major：多数側ポジションの平均エントリー価格。
• size_major：多数側の合計ポジションサイズ。
• equity_major：多数側の合計株式資本。

多数側損益とその比率は次のように定義されます。

アクション：

• レベル1：しきい値侵害時にアラートを発します。
• レベル2：それが持続する場合、setOpenInterestCapsを呼び出してOIキャップを削減することを検討します。

0x5 結論

HIP-3のコアストーリーは簡単です。市場リスティングを少数の人間によって制御される裁量的なプロセスから、要件が満たされた場合に任意の適格ビルダーが呼び出すことができるプロトコルレベルの機能に変換します。ステークすることにより、ビルダーはHyperCore上に独自のパーペチュアルDEXをローンチし、初期セットの市場を無料でリストし、オークションを通じて追加のスロットを取得できます。これにより、市場拡大は承認を待つことから、ルールベースの、許可不要なスケーリングへと移行します。

同様に明確なのは、HIP-3がリスクを排除するわけではないということです。それはリスクを再配置し、再形成します。プラットフォームレベルのリスク制御によって以前に吸収されていた責任は、現在、主にビルダーからの入力と運用品質を通じてビルダーが負担します。これには、setOracleを介したオラクル価格設定と更新間隔、markPxの選択と制約、証拠金テーブルによる段階的なレバレッジ設計、非24時間年中無休資産の市場時間外価格設定範囲、および損失を封じ込めたり増幅したりできるhaltTradingなどの強力な制御が含まれます。薄い流動性下では、誤設定や運用上の失敗は、清算の連鎖、ギャップ損失、そして最終的にはADLイベントに増幅される可能性があります。問いはもはや***「市場をリストできるか？」ではなく、「リスト後に安定を維持できるか？」***です。

プロトコルレベルでは、Hyperliquidは、許可を説明責任のある許可に変換することによって、このリスクの再配分に対処します。ステークとバリデーターによって管理されるスラッシングを組み合わせることで、ビルダーの誤運用に対する明確な経済的結果が確立されます。価格設定とレバレッジの制約（クランプ、更新間隔、ボラティリティ制限、分離証拠金要件を含む）は、最も危険なテールリスクを管理可能な範囲内に保つことを目的としています。このフレームワークでは、HIP-3の価値提案が明確になります。オープンネスによるスケーリング、制約による安全性、検証可能性と説明責任による長期的な持続可能性です。

HIP-3はリスティングをより自由にしません。それはそれらをより標準化され、展開可能で、運用可能で、スラッシュ可能にします。この標準化が大規模で機能するかどうかは、最終的にはオラクル設計、レバレッジおよびリスクパラメータ、およびランタイム監視の実際の品質にかかっています。HIP-3の上に市場アクセスルール、パラメータテンプレート、アラートシステム、または緊急ワークフローを設計している場合、または監査および継続的なセキュリティサポートが必要な場合は、BlockSec（[email protected]）までお気軽にお問い合わせください。

参照

[1] https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-improvement-proposals-hips/hip-3-builder-deployed-perpetuals

[2] https://hyperliquid.gitbook.io/hyperliquid-docs

BlockSecについて

BlockSecは、フルスタックのブロックチェーンセキュリティおよび暗号コンプライアンスプロバイダーです。当社は、顧客がコード監査（スマートコントラクト、ブロックチェーン、ウォレットを含む）、リアルタイムでの攻撃傍受、インシデント分析、不正資金の追跡、およびAML/CFT義務の遵守を、プロトコルおよびプラットフォームのライフサイクル全体にわたって支援する製品とサービスを構築しています。

BlockSecは、著名な会議で複数のブロックチェーンセキュリティ論文を発表し、DeFiアプリケーションのいくつかのゼロデイ攻撃を報告し、複数のハッキングを阻止して2000万ドル以上を救済し、数十億ドルの暗号通貨を確保しています。

• 公式ウェブサイト：https://blocksec.com/

• 公式Twitterアカウント：https://twitter.com/BlockSecTeam

• 🔗 BlockSec監査サービス : リクエストを送信

• 🔗 Phalcon Security APP: デモを予約

• 🔗 Phalcon Compliance