HIP-3深掘り：ビルダー中心の視点

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

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

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

0x0 背景

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

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

実行と清算はプロトコルレベルで一律に強制されるため、新しい市場は、重要な安全ロジックを再実装することなく、同じコアインフラストラクチャを再利用できます。しかし、価格設定は完全に標準化できるわけではありません。オラクル入力、レバレッジ設計、ランタイム運用は市場ごとに必然的に異なるため、価格設定は分散化とリスクが出会う主要なインターフェースとなっています。

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

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

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

HIP-3の下では、ビルダーは市場ライフサイクルの管理に対するエンドツーエンドの責任を負います。このセクションでは、まず市場ローンチワークフローを説明し、次に本番環境での市場の安定性を最も直接的に決定する運用レバーに焦点を当てます。

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

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

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

ダッチオークション：各ラウンドは31時間続き、各回の開始価格は前の最終価格（最後の勝利価格/最低価格）の2倍です。

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

実際には、HIP-3の下でのほとんどの深刻な障害は、市場定義中ではなく、ストレスのかかった市場状況下での長期運用中に発生します。重要なのは、ビルダーの責任は市場を停止した後すぐに終了するわけではないということです。すべての市場が決済されるまで、ステーク解除は可能ではなく、必須のステーク解除期間中はステークはスラッシュ可能のままです。

0x1.2 重要な焦点分野：価格設定とソルベンシー

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

1. オラクル設定と価格形成

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

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

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

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

a) setOracleへの入力

oraclePx（必須）：HyperCoreでの定義と同じ。
markPx（オプション）：0〜2の外部計算マーク価格候補。
externalPerpPx（必須）：マーク価格の突然の逸脱を防ぐための参照値。

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

b) 実際のマーク価格

ローカルマークを計算：median(best bid, best ask, last trade)。
ローカルマークとmarkPx（0〜2値）を組み合わせて中央値を取得して新しいマーク価格にします。

c) setOracleの制約

更新頻度：呼び出し間隔は少なくとも2.5秒。markPxが10秒間更新されない場合、ローカルマーク価格にフォールバックします。
振幅制限：markPxは更新ごとに最大±1％しか変更できません。すべての価格は、終値の10倍以内にクランプされます。

HIP-3での価格設定に資産タイプが重要な理由

HIP-3の下では、あらゆる種類の資産に対して永久先物市場をローンチできます。これらの資産は、一般に24/7資産（常時取引可能）と非24/7資産（特定の市場時間のみ取引可能で、それ以外の時間帯はスポット取引なし）に分類できます。取引時間の違いは、価格の調達方法と維持方法を根本的に決定します。

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

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

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

市場時間中、Pythなどの外部オラクルサービスによって安定したオラクル価格が提供されます。
市場時間外、価格は資産の最終終値と、オーダーブックからの内部の売買圧力に基づいて調整されます。マーク価格は、最終終値の**±1 / max_leverage**の範囲で変動するように制限されます（例：テスラ：10倍レバレッジ→±10％）。

2. ストレス下での市場ソルベンシー

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

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

a) 清算

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

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

ここで：

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

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

証拠金ティアが設定されている場合、清算価格におけるポジションの名目値に対応するティアのmmrを適用します。

margin_available（分離）：isolated_margin - maintenance_margin_required

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

ただし、オーダーブックの深さが不十分な場合や価格ギャップがある場合、実際の平均実行価格はマーク価格よりも著しく悪くなる可能性があり、**「清算ショートフォール」**が発生します。

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

b) 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で強制的に削減/クローズし、ショートフォールを**「勝者の受動的な収益の減少」**にシフトします。

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

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

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

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

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

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

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

不正な状態/長時間のダウンタイム：最大100％

短時間のダウンタイム：最大50％

パフォーマンス低下：最大20％

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

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

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

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

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

1. setOracle

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

2. haltTrading

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

3. setMarginTableIds & InsertMarginTable

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

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

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

4. setMarginModes

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

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

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

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

trade.xyzを例にとると、市場時間外には、最終利用可能な外部オラクル価格と内部市場価格の組み合わせから価格が導き出されます。週末には、株式の永久先物市場はしばしば流動性が大幅に低下し、オーダーブックが薄くなり、マーケットメーカーの提示価格が縮小しますが、市場時間外に価格を固定するための外部オラクル価格は利用できません。価格変動にハードキャップが課せられていても（例：1 / max_leverage）、この制限は低ボラティリティ資産にとっては緩すぎる可能性があります。この範囲内の価格変動でも、大規模な清算やADLイベントを引き起こす可能性があります。

