このページは機械翻訳されています。英語の原文が正式版です。 英語で読む →
メインコンテンツにスキップ

ランブック

デスク準備の完全なチェックリストと統合認定テストです。

デスク準備チェックリスト​

本番稼働の前に、以下を確認してください。

API接続​

  • 本番エンドポイントが設定されている
  • ヘルスチェックエンドポイントが応答している
  • WebSocket接続が安定している

認証​

  • EIP-712署名が機能している
  • エージェント認可が設定されている(該当する場合)
  • ノンス管理が実装されている
  • 署名検証がテスト済みである

クオートシステム​

  • 一括注文の発注がテスト済みである
  • 注文ライフサイクルの照合が検証済みである
  • 約定トラッキングが実装されている
  • キャンセル機能がテスト済みである

リスク管理​

  • MMPが設定・テスト済みである
  • 証拠金モデルを理解している
  • ティア制限が検証済みである
  • ポートフォリオ監視が実装されている

監視​

  • WebSocketフィードを購読している
  • 注文/約定の照合が自動化されている
  • ヘルスチェックが設定されている
  • アラートが設定されている

キルスイッチ​

  • すべての注文をキャンセルできる
  • 即座に切断できる
  • 緊急時手順が文書化されている

ヘッジ​

  • Hyperliquidのパーペチュアルとの統合が検証済みである
  • デルタヘッジ戦略が実装されている
  • パーペチュアルの証拠金計算を理解している

決済​

  • 満期処理がテスト済みである
  • ポジションの決済が検証済みである
  • 参照価格のソースを理解している

統合認定テスト​

テスト1:注文の発注​

手順:

  1. POST /order で単一の注文を発注します
  2. 注文レスポンスのステータスが ACKED または OPEN であることを確認します
  3. 注文が GET /orders?wallet=... に表示されることを確認します
  4. WebSocketの order_updates を受信したことを確認します

期待される結果:注文が正常に発注され、ステータス更新を受信します

テスト2:一括注文の発注​

手順:

  1. POST /bulk_order で10件の注文を発注します
  2. すべての注文が受け付けられたことを確認します
  3. RESTとWSで注文ステータスを確認します
  4. 署名/認証エラーがないことを確認します

期待される結果:すべての注文が正常に発注されます

テスト3:約定トラッキング​

手順:

  1. 約定する注文を発注します
  2. WebSocketの fills チャネルを監視します
  3. 正しい order_id で約定を受信したことを確認します
  4. 約定が GET /fills?wallet=... に表示されることを確認します
  5. 注文ステータスが FILLED に更新されることを確認します

期待される結果:約定が正しくトラッキングされ、注文ステータスが更新されます

テスト4:部分約定トラッキング​

手順:

  1. 部分約定する注文を発注します
  2. WebSocketの fills および order_updates チャネルを監視します
  3. 部分約定が fills に届くことを確認します
  4. order_updates が累積の filled_size とともに PARTIALLY_FILLED を報告することを確認します
  5. order_id ごとに約定を集計し、合計が filled_size と一致することを確認します

期待される結果:fills には約定ごとの数量、order_updates には累積約定数量が届きます

テスト5:注文のキャンセル​

手順:

  1. POST /order で注文を発注します
  2. DELETE /order で注文をキャンセルします
  3. 注文ステータスが CANCELED であることを確認します
  4. WebSocketの order_updates を受信したことを確認します

期待される結果:注文が正常にキャンセルされ、ステータス更新を受信します

テスト6:MMPの発動​

手順:

  1. 署名付きの POST /mmp-config でMMPを設定します。クライアントが直後にプロジェクションを読み取る場合は X-Hypercall-Fence-Wait: 1 を送信し、返された X-Hypercall-Fence の値を保持します。
  2. MMPを有効にした注文を発注します
  3. 上限を超過させてMMPを発動させます
  4. 注文がMMPの理由でキャンセルされたことを確認します
  5. MMPを有効にした他の注文もキャンセルされたことを確認します

期待される結果:MMPが正しく発動し、注文がキャンセルされます

MMP設定の読み取りにも認証が必要です。GetMmpConfig に署名し、 その有効期限と署名を X-Hypercall-Expires-At-Ms および X-Hypercall-Signature ヘッダーとして送信してください。書き込みレスポンスの X-Hypercall-Fence の値をこのGETにそのまま付与すると、そのコミット済み設定が反映されるまで待機します。 X-Hypercall-Fence-Wait: 1 を付けない書き込みは、意図的に フェンスヘッダーを返しません。

テスト7:証拠金不足による拒否​

手順:

  1. 証拠金を超える注文を発注します
  2. 注文が「Insufficient margin」の理由で拒否されたことを確認します
  3. 拒否理由に必要額、エクイティ、不足額の値が含まれていることを確認します
  4. 注文ステータスが REJECTED であることを確認します

期待される結果:明確な理由とともに注文が拒否されます

テスト8:ティア制限​

手順:

  1. カバードの売りのみが許可されるティアのウォレットを使用します(GET /risk/limits?wallet=... で確認)
  2. ロングポジションを持たない状態で売り注文の発注を試みます
  3. 注文がティアの理由で拒否されたことを確認します
  4. 買い注文を発注します(成功するはずです)
  5. 決済のための売り注文を発注します(成功するはずです)

期待される結果:ティア制限が正しく適用されます

テスト9:WebSocketの再接続​

手順:

  1. WebSocketに接続します
  2. チャネルを購読します
  3. WebSocketを切断します
  4. 指数バックオフで再接続します
  5. チャネルを再購読します
  6. RESTをポーリングして、取りこぼした更新を補完します

期待される結果:再接続が機能し、状態が復元されます

テスト10:ポートフォリオの照合​

手順:

  1. 注文を発注し、約定させます
  2. GET /portfolio?wallet=... でポートフォリオを確認します
  3. ポジションが約定と一致することを確認します
  4. 証拠金使用量が正しいことを確認します
  5. WebSocketの portfolio 更新と照合します

期待される結果:ポートフォリオの状態が正確で、照合が成功します

本番稼働の準備​

本番前チェックリスト​

  • すべての統合テストに合格している
  • 監視とアラートが設定されている
  • キルスイッチがテスト済みである
  • 緊急時手順が文書化されている
  • チームがインシデント対応の訓練を受けている
  • サポート窓口が特定されている

本番稼働チェックリスト​

  • 本番環境で小さいサイズにより認定テストに合格している
  • 本番エンドポイントが検証済みである
  • 監視ダッシュボードの準備ができている
  • アラートが設定されている
  • チームのオンコール体制が確立されている
  • ドキュメントがレビュー済みである

参考資料​

最終更新: