HyperliquidのWebSocket APIを使用する理由
Hyperliquidは、分散型取引において最速クラスのWebSocket APIを提供しています。サブ秒のブロックタイムは、WebSocketデータストリームが最小限の遅延で実際のオンチェーン状態を反映することを意味します — WebSocketデータがマッチングエンジンより先行または遅延する可能性がある一部のCEXとは異なります。トレーディングボット、リアルタイムダッシュボード、アラートシステムのいずれを構築する場合でも、WebSocket APIは基盤となります。
このガイドでは、基本的な接続設定からプライベートポジションデータの認証済みストリームまですべてをカバーします。Hyperliquidが初めての方は、app.hyperliquid.xyz/join/HOLYGRAILでコードHOLYGRAILを使用して、構築中に取引手数料を4%節約してください。
公開WebSocketエンドポイント
Hyperliquidの公開WebSocketストリームは認証を必要としません。任意のWebSocketクライアントから直接接続できます。主な公開エンドポイントは以下の通りです。
- メインネットWebSocket:
wss://api.hyperliquid.xyz/ws— すべての本番取引データのプライマリエンドポイント。 - テストネットWebSocket:
wss://api.hyperliquid-testnet.xyz/ws— 実際の資金を使わない開発とテスト用。
両方のエンドポイントは同じメッセージ形式をサポートしています。メインネットにデプロイする前に、必ずテストネットで開発とテストを行ってください。
マーケットデータストリームへのサブスクライブ
接続後、JSONサブスクリプションメッセージを送信して特定のデータストリームにサブスクライブします。最も一般的に使用されるストリームへのサブスクライブ方法は以下の通りです。
注文板更新
BTC-PERPのリアルタイム注文板スナップショットと増分更新を受信するには:
subscription:
type: "l2Book"
coin: "BTC" レスポンスには、サブスクリプション時の完全なスナップショットと、その後の注文が発注、約定、またはキャンセルされるたびの増分更新が含まれます。各更新には価格レベルとサイズが含まれており、注文板のローカルコピーを維持することが簡単です。
最近の取引
特定の市場のすべての取引をストリーミングするには:
subscription:
type: "trades"
coin: "ETH" 各取引メッセージには、価格、サイズ、サイド(買いまたは売り)、ミリ秒単位のタイムスタンプが含まれます。このストリームは、出来高加重平均価格の計算や取引シグナル生成に役立ちます。
ローソク足データ
さまざまな間隔のOHLCVローソク足の場合:
subscription:
type: "candle"
coin: "SOL"
interval: "1m" サポートされる間隔には、1m、5m、15m、1h、4h、1dが含まれます。より高い時間枠のデータのみが必要な場合、ローソク足ストリームはティックレベルの取引ストリームよりも帯域幅効率が高くなります。
認証済みWebSocketストリーム
プライベートデータ(未約定注文、ポジション、口座更新)には、認証済みWebSocket接続が必要です。Hyperliquidは、WebSocket接続自体に秘密鍵を公開することなく、ウォレットを管理していることを証明する署名ベースの認証スキームを使用しています。
認証フローは以下のように動作します:
- 現在時刻から60秒以内のタイムスタンプを生成します。
- ウォレットの秘密鍵でメッセージに署名して署名を作成します。署名可能なペイロードには、アクションタイプとタイムスタンプが含まれます。
- ウォレットアドレス、タイムスタンプ、署名を含む認証済みサブスクリプションメッセージを送信します。
認証されると、以下のプライベートストリームにサブスクライブできます:
- 注文更新: 注文が発注、部分的約定、完全約定、またはキャンセルされたときのリアルタイム通知。
- ポジション更新: 全市場の現在のポジションサイズ、エントリー価格、未実現損益、清算価格。
- 口座更新: 証拠金使用率、利用可能担保、総口座価値の変更。
接続管理のベストプラクティス
WebSocket接続は永続的ではありません。ネットワーク切断、サーバー再起動、レート制限はすべて切断を引き起こす可能性があります。堅牢な実装はこれらを適切に処理する必要があります。
- 指数バックオフによる自動再接続。 接続が切れた場合、1秒後、2秒、4秒、8秒、最大60秒まで再試行します。これにより、サーバーに負荷をかけずにタイムリーな再接続を確保します。
- 再接続時に再サブスクライブ。 再接続後、サブスクリプションは持続しません。新しい接続を確立した後は、常にサブスクリプションメッセージを再送信してください。
- ローカル注文板スナップショットを維持する。 再接続のたびに完全なスナップショットを再要求するのではなく、ローカルコピーを維持して増分更新を適用します。これによりAPIの負荷が減り、ボットの応答性が向上します。
- ハートビート監視。 30秒ごとにpingメッセージを送信し、pongレスポンスを期待します。2回連続してpongを逃した場合、接続が失効していると見なし、再接続を開始します。
レート制限とスロットリング
HyperliquidはRESTエンドポイントと同様にWebSocket接続にもレート制限を適用します。個人トレーダーには寛大ですが、自動化システムはこれを尊重する必要があります。
- 接続あたりの最大サブスクリプション数:50アクティブストリーム。
- IPあたりの最大接続数:10。
- メッセージバースト制限:スロットリングが開始される前に約100メッセージ/秒。
これらの制限を超えると、Hyperliquidはレート制限エラーコードで接続を閉じます。この場合、再接続ロジックには再試行前の遅延を含める必要があります。
WebSocketセットアップのテスト
実際の資金を接続する前に、テストネットでWebSocket実装をテストしてください。手順は以下の通りです。
wss://api.hyperliquid-testnet.xyz/wsに接続します- BTCのL2ブックにサブスクライブし、スナップショットと更新メッセージが正しく到着することを確認します。
- REST API(またはテストネットのWebインターフェース)を通じてテスト注文を発注し、認証済みストリームに注文更新が表示されることを確認します。
- WebSocketクライアントを強制終了して切断をシミュレートし、再接続ロジックが機能することを確認します。
- 24時間にわたってメモリとCPU使用率を監視し、リソースリークがないことを確認します。
テストネットですべてが機能したら、エンドポイントURLをメインネットに切り替えれば準備完了です。
避けるべき一般的な落とし穴
- 多すぎるストリームへのサブスクライブ。 各サブスクリプションは永続的なデータフローを生み出します。100以上のコインの注文板にサブスクライブすると、かなりの帯域幅とCPUを消費します。実際に取引する市場のみにフィルタリングしてください。
- メッセージの順序を無視する。 WebSocketメッセージは順不同で到着する可能性があります。Hyperliquidは注文板更新にシーケンス番号を含めています — これを使用してギャップを検出し処理してください。
- WebSocket URLのハードコーディング。 エンドポイントは変更される可能性があります。設定ファイルまたは環境変数を使用して、再デプロイせずに更新できるようにしてください。
- 古いデータを処理しない。 WebSocketが数秒以上無音になった場合、ローカル状態が古くなっている可能性があります。WebSocketが遅延したときにデータを更新するためのフォールバックとしてREST APIを使用してください。