2025年12月14日、trade.xyzのXYZ100-USDC市場（NASDAQ-100を追跡する永久先物契約）が操作されました。攻撃者は398 XYZ100（名目エクスポージャーで約1,000万USDC）をショートし、深刻な価格の乖離を引き起こしました。多数のロングポジションが清算され、清算自体がさらに価格を下落させ、最終的にロングサイドの清算で約1,300万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イベントの急増につながる可能性があります。

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

設定規律だけではリスクを排除できません。最も効果的な軽減戦略は、オラクル依存障害へのエクスポージャーを減らすことに焦点を当てています。

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

非24/7取引資産（株式など）の場合、主な課題は市場時間外の価格設定にあります。この期間中、安定した外部に固定された価格参照はほとんどなく、市場は操作や薄い流動性下での内因性のドリフトの影響を受けやすくなります。

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

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

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

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

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

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

0x3.2 価格検証

HIP-3の下では、オラクル価格はビルダー運用リレーヤーサーバーから調達されますが、これは中央集権化に関する懸念を引き起こします。これを軽減するために、ビルダーは、RedStoneが価格をデータソースと暗号証明とともにパッケージ化するのと同様に、任意のユーザーまたは機関がオフチェーンで価格設定の正確性と公平性を検証できる価格検証フレームワークを実装することが推奨されます。

1. データ透明性

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

2. 価格証明

各setOracle呼び出しについて、以下の内容を含む対応する証明を生成します。

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

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

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

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

4. 検証

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

0x3.3 リスク監視

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

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

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

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

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

1. 価格サイド監視

a) オラクルフィード障害

メトリクス：

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

しきい値：

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

アクション：

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

b) 価格の乖離

メトリクス：

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

シグナルB（d2）：オーダーブック中間価格とオラクル価格の間の偏差。

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

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

しきい値ロジック：

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

アクション：

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

2. オーダーブックサイド監視

a) 流動性の引き出し

メトリクス：

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を介してレバレッジを強制的に解除し、高レバレッジ、高リスクポジションを清算します。

b) 偽の流動性

リスクパターン：

短期間でのdepth_bandの突然のスパイクとその後の崩壊。

アクション：

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

3. ポジションサイド監視

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

その結果、ポジションサイドのアクションは通常、価格サイドおよびオーダーブックサイドの介入よりも優先度が低いです。

a) 過剰な短期OI

メトリクス：

OI_notional：未決済建玉の名目値。
Volume_24h_notional：24時間名目取引量。

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

アクション：

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

b) 多数側損益

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

メトリクス：

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

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

アクション：

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

0x4 結論

HIP-3のコアストーリーは単純です。市場上場を少数の人物が管理する裁量的なプロセスから、要件を満たせば資格のあるビルダーが誰でも呼び出すことができるプロトコルレベルの機能へと変革します。ステークすることにより、ビルダーはHyperCore上に独自のパーペチュアルDEXをローンチし、初期セットの市場を無料で上場し、オークションを通じて追加のスロットを取得できます。これにより、市場拡大は承認を待つことから、ルールベースのパーミッションレススケーリングへと移行します。

同様に明確なのは、HIP-3がリスクを排除するわけではないということです。それはリスクを再配置し、再形成します。プラットフォームレベルのリスク制御によって以前吸収されていた責任は、 now largely borne by builders through their inputs and operational quality。これには、setOracleを介したオラクル価格設定と更新間隔、markPxの選択と制約、証拠金テーブルを介したティア化レバレッジ設計、非24/7資産の市場時間外価格設定範囲、および損失を封じ込めたり増幅させたりできる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アプリケーションの数多くのゼロデイ攻撃を報告し、複数のハッキングを阻止して2,000万ドル以上を救済し、数十億ドルの暗号通貨を保護してきました。

公式ウェブサイト：https://blocksec.com/
公式Twitterアカウント：https://twitter.com/BlockSecTeam
🔗 BlockSec Auditing Service : リクエストを送信
🔗 Phalcon Security APP: デモを予約
🔗 Phalcon Compliance