HyperliquidがHIP-3を導入してから、永続契約市場の成立方法は根本的に変わりました。市場上場を中央集権的な承認プロセスの背後に隠すのではなく、プロトコルは資格を持つビルダーにアクセスを開放しました—しかし、この自由には落とし穴もあります：ビルダーは運用リスクを所有することになるのです。この責任の礎は、しばしば過小評価される単一の決定、すなわち「オラクル定義」から始まります。メインネット開始から3か月以上経ち、HIP-3上に展開されたビルダー運営の市場はすでに$13 十億ドルを超える取引高を蓄積しています。この規模は偶然に起きたものではありません。これはプロトコルの革新と、その複雑さを成功裏に乗り越えたビルダーたちの努力の結果です。しかし、成功した市場の裏には警鐘となる事例もあります—例えば2025年12月のtrade.xyz事件では、攻撃者が弱いオラクル定義を突いて、24時間稼働しない資産の価格操作を行い、$13 百万ドルのロングポジションを流出させました。このガイドでは、繁栄する市場と破綻し液化カスケードやADLトリガーに陥る市場を分けるアーキテクチャ、リスク、そして実証済みのコントロール戦略について解説します。## Hyperliquidのインフラ構造の理解：オラクル定義の基盤Hyperliquidはビルダーに「車輪の再発明」を求めません。二層構造のインフラを提供します。**HyperCore**：永続取引に最適化されたカスタムLayer 1ブロックチェーンで、1秒あたり20万件の注文を処理し、決定的な確定性を持ちます。マッチング、清算、決済はすべてプロトコルレベルで行われるため、ビルダーは取引エンジンをゼロから構築する必要はありません。**HyperEVM**：スマートコントラクトを実行するアプリケーション層で、既存のEthereumツールと互換性があります。これらのインフラ層を再利用することで、ビルダーは本当に重要な部分—市場定義と運用の規律—に集中できます。ネイティブのHyperliquid永続マーケットプレイスは従来のCEX上場プロセスに従います—バリデーターがどのコントラクトを含めるか投票します。しかしHIP-3はこのモデルを逆転させます：閾値を満たすビルダーなら誰でもローンチ可能です。HIP-3の下でローンチするには、50万HYPEトークンをステーキングする必要があります。最初の3つの市場は無料で展開でき、それ以降はダッチオークションシステム(31時間サイクル)で入札します。前ラウンドの最終価格の2倍から開始します。ステーキングは30日間継続し、市場を一時停止しても解除されません—これは任意の保険ではなく、あなたの責任メカニズムです。## ビルダーとしての役割：二つの責任HIP-3はビルダーの作業を二つのフェーズに分けます：市場定義と市場運用。**市場定義**は最初から正しく設定することです。以下を指定します。1. **オラクル定義**：どのデータソースを価格の基準とするか？最初のオラクル価格(oraclePx)は何か？株式永続の場合はPythか？流動性の低いアルトコインならCEXの価格フィードか？この決定は、トレーダーがポジションを持つと不可逆です。2. **コントラクト仕様**：シンボル、最小注文サイズ、最大レバレッジ、担保資産(USDC)など、レバレッジ制限とポジションサイズを結びつけるマージンターブル。**市場運用**は継続的な警戒です。- **価格フィード**：setOracleを繰り返し呼び出し、オラクル価格を提出します。呼び出し間隔は最低2.5秒。もし(optional)のマーク価格が10秒以内に更新されない場合、システムはローカルの注文板価格にリバートします。- **レバレッジ調整**：マージンターブルを市場にバインドし、名目ポジションサイズに基づき段階的にレバレッジ制限を設定します。- **緊急制御**：haltTradingを呼び出して市場を凍結し、すべての注文をキャンセルし、現在のマーク価格でポジションを決済します。プロトコルはガードレールを設けています—マーク価格は更新ごとに±1%を超えられず、すべての価格は日始値の10倍以内に収まる必要があります。ただし、これらの制約は拘束具ではありません。これらの範囲内での選択が、市場の繁栄か崩壊かを決めるのです。## オラクル定義：市場安定性のための重要な決定点オラクル定義は、市場の運命を左右します。最初に設定し、修正は最も難しい部分です。その理由は以下の通りです。### オラクル定義の実態HIP-3におけるオラクル定義は三層構造です。1. **oraclePx (必須)**：価格の主要なアンカー。通常はリレーヤサーバーから取得し、外部フィードを集約します(Pyth、DEXのAMM、CEXの価格)。これがクラッシュやDDoS攻撃に対する唯一の単一点障害です。2. **MarkPx (任意)**：カスタムのマーク価格。最大2セットまで提出可能で、実際の清算基準値を計算します。独自の価格モデルを持つビルダーが輝く部分ですが、判断ミスが市場を殺すこともあります。3. **ExternalPerpPx (必須)**：複数のCEXからの中間価格の加重中央値。これは市場の広範なコンセンサスから乖離しすぎないようにするためのセーフティネットです。これらを組み合わせて最終的なマーク価格を生成します：local order bookの中央値、提出された(oraclePx)、externalPerpPxの中央値です。いずれかの層が失敗すると次の層にフォールバックし、すべて失敗すれば盲目的に取引します。### 24/7資産 vs. 非24/7資産：二つの異なるオラクル定義**24/7資産 (BTC、ETH、ほとんどのアルトコイン)**：オラクル定義はシンプルです。PythやChainlink、直接CEXのフィードが連続的で流動性の高い価格信号を提供します。リレーヤはそれらを集約します。操作はコスト高で、外部市場の誤価格を即座に検知できるため、操作は困難です。**非24/7資産 (株式、指数、コモディティ)**：オラクル定義は生死を分ける問題です。NASDAQ株式を例に取ると、市場時間中はPythがクリーンな価格を提供しますが、市場終了後は外部価格がありません。オラクル定義は真空状態で生き残る必要があります。落とし穴は、営業時間外はsetOracleが実際の市場価格を取得できないことです。したがって、「最後の終値 +内部注文板の圧力」に頼ることになります。しかし、外部アンカーがないと、内部圧力だけが鏡となり、市場の価格は内部の値だけを反映し、資産の本当の価値を反映しなくなります。プロトコルは±1レバレッジ制限を課しています(例：10倍レバレッジ→最大10%の振れ幅)。通常の時間帯の高ボラティリティ資産では妥当ですが、週末の流動性の低い株式や外部価格がゼロの状態では、10%の振れ幅でポートフォリオ全体が清算され、ADLカスケードを引き起こす可能性があります。## 清算とADL：オラクル定義がカスケードリスクに与える影響ポジションを持った後、オラクル定義はトレーダーのマージンコールのタイミングを決定します。### 清算トリガー清算は、ポジションの価値が維持証拠金要件を下回ったときに発生します。判定には(計算されたマーク価格)を使用し、取引価格は関係ありません。数式は以下の通りです。**清算価格 = (名目値 × marginRequirement) / ポジションサイズ**維持証拠金要件は段階的で、レバレッジが高いほど証拠金は厳しくなり、早期に清算されやすくなります。マージンターブルはこれらの段階を市場にバインドしているため、低流動性市場で不合理に高いレバレッジを設定すると、清算が集中します。### 清算がADLになるとき最も恐ろしいのは、清算注文が買い手を見つけられなくなるときです。例えば、あなたのマーク価格が$3,000(オラクル定義から計算されているが、実際の注文板の深さが薄い場合、清算注文は$2,910で執行される—3%のギャップです。このギャップが大きすぎて、清算損失が証拠金を超えると、「不良債務」が発生します。システムは不良債務を許容しません。**ADL )Auto-Deleveraging(**をトリガーします：利益のある逆側のポジションは、前のマーク価格)$3,000(で強制的にクローズされ、現在の市場価格ではありません。利益は差額を埋めるために奪い取られ、損失は勝者に移転します。ビルダーの観点から、ADLは感染の警告です。各ADLイベントは、市場がストレス状態にあることを示しています—オラクル定義が壊れているか、レバレッジ設定が浅い注文板に過剰なリスクを招いているかのいずれかです。## 重要パラメータ：市場のオラクル定義とレバレッジの設定setOracleの実装は、調整ダイヤルのようなものです。誤ると連鎖的に影響します。) オラクルの更新頻度とルール少なくとも10秒ごとにsetOracleを呼び出す必要があります。そうしないと、システムはローカルの注文板価格にリバートします###フィードが良好な場合でも(。多くのビルダーは、ボラティリティの高い期間中は2〜5秒ごとに更新します。ただし、ポイントはこれです：setOracleの呼び出しごとに、マーク価格は最大±1%しか動かせません。実際の市場状況が1秒で5%動くことも珍しくありません)例：低時価総額アルトコインやブラックスワンイベント(。この場合、オラクル定義は必然的に古くなります。清算者は古い価格を見て市場を叩きます。) 非24/7資産のオラクル定義：週末の問題株式や伝統的資産は週末に取引しません。HIP-3上の株式永続契約を計画しているビルダーは、土曜日の朝に取引所が開いていないとき、どうオラクル価格を定義しますか？現状のアプローチ：**アプローチ1：保守的**—営業時間外は取引や清算を停止します。Lighter protocolやOptiumはこれを採用。トレーダーは24/7アクセスできませんが、市場は安定します。**アプローチ2：内部価格**—「最後の外部価格 +内部注文板」を使って運用を維持します。trade.xyzは2025年12月の事件前にこれを試みました。アプローチ2は、オラクル定義の重大な弱点を露呈します：±1/maxLeverageの価格下限がリスクの上限となるのです。週末の低流動性株式で、10%の価格変動が少数の大口注文で起きる可能性があります。オラクル定義はこれを防ぐ必要がありますが、ガードレールは十分に厳しくありません。より良い非24/7資産のオラクル定義は、補助的なアンカーを取り入れることです。- **Blue Ocean ATS**：アフターアワーの株価を提供。通常取引時間ほど流動性は高くありませんが、実際の市場価格です。- **IG Weekend CFDクォート**：予想される開場ギャップのシグナルを提供。最後の終値＋内部価格と併用し、オラクル定義のアンカーとして機能させます。これらの補助は、厳密なオラクル設計の代替ではなく、補強です。あなたのオラクル定義は次のようにすべきです：「市場時間中はPyth。営業時間外は、最後のPyth終値にBlue Ocean ATSの中間値＋内部注文板の圧力を調整し、±X%にクランプする。」## オラクルリスクコントロール：価格フィードの安定性を監視するリアルタイム戦略ここで理論と運用が交差します。あなたのオラクル定義は、その監視システムの良し悪しにかかっています。### フィード障害検知リレーヤは単一点障害です。クラッシュやネットワーク喪失が起きると、setOracleは停止します。10秒以内に、システムは純粋な注文板価格にリバートします###フィードが良好な場合でも###。流動性の高い市場やスプレッドが狭い場合は耐えられますが、それ以外は清算の罠です。**アクションプラン：**- **レベル1アラート**：フィードダウン2.5秒超。リレーヤノードの状態を即座に確認し、バックアップインフラに切り替え、ステータスレポートを公開。- **レベル2アラート**：フィードダウン10秒超。setOpenInterestCapsを呼び出し、新規ポジションを凍結。既存ポジションはクローズ可能。これにより、オラクルパイプライン再構築までの連鎖的清算を防止。( フィードのデアアンカー：オラクル定義の漂流リレーヤがオンラインでも、オラクル価格は実態から乖離することがあります。原因は：- Pythフィードがわずかに遅延（混雑時に発生）- 内部注文板の中央値が流動性不足で乖離- externalPerpPxに使われるCEX価格が更新より早く動く定量的にデアアンカーを定義します：- **閾値A**：|oraclePx - externalPerpPx| > 2%- **閾値B**：|markPx - local order book mid| > 1%- **閾値C&D**：持続的な>5秒の偏差**アクションプラン：**- **レベル1**：2つ以上の閾値が超えたら、setOpenInterestCapsを呼び出し、新規ポジションの増加を制限。- **レベル2**：マージンターブルを段階的に調整し、最大レバレッジを段階的に削減。setOracleの±1%クランプを安全策として有効化。- **レベル3**：レベル2の措置を継続しつつアラートを出し続け、偏差が30秒以上続く場合は、最終手段としてhaltTradingを呼び出す。) 注文板の劣化：薄い市場の検知流動性は、オラクル定義の失敗なしに消えることもあります。次の指標を追跡：- **深さバンド (±x%)**：中央値からx%以内の注文総量。一般的には±0.5%の深さ。- **スプレッド**：bestAsk - bestBid。健全：<0.1%。危険：>1%。- **積極的な取引量**：Δt秒間のテイカー取引量。これが深さバンドを超える場合、問題の兆候。深さが急激に減少し、積極的取引量が増加したら、清算注文はスリッページに直面します。これを見て、ADLに入る前にオープンインタレストの上限を下げるべきです。## 非24/7資産：取引停止中のオラクル定義特に想定されるのは、金曜日の夜の株式永続契約です。市場は午後4時ETにクローズします。あなたのビルダー設定したオラクル定義は、週末を通じて市場を維持しなければなりません。( 2025年12月のTrade.xyz崩壊例2025年12月14日、攻撃者はこのシナリオを突いてきました。彼らはNASDAQ-100指数の永続契約)XYZ100###に大規模なショートポジションを構築。市場が流動性の低いときに攻撃を仕掛けました。攻撃の流れ：1. **営業時間外のポジショニング**：市場終了後、外部価格アンカーが乏しく、注文板も薄い中で、大量の売り圧力を作り出した。2. **オラクル定義の失敗**：内部のマーク価格(限られた内部取引＋最後の外部価格)が上昇方向に乖離し、買い手の存在しない状態に。3. **清算カスケード**：長ポジションが人工的に高い価格でマージンコールされ、市場はさらに下落。4. **ADLカスケード**：システムは利益のあるショートポジション###攻撃者を含む(を古いマーク価格で強制クローズ。ギャップが大きすぎて、ADLイベントが連鎖。根本原因は、非24/7資産のオラクル定義が緩すぎたことです。レバレッジ10倍の価格上限は硬そうに見えますが、実際には株式の通常取引で2〜3%の動きに10ポイントの余裕を持たせているに過ぎません。) 非24/7資産のためのより良いオラクル定義次の要素を含めるべきです。1. **営業時間中の主要アンカー**：Pythや取引所フィード。2. **補助的なオフ時間アンカー**：Blue Ocean ATSやIG CFDクォート。期待される開場ギャップを示す。3. **内部の健全性チェック**：内部の注文板中央値が補助アンカーから一定以上乖離したらアラートを出し、レバレッジを削減。4. **非対称リスク管理**：営業時間中は10倍レバレッジも許容。オフ時間は2〜5倍に制限し、清算カスケードのリスクを低減。## リスクダッシュボード構築：価格、深さ、ポジションの監視プロのビルダーは、次の3つの監視チャネルを同時に運用します。( チャネル1：価格側指標- setOracleの呼び出し間隔（1〜2秒ごと）- フィード遅延時間- 価格の外部ベンチマークからの乖離- クランプ違反（±1%の範囲内かどうか） ) チャネル2：注文板指標- 深さとスプレッド（5〜10秒ごと）- 深さ(±0.5%、±1%、±2%)の範囲- Bid-Askスプレッドのトレンド- アグレッシブな買い/売りの取引量深さの急激な減少と高いアグレッシブ取引量の組み合わせは、清算前兆です。$13M チャネル3：ポジション指標- オープンインタレストと集中度（毎時）- 総名目OIと24時間取引量の比率- 最大ポジションサイズの証拠金に対する割合- 多数側のロング/ショートの未実現損益と証拠金比率これらのダッシュボードは、アラートをトリガーし、対応します。高度なビルダーは自動化も行います。- フィードダウン>10秒→自動的にOI上限を50%に縮小- 深さ崩壊＋高アグレッシブ取引量→自動的にレバレッジ段階を縮小- 大多数の損益>80%→アラート発行、市場停止も検討## オラクル定義から市場安定性へ：ビルダーの責任フレームワークHIP-3はビルダーに自主性を与えました。同時に責任も。市場が不調になった場合—オラクル定義の誤り、レバレッジの乱用、監視不足—バリデーターはあなたの50万HYPEステークを削減する投票を行えます。プロトコルは悪意と無能を区別しません。結果だけを評価します：ポジションは適切にクローズされたか？オラクル価格は正しくアンカーされたか？市場は安定していたか？ビルダーの今後の道は、標準化による責任の明確化です。1. **オラクル定義を公開**：どのデータソースを使い、どの頻度で更新し、フォールバックのロジックは何かを明示。透明性は信頼を築き、問題が大きくなる前に露見させます。2. **証明システムの導入**：setOracleごとに証明（データソース入力、計算過程、出力）を生成し、署名して、1時間ごとにオンチェーンのマークルツリーにコミット。これにより、価格決定の監査性が向上します。3. **徹底的な監視**：リアルタイムダッシュボードを実装し、価格、深さ、ポジションの健全性を追跡。自動的にサーキットブレーカーを作動させ、ストレス前にOI上限やレバレッジを縮小。4. **非24/7資産の設計に注意**：株式永続契約を展開する場合は、補助的なオラクルアンカー（Blue Ocean ATS、CFDクォート）や低レバレッジ運用を採用。trade.xyzの12月崩壊から学ぶ。5. **エスカレーション手順の確立**：haltTradingの呼び出しタイミングと方法を文書化。緊急ブレーキとして適切に運用。HIP-3の革新は、展開の容易さだけでなく、標準化を促進し、アクセス、運用、責任を可能にした点にあります。市場の存続は、オラクル定義の厳格な実装、価格フィードの監視、早期警告への対応次第です。ビルダーが展開した規模は、可能性を示しています。一方、trade.xyz事件はリスクを示しています。成功の鍵は、オラクル定義を単なる技術的チェックボックスとせず、市場運営や清算ファームを決定づける根本的なコミットメントとみなすことです。セキュリティ監査、準備、リスク監視インフラの構築には、BlockSecのような専門企業の支援を検討してください。コンサル費用は、巧妙な攻撃のコストのごく一部です。
HIP-3 ビルダーガイド：なぜオラクルの定義があなたの永続市場の運命を左右するのか
HyperliquidがHIP-3を導入してから、永続契約市場の成立方法は根本的に変わりました。市場上場を中央集権的な承認プロセスの背後に隠すのではなく、プロトコルは資格を持つビルダーにアクセスを開放しました—しかし、この自由には落とし穴もあります：ビルダーは運用リスクを所有することになるのです。この責任の礎は、しばしば過小評価される単一の決定、すなわち「オラクル定義」から始まります。
メインネット開始から3か月以上経ち、HIP-3上に展開されたビルダー運営の市場はすでに$13 十億ドルを超える取引高を蓄積しています。この規模は偶然に起きたものではありません。これはプロトコルの革新と、その複雑さを成功裏に乗り越えたビルダーたちの努力の結果です。しかし、成功した市場の裏には警鐘となる事例もあります—例えば2025年12月のtrade.xyz事件では、攻撃者が弱いオラクル定義を突いて、24時間稼働しない資産の価格操作を行い、$13 百万ドルのロングポジションを流出させました。
このガイドでは、繁栄する市場と破綻し液化カスケードやADLトリガーに陥る市場を分けるアーキテクチャ、リスク、そして実証済みのコントロール戦略について解説します。
Hyperliquidのインフラ構造の理解：オラクル定義の基盤
Hyperliquidはビルダーに「車輪の再発明」を求めません。二層構造のインフラを提供します。
HyperCore：永続取引に最適化されたカスタムLayer 1ブロックチェーンで、1秒あたり20万件の注文を処理し、決定的な確定性を持ちます。マッチング、清算、決済はすべてプロトコルレベルで行われるため、ビルダーは取引エンジンをゼロから構築する必要はありません。
HyperEVM：スマートコントラクトを実行するアプリケーション層で、既存のEthereumツールと互換性があります。
これらのインフラ層を再利用することで、ビルダーは本当に重要な部分—市場定義と運用の規律—に集中できます。ネイティブのHyperliquid永続マーケットプレイスは従来のCEX上場プロセスに従います—バリデーターがどのコントラクトを含めるか投票します。しかしHIP-3はこのモデルを逆転させます：閾値を満たすビルダーなら誰でもローンチ可能です。
HIP-3の下でローンチするには、50万HYPEトークンをステーキングする必要があります。最初の3つの市場は無料で展開でき、それ以降はダッチオークションシステム(31時間サイクル)で入札します。前ラウンドの最終価格の2倍から開始します。ステーキングは30日間継続し、市場を一時停止しても解除されません—これは任意の保険ではなく、あなたの責任メカニズムです。
ビルダーとしての役割：二つの責任
HIP-3はビルダーの作業を二つのフェーズに分けます：市場定義と市場運用。
市場定義は最初から正しく設定することです。以下を指定します。
オラクル定義：どのデータソースを価格の基準とするか？最初のオラクル価格(oraclePx)は何か？株式永続の場合はPythか？流動性の低いアルトコインならCEXの価格フィードか？この決定は、トレーダーがポジションを持つと不可逆です。
コントラクト仕様：シンボル、最小注文サイズ、最大レバレッジ、担保資産(USDC)など、レバレッジ制限とポジションサイズを結びつけるマージンターブル。
市場運用は継続的な警戒です。
プロトコルはガードレールを設けています—マーク価格は更新ごとに±1%を超えられず、すべての価格は日始値の10倍以内に収まる必要があります。ただし、これらの制約は拘束具ではありません。これらの範囲内での選択が、市場の繁栄か崩壊かを決めるのです。
オラクル定義：市場安定性のための重要な決定点
オラクル定義は、市場の運命を左右します。最初に設定し、修正は最も難しい部分です。その理由は以下の通りです。
オラクル定義の実態
HIP-3におけるオラクル定義は三層構造です。
oraclePx (必須)：価格の主要なアンカー。通常はリレーヤサーバーから取得し、外部フィードを集約します(Pyth、DEXのAMM、CEXの価格)。これがクラッシュやDDoS攻撃に対する唯一の単一点障害です。
MarkPx (任意)：カスタムのマーク価格。最大2セットまで提出可能で、実際の清算基準値を計算します。独自の価格モデルを持つビルダーが輝く部分ですが、判断ミスが市場を殺すこともあります。
ExternalPerpPx (必須)：複数のCEXからの中間価格の加重中央値。これは市場の広範なコンセンサスから乖離しすぎないようにするためのセーフティネットです。
これらを組み合わせて最終的なマーク価格を生成します：local order bookの中央値、提出された(oraclePx)、externalPerpPxの中央値です。いずれかの層が失敗すると次の層にフォールバックし、すべて失敗すれば盲目的に取引します。
24/7資産 vs. 非24/7資産：二つの異なるオラクル定義
24/7資産 (BTC、ETH、ほとんどのアルトコイン)：オラクル定義はシンプルです。PythやChainlink、直接CEXのフィードが連続的で流動性の高い価格信号を提供します。リレーヤはそれらを集約します。操作はコスト高で、外部市場の誤価格を即座に検知できるため、操作は困難です。
非24/7資産 (株式、指数、コモディティ)：オラクル定義は生死を分ける問題です。NASDAQ株式を例に取ると、市場時間中はPythがクリーンな価格を提供しますが、市場終了後は外部価格がありません。オラクル定義は真空状態で生き残る必要があります。
落とし穴は、営業時間外はsetOracleが実際の市場価格を取得できないことです。したがって、「最後の終値 +内部注文板の圧力」に頼ることになります。しかし、外部アンカーがないと、内部圧力だけが鏡となり、市場の価格は内部の値だけを反映し、資産の本当の価値を反映しなくなります。
プロトコルは±1レバレッジ制限を課しています(例：10倍レバレッジ→最大10%の振れ幅)。通常の時間帯の高ボラティリティ資産では妥当ですが、週末の流動性の低い株式や外部価格がゼロの状態では、10%の振れ幅でポートフォリオ全体が清算され、ADLカスケードを引き起こす可能性があります。
清算とADL：オラクル定義がカスケードリスクに与える影響
ポジションを持った後、オラクル定義はトレーダーのマージンコールのタイミングを決定します。
清算トリガー
清算は、ポジションの価値が維持証拠金要件を下回ったときに発生します。判定には(計算されたマーク価格)を使用し、取引価格は関係ありません。数式は以下の通りです。
清算価格 = (名目値 × marginRequirement) / ポジションサイズ
維持証拠金要件は段階的で、レバレッジが高いほど証拠金は厳しくなり、早期に清算されやすくなります。マージンターブルはこれらの段階を市場にバインドしているため、低流動性市場で不合理に高いレバレッジを設定すると、清算が集中します。
清算がADLになるとき
最も恐ろしいのは、清算注文が買い手を見つけられなくなるときです。例えば、あなたのマーク価格が$3,000(オラクル定義から計算されているが、実際の注文板の深さが薄い場合、清算注文は$2,910で執行される—3%のギャップです。このギャップが大きすぎて、清算損失が証拠金を超えると、「不良債務」が発生します。
システムは不良債務を許容しません。**ADL )Auto-Deleveraging(**をトリガーします：利益のある逆側のポジションは、前のマーク価格)$3,000(で強制的にクローズされ、現在の市場価格ではありません。利益は差額を埋めるために奪い取られ、損失は勝者に移転します。
ビルダーの観点から、ADLは感染の警告です。各ADLイベントは、市場がストレス状態にあることを示しています—オラクル定義が壊れているか、レバレッジ設定が浅い注文板に過剰なリスクを招いているかのいずれかです。
重要パラメータ：市場のオラクル定義とレバレッジの設定
setOracleの実装は、調整ダイヤルのようなものです。誤ると連鎖的に影響します。
) オラクルの更新頻度とルール
少なくとも10秒ごとにsetOracleを呼び出す必要があります。そうしないと、システムはローカルの注文板価格にリバートします###フィードが良好な場合でも(。多くのビルダーは、ボラティリティの高い期間中は2〜5秒ごとに更新します。
ただし、ポイントはこれです：setOracleの呼び出しごとに、マーク価格は最大±1%しか動かせません。実際の市場状況が1秒で5%動くことも珍しくありません)例：低時価総額アルトコインやブラックスワンイベント(。この場合、オラクル定義は必然的に古くなります。清算者は古い価格を見て市場を叩きます。
) 非24/7資産のオラクル定義：週末の問題
株式や伝統的資産は週末に取引しません。HIP-3上の株式永続契約を計画しているビルダーは、土曜日の朝に取引所が開いていないとき、どうオラクル価格を定義しますか？
現状のアプローチ：
アプローチ1：保守的—営業時間外は取引や清算を停止します。Lighter protocolやOptiumはこれを採用。トレーダーは24/7アクセスできませんが、市場は安定します。
アプローチ2：内部価格—「最後の外部価格 +内部注文板」を使って運用を維持します。trade.xyzは2025年12月の事件前にこれを試みました。
アプローチ2は、オラクル定義の重大な弱点を露呈します：±1/maxLeverageの価格下限がリスクの上限となるのです。週末の低流動性株式で、10%の価格変動が少数の大口注文で起きる可能性があります。オラクル定義はこれを防ぐ必要がありますが、ガードレールは十分に厳しくありません。
より良い非24/7資産のオラクル定義は、補助的なアンカーを取り入れることです。
これらの補助は、厳密なオラクル設計の代替ではなく、補強です。あなたのオラクル定義は次のようにすべきです：「市場時間中はPyth。営業時間外は、最後のPyth終値にBlue Ocean ATSの中間値＋内部注文板の圧力を調整し、±X%にクランプする。」
オラクルリスクコントロール：価格フィードの安定性を監視するリアルタイム戦略
ここで理論と運用が交差します。あなたのオラクル定義は、その監視システムの良し悪しにかかっています。
フィード障害検知
リレーヤは単一点障害です。クラッシュやネットワーク喪失が起きると、setOracleは停止します。10秒以内に、システムは純粋な注文板価格にリバートします###フィードが良好な場合でも###。流動性の高い市場やスプレッドが狭い場合は耐えられますが、それ以外は清算の罠です。
アクションプラン：
( フィードのデアアンカー：オラクル定義の漂流
リレーヤがオンラインでも、オラクル価格は実態から乖離することがあります。原因は：
定量的にデアアンカーを定義します：
アクションプラン：
) 注文板の劣化：薄い市場の検知
流動性は、オラクル定義の失敗なしに消えることもあります。次の指標を追跡：
深さが急激に減少し、積極的取引量が増加したら、清算注文はスリッページに直面します。これを見て、ADLに入る前にオープンインタレストの上限を下げるべきです。
非24/7資産：取引停止中のオラクル定義
特に想定されるのは、金曜日の夜の株式永続契約です。市場は午後4時ETにクローズします。あなたのビルダー設定したオラクル定義は、週末を通じて市場を維持しなければなりません。
( 2025年12月のTrade.xyz崩壊例
2025年12月14日、攻撃者はこのシナリオを突いてきました。彼らはNASDAQ-100指数の永続契約)XYZ100###に大規模なショートポジションを構築。市場が流動性の低いときに攻撃を仕掛けました。
攻撃の流れ：
根本原因は、非24/7資産のオラクル定義が緩すぎたことです。レバレッジ10倍の価格上限は硬そうに見えますが、実際には株式の通常取引で2〜3%の動きに10ポイントの余裕を持たせているに過ぎません。
) 非24/7資産のためのより良いオラクル定義
次の要素を含めるべきです。
リスクダッシュボード構築：価格、深さ、ポジションの監視
プロのビルダーは、次の3つの監視チャネルを同時に運用します。
( チャネル1：価格側指標
) チャネル2：注文板指標
深さの急激な減少と高いアグレッシブ取引量の組み合わせは、清算前兆です。
$13M チャネル3：ポジション指標
これらのダッシュボードは、アラートをトリガーし、対応します。高度なビルダーは自動化も行います。
オラクル定義から市場安定性へ：ビルダーの責任フレームワーク
HIP-3はビルダーに自主性を与えました。同時に責任も。
市場が不調になった場合—オラクル定義の誤り、レバレッジの乱用、監視不足—バリデーターはあなたの50万HYPEステークを削減する投票を行えます。プロトコルは悪意と無能を区別しません。結果だけを評価します：ポジションは適切にクローズされたか？オラクル価格は正しくアンカーされたか？市場は安定していたか？
ビルダーの今後の道は、標準化による責任の明確化です。
オラクル定義を公開：どのデータソースを使い、どの頻度で更新し、フォールバックのロジックは何かを明示。透明性は信頼を築き、問題が大きくなる前に露見させます。
証明システムの導入：setOracleごとに証明（データソース入力、計算過程、出力）を生成し、署名して、1時間ごとにオンチェーンのマークルツリーにコミット。これにより、価格決定の監査性が向上します。
徹底的な監視：リアルタイムダッシュボードを実装し、価格、深さ、ポジションの健全性を追跡。自動的にサーキットブレーカーを作動させ、ストレス前にOI上限やレバレッジを縮小。
非24/7資産の設計に注意：株式永続契約を展開する場合は、補助的なオラクルアンカー（Blue Ocean ATS、CFDクォート）や低レバレッジ運用を採用。trade.xyzの12月崩壊から学ぶ。
エスカレーション手順の確立：haltTradingの呼び出しタイミングと方法を文書化。緊急ブレーキとして適切に運用。
HIP-3の革新は、展開の容易さだけでなく、標準化を促進し、アクセス、運用、責任を可能にした点にあります。市場の存続は、オラクル定義の厳格な実装、価格フィードの監視、早期警告への対応次第です。
ビルダーが展開した規模は、可能性を示しています。一方、trade.xyz事件はリスクを示しています。成功の鍵は、オラクル定義を単なる技術的チェックボックスとせず、市場運営や清算ファームを決定づける根本的なコミットメントとみなすことです。
セキュリティ監査、準備、リスク監視インフラの構築には、BlockSecのような専門企業の支援を検討してください。コンサル費用は、巧妙な攻撃のコストのごく一部です。