HyperliquidはHIP-3（Hyperliquid改進提案3）を通じて永続取引市場における新たな分散型仕組みを実現しており、メインネット公開から約3ヶ月が経過しています。サードパーティの開発者は統一された取引・清算基盤上に自らの市場を展開でき、これまでに蓄積された取引量は130億ドルを突破しています。この革新は新規参入のハードルを大幅に下げる一方で、新たなセキュリティリスクも伴います。その中でも、担保維持率の管理は市場の長期的な安定運営を左右する重要な要素となっています。Builderにとって、担保の預託は単なる「参入証票」以上の意味を持ち、経済的インセンティブとリスク共有の枠組みを形成しています。担保と維持率の制約を通じて、HIP-3はオープンなイノベーションを促進しつつ、責任追及可能なリスク管理の境界を築いています。## HIP-3の担保預託メカニズムと維持率フレームワークHIP-3はHyperliquidの二層構造に基づいています：HyperCore（取引最適化されたカスタムL1チェーン、毎秒20万件の注文処理能力）とHyperEVM（EVM互換のアプリケーション層）。このアーキテクチャの最大の利点は、マッチング、清算、決済をプロトコル基盤が一元的に提供し、Builderは高性能エンジンを再利用できる点です。ゼロから構築する必要はありません。**担保預託の経済的意味合い**HIP-3において、Builderは500万HYPEトークンの担保預託を維持する必要があります。この担保には三つの側面があります：1. **参入条件**：担保預託は市場展開の前提条件であり、参加者の経済的投入を保証します2. **リスク共有**：市場運営の不適切により担保が没収されるリスクを伴い、Builderとユーザーの利益を結びつけます3. **維持率制約**：担保規模は、Builderが展開可能な市場数とリスク負担の規模を直接決定します**維持率との直接的な関係**担保維持率（Maintenance Margin Ratio）は、担保規模と密接に関連しています。Builderの担保は、その市場の「リスクバッファ資本」に相当します。市場に異常事態（価格のデペンディング、流動性の枯渇、清算ギャップなど）が発生した場合、この担保は最終的な責任追及と補償の源泉となります。検証者はstake-weighted vote（担保の重み付け投票）により、Builderの担保没収の是非を決定します。没収の条件は以下の通り：- 市場の無効化や長時間のダウンタイムを引き起こした場合：最大100%の担保没収- 一時的なダウンやパフォーマンス低下：最大20%-50%- プライベートキーの盗難による価格操作：同様に没収リスクを負うこの設計は本質的に、運営責任と経済的利益を直接結びつけるものであり、担保維持率が高いほどリスクバッファは厚くなるが、リスクが発生した場合の損失も大きくなることを意味します。**担保ロック期間**Builderが展開したすべての市場を停止した場合でも、担保の解除申請には30日間の維持が必要です。これは、リスク責任が取引停止だけで即座に解除されないことを意味します。市場停止期間中に新たなセキュリティ問題やユーザーの争議が発生した場合、担保は凍結または没収される可能性があります。## 市場運営におけるパラメータ設定と維持率制約市場が展開されると、Builderはパラメータ設定を通じて市場の安定性を維持します。これらのパラメータは、清算のトリガー条件やリスク規模に直接影響し、担保維持率の実質的なプレッシャーを左右します。**オラクルと価格形成メカニズム**BuilderはsetOracleインターフェースを用いて、以下の三種類の価格を継続的に入力します：- oraclePx（必須）：資産の基準価格、資金料の計算に使用- markPx（任意）：外部のmark price（0-2組）- externalPerpPx（必須）：複数のCEX永続契約の加重中央値、脱錨防止の参考値システムが最終的に使用するmark priceは、ローカルの注文簿価格とBuilderが提出したmarkPxの中央値です。価格操作を防ぐために、以下の二つのハード制約を設けています：- **更新頻度制限**：2回の呼び出し間隔は最低2.5秒、10秒間未更新の場合は自動的にローカルmarkにフォールバック- **変動幅制限**：markPxの変動は±1%以内に制限され、すべての価格は当日の始値の10倍範囲内にクランプこれらの制約は、Builderの担保を保護するために設計されており、操作の余地を制限し、没収リスクを低減します。**レバレッジと証拠金表の設定**Builderはmargin table（証拠金表）を定義し、市場の最大レバレッジを制約します。証拠金表は通常、ポジション規模に応じて階層化され、各階層には異なる維持証拠金要件（maintenance margin requirement）が設定されます。流動性の低い市場では、過剰なレバレッジ上限設定はADL（自動的なレバレッジ削減）の発動確率を高めます。例えば、日次取引高が1000万ドルの市場に20倍のレバレッジを設定した場合、OI（未決済建玉）が臨界点に達すると、価格変動により短時間で清算が集中し、ギャップやADLが発生しやすくなります。Builderが突然marginTableIdを切り替えると、同時にすべてのユーザーポジションの維持証拠金比率が変更され、多数のアカウントが安全状態から清算可能状態に変わるリスクがあります。これにより連鎖的な清算が引き起こされ、システム的なリスクが高まります。大規模な清算が発生すると、Builderの担保は重度の罰没リスクにさらされます。**市場停止と強制決済**BuilderはhaltTrading権限を持ち、市場の取引停止やすべての注文のキャンセル、現在のmark priceに基づく強制決済を行えます。この権限はリスク管理のためのツールですが、不適切な使用は損失を拡大させる可能性があります。極端なケース：攻撃者が大量の空売りポジションを作成し、価格を操作した場合、BuilderがhaltTradingを呼び出すと、mark priceで決済され、攻撃者の浮動益を直ちに確定させることになります。流動性不足のために対抗注文を見つけられなかった攻撃者は、Builderの決済操作により強制的に約定し、最終的にシステムの負債となるケースです。この種の事象は、Builderの担保が没収される原因となり、検証者の投票により市場の無効化とユーザ損失が認定されることになります。## オラクルリスクと担保維持率の関係オラクルはHIP-3市場の価格形成の生命線です。Builderは独立したリレーヤーノードを運用し、価格情報を供給しますが、複数のリスクポイントがあります。**24時間取引資産と非24時間資産の価格差**BTCなどの24時間取引資産は、CEXやDEXから連続的で安定した外部価格を取得可能です。Builderのオラクルは、複数の信頼できるソースを集約し、重複排除や異常値除去を行います。一方、株式などの非24時間資産は、状況が複雑です。株式市場の開場中は、Pythなどの外部オラクルを利用できますが、市場休止期間（夜間、週末）には流動性が消失し、Builderは特殊な価格形成メカニズムを採用します。具体的には、前回の終値と内部注文簿の圧力を基にしたアルゴリズムで価格を決定し、mark priceは前回終値の±10%の範囲内に制限されます（例：10倍レバレッジなら±10%）。この「内部価格設定」のリスクは、市場再開時に外部現物価格と内部価格の大きなギャップが生じることです。例えば、週末のCFD市場での価格が前週金曜日の終値から8%上昇していた場合でも、HIP-3のmark priceは±10%の制限内にとどまり、再開時に外部価格と乖離が生じる可能性があります。これにより、大規模な再価格調整と連鎖的清算が引き起こされるリスクがあります。こうした事象は、Builderの担保に圧力をかけ、休場期間中の価格形成メカニズムの信頼性に疑問を投げかけることになります。**オラクル中継の中央集権リスク**Builderが運用するリレーヤーサーバーがDDoS攻撃や秘密鍵漏洩に遭うと、市場の価格情報が悪意的に操作されたり長期間脱錨したりする可能性があります。これが判明した場合、Builderの担保は即座に没収リスクにさらされます。## リアルタイム監視と動的調整戦略HIP-3の設計には、Builderに一定のパラメータ設定の裁量権が与えられていますが、システムは動的調整ツールも提供しています。これらのツールの理解と適切な運用は、担保の安全性維持に不可欠です。**価格側の監視**1. **オラクル喂価の失効**：リレーヤーのブロックやsetOracle呼び出し間隔が10秒超過した場合、システムは自動的にローカルmarkにフォールバックします。この場合、直ちに予備のリレーヤーに切り替え、健全性レポートを検証者に送付します。中断が続く場合は、setOpenInterestCapsを用いてOI上限を引き下げ、脱錨期間中の新規ポジション拡大を防ぎます。2. **価格脱錨**：mark priceと複数のCEX perp中間価格の乖離を監視し、閾値超過時に段階的な対応を行います： - レベル1警告：乖離≥3%、OI上限を引き下げ - レベル2警告：乖離≥5%かつ30秒以上継続、max leverageを段階的に引き下げ、clampを有効化 - レベル3警告：高水準の乖離が継続した場合、市場停止を検討**板側の監視**1. **深度抽離**：特定価格帯（±3%）内の実際の注文量、スプレッド、アクティブな約定量を監視し、受け皿比（taker volume /深度帯の注文量）を計算。深度の低下とスプレッド・受け皿比の上昇はリスク上昇を示すため、setOpenInterestCapsで新規ポジション規模を制限します。2. **虚偽注文**：短時間で深度帯の急激な増減パターンを検出し、虚偽流動性の疑いがあれば即座にOI上限を凍結します。**ポジション側の監視**未決済建玉（OI）と24時間取引高の比率を監視し、急激な上昇は市場の短期取引から長期ポジションへの偏りを示唆します。これにより、価格の外生的な動きが清算の連鎖を引き起こしやすくなるため、レバレッジ調整やOI上限の引き下げを検討します。また、多数派の損益状況も監視し、偏ったポジションの反転による大規模逆清算リスクを把握します。これらの監視信号は、Builderの意思決定（レバレッジ調整、OI上限変更、リスクモードの有効化）に反映され、誤った判断は担保没収リスクを高めることになります。## 担保維持率計算ツール：リスク管理の実践的応用これらのリスク管理体系を踏まえ、Builderはリアルタイムで担保維持率の圧力を計算・監視できるツールを必要とします。**計算ツールの主要機能**1. **安全性評価**：現在の担保規模、展開市場数、各市場のOI規模、清算確率を入力し、最悪シナリオ下での担保没収規模を算出2. **リスクレベルの階層化**：市場の現状（価格安定性、深度充足度、OIと取引高の比）に基づき、リスクレベルを自動判定し、「担保消耗速度」の予測を提示3. **パラメータ推奨**：市場特性に応じて、最適なmax leverage、証拠金階層、OI上限とそれに伴う担保圧力を提案4. **複数市場の総合評価**：複数展開している場合、全体の担保リスクを評価し、最も危険な市場を特定5. **シナリオストレステスト**：価格脱錨5%、流動性断裂、ADL発生などの極端事象をシミュレートし、最悪時の損失規模を予測**実運用例**- **市場展開前**：計算ツールを用いてリスクレベルを評価し、初期パラメータと担保充足度を決定- **運用中**：リアルタイムで担保圧力指標を監視し、リスク兆候を早期に察知し、パラメータ調整- **危機時**：迅速なストレステストを行い、市場停止やレバレッジ引き下げ、運用停止を判断- **事後分析**：担保没収の妥当性やリスク管理の改善点を抽出し、次回に活かす## まとめ：責任追及可能な枠組みと拡張性HIP-3は、オープンなインターフェースを通じて、「新規展開」を少数の判断から条件を満たすだけで呼び出せる仕組みに変えました。これにより、第三者の市場は130億ドル超の取引量を達成していますが、その一方で、従来のプラットフォーム一括リスク管理から、Builderの入力と運用の質に依存する仕組みに移行しています。担保と維持率の枠組みは、HIP-3がこの「リスク外注」の防衛策として機能しています。Builderは担保預託を通じて「市場を安定させる自信」を示し、検証者は没収権を行使して「安定させられなかった責任」を追及します。これらの仕組みの成功は、以下にかかっています：1. **Builderの入力の質**：信頼できるオラクル、適切なパラメータ設定、効果的なリスク監視2. **プロトコルの枠組み**：担保没収権の明確化、価格変動制約、リスク監視体制の整備3. **ツールとシステムの支援**：担保維持率計算器などのリスク管理ツールによる迅速な意思決定支援長期的な安全性は、Builderがこれらのベストプラクティスを実践に落とし込み、理論だけでなく実運用に反映させることにかかっています。
HIP-3ステーキング維持率ガイド：パラメータ設定からリスク管理実行まで
HyperliquidはHIP-3（Hyperliquid改進提案3）を通じて永続取引市場における新たな分散型仕組みを実現しており、メインネット公開から約3ヶ月が経過しています。サードパーティの開発者は統一された取引・清算基盤上に自らの市場を展開でき、これまでに蓄積された取引量は130億ドルを突破しています。この革新は新規参入のハードルを大幅に下げる一方で、新たなセキュリティリスクも伴います。その中でも、担保維持率の管理は市場の長期的な安定運営を左右する重要な要素となっています。
Builderにとって、担保の預託は単なる「参入証票」以上の意味を持ち、経済的インセンティブとリスク共有の枠組みを形成しています。担保と維持率の制約を通じて、HIP-3はオープンなイノベーションを促進しつつ、責任追及可能なリスク管理の境界を築いています。
HIP-3の担保預託メカニズムと維持率フレームワーク
HIP-3はHyperliquidの二層構造に基づいています：HyperCore（取引最適化されたカスタムL1チェーン、毎秒20万件の注文処理能力）とHyperEVM（EVM互換のアプリケーション層）。このアーキテクチャの最大の利点は、マッチング、清算、決済をプロトコル基盤が一元的に提供し、Builderは高性能エンジンを再利用できる点です。ゼロから構築する必要はありません。
担保預託の経済的意味合い
HIP-3において、Builderは500万HYPEトークンの担保預託を維持する必要があります。この担保には三つの側面があります：
維持率との直接的な関係
担保維持率（Maintenance Margin Ratio）は、担保規模と密接に関連しています。Builderの担保は、その市場の「リスクバッファ資本」に相当します。市場に異常事態（価格のデペンディング、流動性の枯渇、清算ギャップなど）が発生した場合、この担保は最終的な責任追及と補償の源泉となります。
検証者はstake-weighted vote（担保の重み付け投票）により、Builderの担保没収の是非を決定します。没収の条件は以下の通り：
この設計は本質的に、運営責任と経済的利益を直接結びつけるものであり、担保維持率が高いほどリスクバッファは厚くなるが、リスクが発生した場合の損失も大きくなることを意味します。
担保ロック期間
Builderが展開したすべての市場を停止した場合でも、担保の解除申請には30日間の維持が必要です。これは、リスク責任が取引停止だけで即座に解除されないことを意味します。市場停止期間中に新たなセキュリティ問題やユーザーの争議が発生した場合、担保は凍結または没収される可能性があります。
市場運営におけるパラメータ設定と維持率制約
市場が展開されると、Builderはパラメータ設定を通じて市場の安定性を維持します。これらのパラメータは、清算のトリガー条件やリスク規模に直接影響し、担保維持率の実質的なプレッシャーを左右します。
オラクルと価格形成メカニズム
BuilderはsetOracleインターフェースを用いて、以下の三種類の価格を継続的に入力します：
システムが最終的に使用するmark priceは、ローカルの注文簿価格とBuilderが提出したmarkPxの中央値です。価格操作を防ぐために、以下の二つのハード制約を設けています：
これらの制約は、Builderの担保を保護するために設計されており、操作の余地を制限し、没収リスクを低減します。
レバレッジと証拠金表の設定
Builderはmargin table（証拠金表）を定義し、市場の最大レバレッジを制約します。証拠金表は通常、ポジション規模に応じて階層化され、各階層には異なる維持証拠金要件（maintenance margin requirement）が設定されます。
流動性の低い市場では、過剰なレバレッジ上限設定はADL（自動的なレバレッジ削減）の発動確率を高めます。例えば、日次取引高が1000万ドルの市場に20倍のレバレッジを設定した場合、OI（未決済建玉）が臨界点に達すると、価格変動により短時間で清算が集中し、ギャップやADLが発生しやすくなります。
Builderが突然marginTableIdを切り替えると、同時にすべてのユーザーポジションの維持証拠金比率が変更され、多数のアカウントが安全状態から清算可能状態に変わるリスクがあります。これにより連鎖的な清算が引き起こされ、システム的なリスクが高まります。大規模な清算が発生すると、Builderの担保は重度の罰没リスクにさらされます。
市場停止と強制決済
BuilderはhaltTrading権限を持ち、市場の取引停止やすべての注文のキャンセル、現在のmark priceに基づく強制決済を行えます。この権限はリスク管理のためのツールですが、不適切な使用は損失を拡大させる可能性があります。
極端なケース：攻撃者が大量の空売りポジションを作成し、価格を操作した場合、BuilderがhaltTradingを呼び出すと、mark priceで決済され、攻撃者の浮動益を直ちに確定させることになります。流動性不足のために対抗注文を見つけられなかった攻撃者は、Builderの決済操作により強制的に約定し、最終的にシステムの負債となるケースです。
この種の事象は、Builderの担保が没収される原因となり、検証者の投票により市場の無効化とユーザ損失が認定されることになります。
オラクルリスクと担保維持率の関係
オラクルはHIP-3市場の価格形成の生命線です。Builderは独立したリレーヤーノードを運用し、価格情報を供給しますが、複数のリスクポイントがあります。
24時間取引資産と非24時間資産の価格差
BTCなどの24時間取引資産は、CEXやDEXから連続的で安定した外部価格を取得可能です。Builderのオラクルは、複数の信頼できるソースを集約し、重複排除や異常値除去を行います。
一方、株式などの非24時間資産は、状況が複雑です。株式市場の開場中は、Pythなどの外部オラクルを利用できますが、市場休止期間（夜間、週末）には流動性が消失し、Builderは特殊な価格形成メカニズムを採用します。具体的には、前回の終値と内部注文簿の圧力を基にしたアルゴリズムで価格を決定し、mark priceは前回終値の±10%の範囲内に制限されます（例：10倍レバレッジなら±10%）。
この「内部価格設定」のリスクは、市場再開時に外部現物価格と内部価格の大きなギャップが生じることです。例えば、週末のCFD市場での価格が前週金曜日の終値から8%上昇していた場合でも、HIP-3のmark priceは±10%の制限内にとどまり、再開時に外部価格と乖離が生じる可能性があります。これにより、大規模な再価格調整と連鎖的清算が引き起こされるリスクがあります。
こうした事象は、Builderの担保に圧力をかけ、休場期間中の価格形成メカニズムの信頼性に疑問を投げかけることになります。
オラクル中継の中央集権リスク
Builderが運用するリレーヤーサーバーがDDoS攻撃や秘密鍵漏洩に遭うと、市場の価格情報が悪意的に操作されたり長期間脱錨したりする可能性があります。これが判明した場合、Builderの担保は即座に没収リスクにさらされます。
リアルタイム監視と動的調整戦略
HIP-3の設計には、Builderに一定のパラメータ設定の裁量権が与えられていますが、システムは動的調整ツールも提供しています。これらのツールの理解と適切な運用は、担保の安全性維持に不可欠です。
価格側の監視
オラクル喂価の失効：リレーヤーのブロックやsetOracle呼び出し間隔が10秒超過した場合、システムは自動的にローカルmarkにフォールバックします。この場合、直ちに予備のリレーヤーに切り替え、健全性レポートを検証者に送付します。中断が続く場合は、setOpenInterestCapsを用いてOI上限を引き下げ、脱錨期間中の新規ポジション拡大を防ぎます。
価格脱錨：mark priceと複数のCEX perp中間価格の乖離を監視し、閾値超過時に段階的な対応を行います：
板側の監視
深度抽離：特定価格帯（±3%）内の実際の注文量、スプレッド、アクティブな約定量を監視し、受け皿比（taker volume /深度帯の注文量）を計算。深度の低下とスプレッド・受け皿比の上昇はリスク上昇を示すため、setOpenInterestCapsで新規ポジション規模を制限します。
虚偽注文：短時間で深度帯の急激な増減パターンを検出し、虚偽流動性の疑いがあれば即座にOI上限を凍結します。
ポジション側の監視
未決済建玉（OI）と24時間取引高の比率を監視し、急激な上昇は市場の短期取引から長期ポジションへの偏りを示唆します。これにより、価格の外生的な動きが清算の連鎖を引き起こしやすくなるため、レバレッジ調整やOI上限の引き下げを検討します。また、多数派の損益状況も監視し、偏ったポジションの反転による大規模逆清算リスクを把握します。
これらの監視信号は、Builderの意思決定（レバレッジ調整、OI上限変更、リスクモードの有効化）に反映され、誤った判断は担保没収リスクを高めることになります。
担保維持率計算ツール：リスク管理の実践的応用
これらのリスク管理体系を踏まえ、Builderはリアルタイムで担保維持率の圧力を計算・監視できるツールを必要とします。
計算ツールの主要機能
実運用例
まとめ：責任追及可能な枠組みと拡張性
HIP-3は、オープンなインターフェースを通じて、「新規展開」を少数の判断から条件を満たすだけで呼び出せる仕組みに変えました。これにより、第三者の市場は130億ドル超の取引量を達成していますが、その一方で、従来のプラットフォーム一括リスク管理から、Builderの入力と運用の質に依存する仕組みに移行しています。
担保と維持率の枠組みは、HIP-3がこの「リスク外注」の防衛策として機能しています。Builderは担保預託を通じて「市場を安定させる自信」を示し、検証者は没収権を行使して「安定させられなかった責任」を追及します。これらの仕組みの成功は、以下にかかっています：
長期的な安全性は、Builderがこれらのベストプラクティスを実践に落とし込み、理論だけでなく実運用に反映させることにかかっています。