アーキテクチャ
Hypercallはハイブリッド実行モデルを採用しています。速度のためにマッチングはオフチェーンで行い、セキュリティのために決済とアカウント管理はオンチェーンで行います。
信頼境界
オフチェーン（Hypercallバックエンド）
責務:
- 注文のマッチングと約定
- オーダーブックの管理
- 取引前の証拠金チェック（すべてのパーペチュアル注文の前に行うポートフォリオチェックを含む）
- 清算の統括
- マーケットデータと価格算出
- WebSocketストリーム
信頼の前提: 上記のすべてについて、オペレーターを信頼することになります。信頼モデルをご覧ください。
オンチェーン（スマートコントラクト）
責務:
- アカウントの所有権とマネージャーによる管理
- 入金と出金
- RSMコマンド（リスク管理操作）
- オプショントークン（OptionRegistryおよびOptionTokenコントラクト）
- パーペチュアル注文のためのビルダー承認（ご自身のAccountから一度だけ
approveZeroFeeBuilderを実行）
信頼の前提: オンチェーンの操作はHyperliquid上に記録され、オペレーター単独では変更できません。コントラクトをアップグレードできる主体については信頼モデルをご覧ください。
注文執行フロー
1. 注文の送信
ユーザーの操作: EIP-712署名付きでPOST /orderから注文を送信します。
バックエンドでの検証:
- 署名検証（EIP-712）
- 取引前の証拠金チェック（シナリオベース）
- 注文の受付判定（ティア、満期、レート制限）
結果: 注文は受理（ACKED）されてマッチング待ちのキューに入るか、理由付きで拒否されます。
2. 注文のマッチング
プロセス: 注文はオーダーブック上で価格・時間優先によりマッチングされます。
約定: 注文がマッチすると約定が生成され、エンジンの状態でポジションが更新されます。すべての状態変更は、確認応答の前にエンジンの永続ジャーナルへ書き込まれ、データベースのテーブルはそのジャーナルから導出されます。
オンチェーンではない: 個々のオプションのマッチングはオンチェーンに記録されません。
3. ポジションの更新
プロセス: オプションのポジションと現金はエンジンの状態で管理され、リアルタイムに更新されます。パーペチュアルのポジションは、Hyperliquid上にあるお客様のアカウントのHyperCore台帳に保持されます。
ユーザーによる参照: GET /portfolioまたはWebSocketのportfolioチャネルでポジションを照会できます。
4. 決済
満期決済: オプションは満期時に、Hyperliquidオラクルから導出された決済価格に対して現金決済されます。エンジンは決済価格をジャーナルに記録し、各ポジションの本質的価値を計算し、現金残高を更新してポジションをクローズします。
原資産ごとの満期時刻、決済価格の算出方法、データが少ない場合の扱いについては、決済およびオラクルをご覧ください。
アカウント管理
アカウントの作成
プロセス: マネージャーウォレットが、少額のHYPE作成デポジットを添えてFactoryのcreateAccountを呼び出します。パーペチュアルまたはポートフォリオ証拠金を有効にすると、アプリがこれを代行します。オンボーディング（コントラクト）をご覧ください。
マネージャー: 各Accountにはマネージャー（EOA）がいます。マネージャーはAccountを管理し、注文やキャンセルに署名するAPIウォレットを承認できます。
入金と出金
入金:
- USDC: HyperEVM上でExchangeコントラクト（
depositUsdcFor）に送金され、ExchangeのHyperCore残高へブリッジされます。HyperCoreへの入金が確認された時点で、Hypercallが残高に反映します。 - オプションERC20: Exchangeコントラクト経由で入金され、トークンはバーンされてポジションとして計上されます。
出金:
- Hypercallの証拠金チェックを通過する必要があります（出金後も十分な証拠金があること）
- お客様のウォレットで署名します。通常のUSDC出金は、RSMディレクティブを通じてExchangeの残高からHyperCore上で支払われます。ポートフォリオ証拠金の出金は、マネージャーが署名したHyperCore上のAccountからの送金です。
信頼境界: 入金と出金はオンチェーンで行われ、検証可能です。
清算
アカウントの純資産が維持証拠金要件を下回ると、事前清算状態に入ります。
- リスクを増やす注文はブロックされますが、ポジションを閉じる注文は引き続き可能です。
- 清算者は証拠金を回復させるために部分清算注文を執行し、清算者ボーナスは時間とともに段階的に増加します。
- エスカレーション期間内にアカウントが回復しない場合は完全清算に移行し、Hypercallエンジンがこれを実行します。
詳細は清算をご覧ください。
Hyperliquidとの統合
パーペチュアル
Hypercallは、xyz dex上のHIP-3市場を含め、パーペチュアル注文をHyperliquidへルーティングします。すべてのパーペチュアル注文は、まずお客様のポートフォリオ証拠金アカウント全体に対してチェックされます。その後のルートは2つあります。アプリではTEEがデフォルトで、スマートコントラクトルートは詳細設定として利用できます。APIクライアントは、呼び出すエンドポイントによってルートを選択します。
スマートコントラクトルート（アプリの詳細設定）: お客様が注文に署名 → Hypercallのエンジンがポートフォリオ証拠金アカウント全体に対して注文をチェック → 注文はお客様のアカウントコントラクトを通じてオンチェーンでHyperCoreへ → Hyperliquidがマッチング
TEEルート（アプリのデフォルト、APIではオプトイン）: お客様が注文に署名 → エンジンがチェック → お客様のアカウントのHyperliquid取引キーを保持するセキュアエンクレーブ（TEE）がネイティブ注文に署名 → Hyperliquidがマッチング
エンクレーブを経由するのはTEEルートの注文のみです。これらの注文にはHypercallのビルダーアドレスが付与されるため、アカウントはビルダーを一度だけ承認します（取引を有効化）。エンクレーブは、エンジンが承認した注文、キャンセル、レバレッジ変更にのみ署名します。Hypercallのパーペチュアルをご覧ください。
ユースケース:
- オプションポジションのデルタヘッジ
- クロスマージン: パーペチュアルのポジションがポートフォリオ証拠金に算入されます
クロスマージン
HyperCoreのパーペチュアルポジションはポートフォリオ証拠金の計算に含まれ、要件はポートフォリオ証拠金の計算結果とHyperliquid自体の証拠金のうち大きい方となります。ポートフォリオ証拠金はすべてのアカウントで利用できます。ポートフォリオ証拠金へのオンボーディングをご覧ください。
RSMコマンド
RSM: エンジンの複製ステートマシンです。エンジンの状態がオンチェーンでのアクション(入金反映、出金、清算ステップ、回復注文)を必要とする場合、RSM署名者がディレクティブに署名し、Hypercallのシーケンサーがそれを送信します。オプションの満期決済はRSMディレクティブではありません。エンジンの状態で現金に対して適用されます。各ディレクティブで可能な操作はRSMディレクティブに記載しています。
検証できること
オンチェーン（検証可能）
- アカウントの所有権（マネージャーアドレス）
- 入金と出金
- Hyperliquidの注文とパーペチュアルのポジション（Hyperliquid上）
- RSMコマンド（オンチェーンでの実行）
オフチェーン（信頼が必要）
- 注文マッチングの公正性
- 証拠金の計算
- 決済価格の算出（Hyperliquidオラクルの入力値は公開されています）
- ポジション管理の正確性
- マーケットデータの正確性
- 清算発動のタイミング
信頼モデル
Mainnet Alphaはオペレーターが運用しています。注文の公正なマッチング(価格・時間優先)、正確なマーケットデータの取り込み、証拠金と決済価格の正しい算出、適時の清算発動、正しいRSMディレクティブのみの発行、インシデントへの対応について、Hypercallを信頼することになります。これらはまだ暗号学的に検証できません。オフチェーンのマッチングは、この信頼と引き換えに速度を得ています。残りはチェーンが強制します。アカウントの所有権、入金、出金はオンチェーンで行われ、Accountはマネージャー、自身のAPIウォレット、または登録されたRSM署名者が署名したディレクティブのみを実行し、コントラクトはRSMディレクティブを入金反映、出金、清算状態、制約付きの回復操作に限定しています。TEEルート(アプリのデフォルト)のパーペチュアル注文は、エンジンが承認した注文のみを受け付けるアテステーション済みのエンクレーブ内で署名されます。RSM署名者、シーケンサー、コントラクトの管理鍵とアップグレード鍵はオペレーターが管理しており、Accountの1回のアップグレードはすべてのAccountに適用されます。正確な権限、ロール、アドレスは信頼と権限に記載しています。RSM分散化のロードマップでは、ステートコミットメント、署名者の役割、異議申し立ての経路、オペレーターによる制御をどのように検証可能にするかを示す予定です。Mainnet Alphaは制約付きの第一段階であり、最終的な信頼モデルではありません。
関連項目: