HIP-3（Hyperliquid改善提案3）がメインネット上で公開されてから約3ヶ月が経ちました。ローンチ以来、サードパーティのカスタムマーケットプレイスの累計取引量は130億米ドルを超えています。これは、「新規商品の上場」が取引所の内部プロセスから、外部開発者が直接呼び出せるインフラ機能へと変化しつつあることを意味します。

中央集権型取引所において、「新規商品の上場」は本質的にプラットフォームの権限です。どの資産が取引可能か、いつ上場されるか、そしてそのパラメータがどのように設定されるかは、基本的に運用とリスク管理プロセスによって決定されます。オンチェーンの永久契約のようにインフラに大きく依存するカテゴリーでさえ、少数のチームによる展開とガバナンスのペースによって制約を受けることがよくあります。

HIP-3の革新性は、プロセスを「プラットフォーム承認」から「オープンインターフェース」へと移行したことにあります。条件が満たされれば、第三者は同一の取引・決済プラットフォーム上に新たな永久契約市場を展開することができ、新規契約の上場に関する集中管理の権限をエコシステムに体系的にアウトソーシングすることができます。この改善はイノベーションの障壁を下げるだけでなく、市場の拡張性も向上させます。しかしながら、オープンインターフェースがもたらす潜在的なセキュリティリスクも無視できません。これらの市場のコンプライアンス遵守と悪意ある行為の排除は、HIP-3の設計において依然として厳密な検証を必要とする重要な課題です。

0x1 ハイパーリキッド: HIP-3のベース

Hyperliquidは、独自のブロックチェーン上で稼働する永続的な取引インフラです。HIP-3の最も重要な点は、マッチング、クリアリング、決済がプロトコル基盤によって統一的に提供されるため、取引システムをゼロから構築するのではなく、市場機能を再利用できることです。

Hyperliquid は 2 層アーキテクチャを採用しています。

HyperCore: 契約取引用に最適化されたカスタマイズされた L1 ブロックチェーン。確定的なファイナリティで 1 秒あたり 200,000 件の注文を処理できます。

HyperEVM: スマート コントラクトを実行し、EVM と互換性のあるアプリケーション層。

Hyperliquid のネイティブ perp マーケットプレイス (バリデーター運営 perp) は、上場に関して従来の中央集権型取引所 (CEX) のプロセスに似ています。公式プラットフォームはコミュニティの希望に基づいて永久契約を上場しますが、上場廃止はバリデーターノードによる投票によって決定されます。

Hyperliquid プロトコルは、perp リスト プロセスの完全な分散化に向けた重要なマイルストーンである、ビルダー デプロイ型 perp (HIP-3) をサポートします。

Hyperliquid プロトコルは、ビルダーによって展開される永久契約 (HIP-3) をサポートします。これは、完全に分散化された永久契約上場プロセスを実現するための重要なマイルストーンです。

0x2 HIP-3: 開発者向けデプロイメントマーケットプレイス

HIP-3のコンセプトはシンプルです。Hyperliquid取引・決済プラットフォームを変更することなく、資格を持つビルダーに「永続的な市場の追加」を可能にすることです。ビルダーは市場の主要なパラメータと価格フィード／運用責任を定義する責任を負い、プロトコルは統合された証拠金・決済エンジンを使用して執行とリスク管理の境界を管理します。これにより、「新しい市場の追加」はプラットフォームプロセスから呼び出し可能な標準インターフェースへと進化します。

つまり、ビルダーは HyperCore エンジンに基づいて永久契約市場をリストし、価格を入力し、市場パラメータを自分で調整することができます。

建設業者の責任の範囲

HIP-3 では、ビルダーはパープ市場に対して、市場の定義と市場の運営という 2 種類のタスクを実行します。

市場の定義:

公式ドキュメントでは、これをOracleの定義と契約仕様としてまとめています。運用レベルでは、少なくとも以下の内容が含まれます。

Oracle の定義:

これには、初期のoraclePxと価格ソースの定義が含まれます。市場を定義する際には、ビルダーは明確に定義され、操作が困難で、経済的実体を持つターゲット資産またはデータソースを定義する必要があります。資産を登録する際には、初期のoraclePxを提供する必要があります。

契約仕様:

API インターフェースで、「資産シンボル/最小注文単位/最大レバレッジ」などの市場パラメータ (coin、szDecimals、maxLeverage など) を明示的に定義します。

DEX選択:

ビルダーはまず、パーペチュアルDEX（各DEXは独立した証拠金、注文板、およびデプロイヤーの設定を持つ）を展開し、DEXの担保として任意の上場資産（USDCなど）を選択できます。各パーペチュアル市場は1つのDEXに対応します。

市場運営：

公式リストには、オラクル価格の設定、レバレッジ制限、必要に応じて市場設定などが含まれています。詳細は以下の通りです。

価格フィードを更新:

市場における Oracle 価格は、setOracle インターフェイスを通じて継続的に提供されます。

レバレッジ制限:

最大レバレッジは、対応するマージン テーブルを資産に割り当てることによって制限されます。レバレッジ制限はポジション サイズに応じて段階的に設定され、利用可能なレバレッジが事前設定された範囲に制限されます。

必要に応じて決済を行います。

ビルダーは haltTrading インターフェースを使用して市場を停止し、決済をトリガーできます。つまり、すべての注文をキャンセルし、現在のマーク価格でポジションを決済します。同じアクションを使用して取引を再開することもできます。

現在、HIP-3 マーケットは個別のポジションのみをサポートしていますが、将来的にはクロス ポジションもサポートされる可能性があります。

市場投入プロセス

ステーク

メインネットでは、ビルダーが 50 万 HYPE のステークを維持することが求められます。また、ビルダーが DEX 上の市場を閉鎖した場合でも、ステーキング要件は 30 日間維持する必要があります。

建てる

ステーキングのしきい値に達すると、ビルダーはPerp DEXをデプロイできます。各Perp DEXは独立した取引ドメインであり、独立した証拠金、注文板、デプロイヤー設定を備えています。

担保を設定する

この DEX の担保は任意の引用資産にすることができますが、引用資産が許可なしの引用資産ステータス (バリデータ投票によって決定) を失った場合、それを担保として使用する perp DEX は無効になります。

市場を追加

最初の 3 つの市場は直接展開できます。

新たな市場を追加する場合には、ダッチオークションを通じて「新たな割当」を取得する必要があります。

5. 市場を運営する

市場が立ち上がると、構築者の仕事は「市場を安定させること」、つまり市場運営になります。

6. ステーク解除

DEX上のすべての市場が決済されると、ステークされた50万HYPEがアンロックされます。アンステークを開始すると、7日間のアンステーキングキューに入ります。この期間中、ステークされたHYPEはステーキングペナルティの対象となる可能性があります。

ダッチオークション: 現在のサイクルは 1 ラウンドあたり 31 時間で、各入札の開始価格は前回の最終価格の 2 倍 (販売価格 / 最低価格) になります。

SetOracle: 3種類の価格入力

HyperCore では、オラクル価格は主に資金調達手数料のアンカーと計算に使用され、マーク価格はマージンコールや清算などのリスク管理シナリオのマーク価格として機能します (TP/SL などをトリガーするためにも使用されます)。

ネイティブ市場では、マーク価格は単一の価格フィードから直接得られるものではなく、計算された 3 つの価格の中央値です。

oraclePx + EMA(midPx - oraclePx)

中央値（最良入札価格、最良売り価格、最終取引価格）（ローカル注文板価格）

複数のCEXからのパープミッド価格の加重中央値

HIP-3 では、Oracle 価格とマーク価格の機能は変更されていませんが、計算メカニズムが変更されました。

setOracle入力

a. OraclePx（必須）

コア定義は HyperCore と一致しています。

b. markPx（オプション）

候補値を計算するために、実際のマーク価格として 0 ～ 2 セットの外部マーク価格を送信できます。

c. externalPerpPx（必須）

これはマーク価格の参照値入力として機能し、マーク価格の急激な変動を防ぎます。

ビルダーは価格フィードのためにレイヤーノードを展開することが多いが、OraclePx

リレイヤーは、包括的な計算のために外部価格ソースを組み合わせます。markPx は、リレイヤーによってカスタム アルゴリズムを使用して計算されます。externalPerpPx は、複数の CEX からの perp mid 価格の加重中央値です。

2. 実際のマーク価格

HIP-3 のマーク価格は、setOracle からの価格フィードを直接使用しません。

ローカルマークを計算します: 中央値(最良入札、最良売り、最終取引)。

ローカルマークと markPx (グループ 0～2) を組み合わせて中央値を取得し、新しいマーク価格を取得します。

3. Oracleの制限を設定する

更新頻度：2回の呼び出しの間には少なくとも2.5秒の間隔が必要です。markPxが10秒以内に更新されない場合、ローカルマーク価格に戻ります。

範囲制限: markPx の変動は毎回 ±1% を超えることはありません。すべての価格は、1 日の開始値の 10 倍以内に制限されます。

7x24Hと非7x24H：料金体系の違い

HIP-3では、無期限契約市場はあらゆる資産の上場をサポートします。資産は、7x24H資産（24時間取引可能）と非7x24H資産（特定の取引時間のみ取引可能。スポット市場は取引時間外には取引できません）に分類されます。これら2種類の資産の取引時間の特性によって、価格取得方法に違いが生じます。

24時間365日取引される資産（BTCなど）の場合、CEX/DEXまたは信頼できるオラクルの組み合わせから安定した価格を得ることができます。

24時間365日取引されない資産（株式など）の場合、十分な流動性と比較的安定した外部市場の相場は取引時間中にのみ利用可能です。HIP-3において、このような資産の24時間正常な取引を維持するためには、市場が閉まっている時間帯には異なる価格設定メカニズムを使用する必要があります。

trade.xyz の株式永久契約市場を例に挙げます。

株式市場の取引時間中は、Pyth などの外部 Oracle サービスによって安定した価格フィードが提供されます。

株式市場が閉まっている間は、株価は前日の終値に基づいて調整され、内部的な売買圧力が考慮されます。マーク価格は、前日の終値変動の1/max_leverage（最大レバレッジ）に制限されます（例：テスラは10倍→10%）。

清算

HIP-3 マーケットは主に HyperCore の清算ロジックを再利用するため、清算トリガー ロジックはプラットフォームに従います。つまり、分離されたポジション値が維持証拠金要件を満たすのに不十分な場合、清算状態になります。

清算に関する判断は、特定の取引の価格ではなく、マーク価格に基づいて行われます。

清算価格の計算式:

サイド = 1 (長い)、-1 (短い)

l: つまり、維持証拠金率

MAINTENANCE_LEVERAGE の値は、このポジションに対応する証拠金層から取得されます。まず、この層から維持証拠金率 (mmr) が読み取られます。

階層がある場合、ポジションの名目価値がどの階層に該当するかに基づいて、清算価格に対応するポジションの MMR が使用されます。

利用可能な余白

分離: 分離マージン - メンテナンスマージンが必要

システムが清算状態に入ると、注文板を通じた成行注文によるポジション決済を優先します。リスクを安全な範囲に戻すことができれば、残りの証拠金はトレーダーに帰属します。

ただし、十分な深さやギャップがない場合、実際の平均終値はマーク価格よりも大幅に低くなり、「清算ギャップ」が形成される可能性があります。

分離ポジション値: 現在のマーク価格での分離ポジションの純価値 (ポジションの利益または損失からポジションに結び付けられたマージンを差し引いたもの) を指します。

日常生活動作:

この場合、ADL (自動デレバレッジ) メカニズムを極端な状況でのフォールバックとして使用できます。

孤立ポジションの価値がマイナスになると、ADL（Advanced Position Limitation）が発動します。反対ポジションは未実現損益とレバレッジに基づいてソートされ、強制的に前回のマーク価格で縮小／決済されます。反対ポジションの利益はギャップを埋めるために使用され、システムが不良債権を被らないようにします。

ソート基準は次の基準に従って計算されます。

前回のマーク価格: ADL がトリガーされる前にシステムによって記録された前回のマーク価格を指します。

例：

ADL が発動する前、システムのマーク価格は 3,000 でした。

setOracle の制約により、新しいマーク価格は最大 2,970 (-1%) までしか更新できません。

しかし、この時点では注文板上の買い注文は非常に少なかった。成行注文が出された後の実際の平均取引価格は2,910（3,000に対して3%減）だった。

ロングポジションの損失は 2,910 で決済され、これによりポジションの孤立したポジション値が 0 を下回る (ギャップが発生) 可能性があり、その結果、適応制限 (ADL) がトリガーされます。

次に、ADL は反対側のポジション (利益の出るショートポジション) を選択し、以前のマーク価格 3,000 で強制的にポジションを減らして決済することで、そのギャップを「利益の出る側が受動的に利益を減らす」方向に転嫁します。

0x3 リスク概要: 説明責任の制約と主要なリスク

スラッシング：個人に責任を負わせるための認可された手段

HIP-3 は「新製品の追加および運用の権利」をビルダーに委任する一方で、一連の強制可能なステーキング ルールを通じてプロトコルに責任を定めています。ビルダーは HYPE をステーキングする必要があり、不適切に運用されていると判断された場合、バリデーターはステーキングとステーキングのバーンを投票で決定できます。

誓約条件

メインネットでは、ビルダーが 50 万 HYPE のステークを維持することが求められており、ビルダーがすべての市場活動を一時停止した場合でも、このステークを 30 日間維持し続けなければなりません (取引の停止によって責任が直ちに免除されるわけではありません)。

トリガーと投票

悪意のある市場操作が行われた場合、バリデーターはステーク加重投票を開始および実行し、ビルダーのステークを削減するかどうかを決定できます。

判断原則

公式声明では、罰金や没収は「悪意/能力不足/秘密鍵の盗難」などの理由を区別せず、ビルダーの行為が無効な状態、長時間のダウンタイム、パフォーマンスの低下をもたらしたかどうかに焦点を当てると明言しています。

罰金および没収の範囲

ペナルティのパーセンテージはバリデーターの投票によって決定され、基準上限は次のとおりです。

無効な状態または長時間のダウンタイムを引き起こす: 最大 100%

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

パフォーマンスの低下: 最大20%

没収されたステークトークンは、影響を受けたユーザーに補償されるのではなく、破棄されます。

パラメータ設定のリスク

Oracle を設定する

オラクルの価格は通常、ビルダーのリレーサーバーから算出されますが、これは中央集権化のリスクを伴います。秘密鍵が漏洩したり、DDoS攻撃が発生したりした場合、市場におけるオラクルの価格が悪意を持って操作されたり、長期間にわたって変動したりする可能性があります。

取引停止

ビルダーは、haltTrading を介して市場内のすべての注文をキャンセルし、現在のマーク価格で決済することができます。

この操作は、次のシナリオなどでは注意して使用する必要があります。

攻撃者によって市場が悪意を持って操作されていることが検出されると、haltTrading が呼び出され、マーク価格でポジションが直接クローズされます。これにより、攻撃者の未実現利益が直接実現され (攻撃者は当初十分な相手方の注文を見つけるのが困難だった可能性があります)、不良債権が発生する可能性があります。

setMarginTableIds/InsertMarginTable

InsertMarginTable: 特定の資産クラスの証拠金要件と最大レバレッジを指定する新しい証拠金テーブルを定義します。

setMarginTableIds: 指定された marginTableId にマーケットをバインドします。

流動性が低い市場やマーケットメイク能力が不十分な市場では、最大レバレッジを高く設定しすぎると、ADL が発動される可能性が高くなります。

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

マージンモードの設定

現在、HIP-3では分離マージンのみが許可されていますが、将来的にはクロスマージンがサポートされる可能性があります。単一のDEXには高流動性市場と低流動性市場の両方が含まれる場合があり、クロスマージンによって低流動性リスクが高流動性市場に伝播する可能性があります。したがって、成熟した公式ソリューションが提供されるまで、ビルダーによるクロスマージン導入は推奨されません。

オラクルのリスク

24 時間 365 日稼働する資産の場合、主なリスクは、依存する外部 Oracle サービスの精度と安定性、および前述のリレー サーバーに関連する集中化されたリスクにあります。

24 時間 365 日取引されない資産の場合、資産の非取引時間中にオラクル価格を取得または計算すると、より大きなリスクが生じます。

trade.xyzを例に挙げると、取引時間外は、直近の外部オラクル価格と内部市場価格の組み合わせを使用して価格が計算されます。週末には、パーペチュアル株式市場の流動性は低下し（注文板が薄くなり、マーケットメーカーが提示価格を下げる）、価格を固定する外部オラクル価格が存在しません。価格変動にハードキャップ（1/max_leverage）を設けたとしても、この制限は低ボラティリティ資産にとっては依然として高すぎます。この範囲内での価格変動は、依然として広範な清算や売掛金（ADL）につながる可能性があります。

2025年12月14日、trade.xyz上のXYZ100-USDC（NASDAQ100にペッグ）が攻撃者によって操作されました。攻撃者は398 XYZ100（約1,000万USDC）のショートポジションを作成し、価格の大幅な乖離を引き起こしました。多数のロングポジションが清算され、その清算によって価格は下落を続け、最終的に約1,300万USDC相当のロングポジションが清算されました。

https://x.com/bartdothl/status/2000292798755684839

一方、取引時間外には、継続的かつアンカー可能な安定したオラクル価格が不足しており、市場は多くの場合「最後の外部価格 + 内部注文板」に依存して限られた内部価格帯を形成しなければなりません（たとえば、trade.xyz は最大変動範囲を 1/max_leverage に制限します）。

リスクは、再開時の切り替えポイントで発生します。外部市場は即座に明確な外部価格を提供します。市場閉鎖時に、外部価格と内部価格に大きな乖離がある場合、システムはクランプ状態を継続し、外部価格と取引可能な価格の間に大きな乖離が生じるか、外部アンカーへの切り替え時に急速な価格改定が発生します。どちらの場合も、短期間に集中的な清算圧力を引き起こし、極端な場合にはADLイベントの増加につながる可能性があります。

0x4 リスク管理戦略

1) 安定したオラクル価格

株式のように24時間365日取引できない資産の場合、主な課題は市場が閉まっている間の価格設定にあります。安定した外部相場がないため、市場は操作されたり、低水準で変動したりしやすくなります。

現在、業界で一般的なソリューションは主に次の 2 つのカテゴリに分類されます。

これにより、オラクル価格の更新が直接停止され、その期間中の取引が停止または制限される可能性があります（例えば、Lighterプロトコルでは、市場が閉鎖されている間のみポジションの削減が許可されます）。Optiumのようなプロトコルでは、市場が閉鎖されている間、最大レバレッジを引き下げ、制限を超えたポジションを強制的に清算することもあります。

これは trade.xyz に似た「内部価格設定」メカニズムを採用しており、外部データが不足している場合でも、プロトコル内の市場流動性とアルゴリズムに依存して動作を維持します。

これら2つのアプローチは、プロトコル設計におけるセキュリティとユーザーエクスペリエンスのトレードオフを明確に反映しています。前者はより厳格なリスク管理メカニズムを採用していますが、ユーザーの取引エクスペリエンスを大幅に犠牲にしています。後者は取引の継続性を維持しますが、外部参照がないため、内部価格と原資産の実際の価値の間に乖離が生じやすい可能性があります。

市場閉鎖時には、交渉価格が「純粋な内部価格」へと完全に堕落してしまうことを避けることが重要です。代わりに、デカップリングや価格差のリスクを軽減するために、参照可能な外部アンカーを導入する必要があります。参照可能なアンカーとしては、以下のようなものが挙げられます。

ブルーオーシャンATS

時間外/夜間取引に関連する取引の場として、市場閉鎖期間中に、ある程度の継続的な価格参照（「最終終値」よりもタイムリー）を提供することができ、市場閉鎖オラクル価格の生成に役立てたり、価格分離の監視ベンチマークとして使用できます。

IG週末CFD相場

週末の CFD 相場は、「週末の市場予想」に対する代替価格シグナルを提供できるため、市場閉鎖時の外部アンカーまたは監視基準として適しており、「潜在的なオープニングギャップ」の方向と規模を事前に特定するのに役立ちます。

これら2つの情報源はどちらも「市場閉鎖時に価格シグナルを提供する」という特徴を共有していますが、原資産となる株式スポット価格と同じ市場構造ではありません。無条件の代替としてではなく、アンカー／比較指標やリスク警告シグナルとしての利用に適しています。

2) 価格検証

HIP-3のオラクル価格は、ビルダーが設置したリレーサーバーから発信されますが、中央集権的な紛争の影響を受ける可能性があります。そのため、ビルダーは、あらゆるユーザーや機関がオフチェーンで価格の真正性と公平性を検証できる価格検証メカニズムを構築することが推奨されます（RedStoneのように、価格値とそのデータソース、署名証明をブロックチェーンにパッケージ化するメカニズムに類似）。

公開データ

アルゴリズム仕様: 詳細なアルゴリズムとプロセスメカニズムを公開する

データ ソース リスト: 各データ ソースはパブリックであり、ビルダーによる介入の対象ではなく、詳細なインターフェースとパラメーターを公開する必要があります。

価格プッシュ仕様: Oracle 呼び出し権限、トリガー頻度、および変動制限。

b. 価格証明

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

入力: この時点での各データ ソースの生の応答 (または正規化されたフィールド) とサンプリング タイムスタンプ。

計算: 計算可能な中間量、各計算ステップの中間結果。

出力: 今回ブロックチェーンに記録されたオラクル価格。

Proof は、proofHash を取得するためにシリアル化され、oracleUpdater によって proofHash に署名されます。

c. チェーン上の証明

リストを維持し、各 ProofHash を Merkle ツリーに時系列順に書き込みます。

MerkleRoot は一定の間隔 (例: 1 時間ごと/毎日) で公開され、ブロックチェーンにアップロードされます。

d. 検証

対応する期間または特定の SETOracle 操作の tx ハッシュを入力して上記のすべてのデータを取得できるオープンソース ツールまたは Web ページを提供します。

署名、タイムスタンプ、MerkleRoot などを検証します。

公開されているアルゴリズムを使用して計算された Oracle の価格を比較します。

3) リスク監視

価格検証により、setOracleプロセスは「再計算および監査可能」となり、価格フィードの信頼性を確保します。しかし、市場の制御不能なスパイラルを防ぐことはできません。価格フィードの中断、価格の乖離、そして板情報の低下は、大きな建玉（OI）と相まって、局所的な異常が容易に連鎖清算やADL（代替制限）といったシステミックリスクへとエスカレートする可能性があります。したがって、市場の異常は可能な限り早期に観測可能なシグナルとして認識し、リスクを制御可能なレベルに戻す機会を捉えてトリガーする必要があります。

1. 価格面

a. Oracle価格フィードの障害

監視指標:

オンチェーンのオブザーバブルを使用して、価格フィードが直接ブロックされているかどうかを判断します。

閾値グレーディング:

アクション：

レベル 1: レイヤーのヘルス チェックを実行し、バックアップ レイヤー ノードに切り替えて、すべてのレイヤー ノードのヘルス レポートと情報を含むアラートを発行します。

レベル 2: setOpenInterestCaps を呼び出して OI 上限を下げます。

b. 価格のデアンカー

監視指標:

しきい値：

レベル 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%の範囲内の実際の注文量。

スプレッド = bestAsk - bestBid: 価格差。注文帳が「壊れている」かどうかを測定するために使用されます。

aggressiveVolume_Δt: Δt 内のテイカー取引量（取引側ごとに集計）。

impact_ratio = aggressiveVolume_Δt / depth_band: ベアリング比

判断：以下の組み合わせパターンが出現するとリスクが増大します。

depth_band は減少し、それに伴って spread と impact_ratio が増加します。

アクション：

レベル 1: `setOpenInterestCaps` を呼び出して、現在の OI によって OI 上限を下げ、ポジション サイズの増加を制限します。

レベル 2: `setMarginTableIds` を呼び出すと、レバレッジが強制的に削減され、高レバレッジのポジションが作成されなくなり、一部の高レバレッジ、高リスクのポジションが強制的にクローズされます。

b. 偽の注文

モニター：

depth_band は一時的に上昇し、その後突然低下します。

アクション：

レベル1: setOpenInterestCapsを呼び出してOI上限を下げる = 現在のOI

レベル 2: 深刻な価格乖離が伴う場合は、市場の停止を検討します。

3. ポジション側

ポジションサイドのモニタリングの目的は、「方向性を予測する」ことではなく、市場が取引主導型からポジションベースの投機へと移行しているかどうかを特定することです。建玉（OI）が急速に蓄積し、ポジションが高度に集中し、大多数の損益が極端な値に近づいている場合、外生的な価格変動は清算ウォーターフォール/ADL（Advanced Liquidation Drought）へと増幅される可能性が高くなります。したがって、ポジションサイドのアクションは、一般的に価格サイドやオーダーブックサイドのアクションよりも優先順位が低くなります。

a. 短期的なOI（オンライン識別）の過度な重視

モニター：

OI_notional: 未決済残高

Volume_24h_notional: 24時間取引量

OI_notional / Volume_24h_notionalを計算します。この比率の急激な上昇は、市場が短期保有から長期投機へと移行していることを示しており、通常、急激な市場変動の前兆となります。

アクション：

レベル 1: 上限に達したときにアラートをトリガーします。

b. 過半数の利益と損失

モニター：

多数派側: 統計ウィンドウ内で、保有者が多い側 (ロングまたはショート)。

avgEntry_major: ほとんどのポジションの平均開始価格

size_major: 多数決ポジションのサイズ

過半数の損益：

過半数の利益/損失比率:

アクション：

レベル 1: 上限に達したときにアラートをトリガーします。

レベル 2: 上限が継続的にトリガーされる場合は、`setOpenInterestCaps` を呼び出して OI 上限を下げることを検討してください。

0x5 結論

HIP-3の核となるのは、「新製品のアップデート」プロセスを、少数の人間が意思決定を行うプロセスから、一定の基準を満たせば誰でもアクセスできるプロトコル機能へと変革することです。ビルダーは、ステーキングによってHyperCore上に独自のパープDEXを立ち上げ、まずは少数の市場を無料で立ち上げ、その後オークションを通じてより多くのスロットを獲得することで、市場拡大を「承認待ち」から「ルールに従って拡大」へと変革することができます。

しかし、HIP-3はリスクを根絶したのではなく、その位置と形態を書き換えただけであることも明らかです。以前はプラットフォームリスク管理の対象だったものが、今ではビルダーの入力と運用品質に大きく依存するようになりました。例えば、`setOracle`の価格フィードと頻度、`markPx`の選択と制約、証拠金テーブルの段階的レバレッジ、24時間年中無休ではない資産市場の閉鎖価格設定のための「内部レンジ」、そして損失を阻止することも増幅することもできる`haltTrading`の威力などです。これらの領域におけるいかなる誤操作も、市場の厚みが薄い中での集中的な清算へと拡大し、ギャップやADLをさらに引き起こす可能性があります。もはや問題は「実行可能か？」ではなく、「実行後も安定して稼働できるか？」です。

プロトコルレベルでこの「リスクアウトソーシング」に対処するための核心は、権限を説明責任のある権限へと転換することです。ステーキングとバリデータ投票によるペナルティは、ビルダーの「運用上の不正行為」に明確なコスト境界を与えます。同時に、価格とレバレッジの制約（クランプ、更新間隔、ボラティリティキャップ、分離マージン）は、最も危険なテールシナリオを制御可能な範囲内に収めようとします。したがって、HIP-3の真の命題は、拡張性はオープン性、セキュリティは制約、そして長期的な持続可能性は検証可能性と説明責任に依存するということになります。

HIP-3は、新規導入の柔軟性を高めるのではなく、導入、運用、そしてアカウンタビリティの向上といった点で、より標準化された環境を実現します。しかしながら、標準化が真に円滑に進むためには、Oracle/レバレッジ/リスク管理パラメータとランタイム監視の実装品質が不可欠です。HIP-3に基づいて市場アクセス、パラメータテンプレート、アラート、緊急対応プロセスを設計している場合、あるいは監査や継続的なセキュリティサポートが必要な場合は、BlockSecまでお問い合わせください。