Hyperliquid Foundation WebSocketの変更点：ユーザーへの影響

Quicknode

2026年6月12日 — 読了時間10分

シェア

「お気に入り」として追加

2026年6月9日、Hyperliquid のコアメンバーであるequipe は、次回のネットワークアップグレード以降、いくつかの公開WebSocket APIフィードのデータ配信頻度が低下すると発表しました。2026年6月11日、equipe は、ユーザー へのフィードバックに基づき、この展開計画を調整しました： webData2 現在の5秒間のプッシュ間隔は、あと1回のネットワークアップグレードまでは維持される予定である。標準 l2Book 2秒ごとに20レベルまで移動し、その後5秒ごとに移動するようになり、さらに新しい fastAssetCtxs WebSocketフィードでは、インターフェースごとに5秒ごとの価格差が保持されます。

影響を受けるフィードには、引き続き注文簿の深さ、ミッド価格、資産コンテキスト、すべてのDEX資産コンテキスト、および webData2, これは依然として移行が見込まれており、 webData3.

ダッシュボード、ポートフォリオ監視ツール、およびユーザー向けのビューについては、新しい間隔でも許容範囲内かもしれません。しかし、自動化された取引 システムの場合、これによりデータモデルが変更されます。公開されているWebSocketスナップショットから注文の提示、数量指定、取消、またはルーティングを行う戦略では、これとは異なるデータプレーンが必要となります。

Hyperliquidのequipe は、このワークロードの予想される進路について率直に語った：

この記事では、どのような変更が行われるのか、それがボットにとってなぜ重要なのか、そしてレイテンシに敏感なHyperliquid のワークロードを、 Quicknode。

Hyperliquid の公開WebSocket APIにはどのような変更がありましたか？

その l2Book 自動戦略において、変化への対応が最も重要です。それなしでは fast: true、次回のアップグレード後は、パブリックAPIが2秒ごとに20レベル分のデータを返すようになり、その後5秒ごとに変更される見込みです。 fast: true、0.5秒ごとに5レベルのデータを返します。どちらのオプションも、深さ、キューの挙動、あるいは急激なスプレッド変動に依存する戦略にとって、完全なリアルタイムのブックを提供するものではありません。

これは、通常の意味でのサービス停止や互換性破綻ではありません。これは、共有の公共インフラと、by による自動化された取引 システムに必要なデータプロファイルとの境界線です。

取引 のボットにとって、WebSocketの更新速度が遅いことがなぜ問題となるのでしょうか？

ボットにとって、古くなった本は不便なこととは感じられません。それは単なる誤った入力として認識されるのです。

マーケットメーカーは、リアルタイムの在庫状況やスプレッドに基づいて価格を提示するために、最新の注文簿情報が必要です。執行ボットは、注文の規模を決定するために、最新のミッド価格と注文簿のプレッシャーを把握する必要があります。清算、アービトラージ、およびベーシス戦略では、直近のスナップショットと現在のブロックとの差が可能な限り小さくなることが求められます。

ある銘柄の情報が2秒または5秒間隔で更新される場合、その戦略は単にby のその更新間隔に遅れているだけではありません。それは、異なる市場状況に基づいて動いているのです。これにより、以下の点に影響が及びます：

• 見積書の提示時期と解約のタイミング

• スプレッド、スリッページ、および逆選択の計算

• ポジションサイズの設定とリスクチェック

• 注文を発動させる清算および資金調達モニター

• 本番環境と同様のデータフィードを想定したバックテスト

UI、パッシブモニタリング、および重要度の低い表示データに関しては、パブリックAPIの利用が依然として有効な場合があります。現在の深度に依存する取引 ロジックには、WebSocketサブスクリプションであれgRPC ストリームであれ、その目的に合わせて設計されたフィードが必要です。

Hyperliquid は、自動取引を行うトレーダーに対してどのようなことを推奨していますか？

Hyperliquidのガイダンスでは、より多くのレベルに対応したり、リアルタイムの更新を実現したりするために、非検証ノードを稼働させることを推奨しています（streams ）。これにより、自動取引を行うトレーダーは必要なデータプロファイルに直接アクセスできるようになりますが、その一方で、ノードの運用、アップグレード、監視、再接続処理、キャパシティプランニング、クライアントとの統合といったインフラ関連の作業も発生します。

Quicknode ブロックチェーン Hyperliquid の開発プラットフォームであり、単一の エンドポイントを通じて、HyperCoreおよびHyperEVM全体にわたり管理された インフラストラクチャを提供するgRPC 開発プラットフォームです。すべてのHyperliquid エンドポイント。この公開APIの変更の影響を受けるチーム 対応のby において、最も重要な機能はHyperCoreのgRPC ストリーミングです。これはWebSocketが不適切なツールだからではなく、大規模な環境においてWebSocketが脆弱になる点が明らかになっているためです。具体的には、再接続の嵐、パッケージ駆動型ストリームの脆弱性、およびマルチマーケットのサブスクリプションにおけるペイロードのオーバーヘッドなどが挙げられます。

Quicknode's Hyperliquid ドキュメント gRPC サポート を、HyperCoreデータの全セットstreams に対して、双方向ストリーミング、市場データに対する1ミリ秒未満のレイテンシ、および帯域幅をby 約70％削減できるネイティブzstd圧縮機能とともに提供します。アクセスについては /ハイパーコア JSON-RPC、 /ハイパーコア WebSocket および HyperCoregRPC を利用するには、Build プラン以上が必要です。

まずは、「Quicknode 」Hyperliquid のドキュメントと、「Hyperliquid 」gRPC のストリーミング API リファレンスから確認してください。

自動取引を行うトレーダーは、どのHyperCoreデータセットを利用すべきでしょうか？

主な違いは、単にプライベートであるということだけではありません エンドポイントだけではありません。自動取引 ワークロードに適したHyperCoreデータセットへのアクセスこそが、その違いなのです。

QuicknodeHyperliquid のデータセットには、約定済み取引、注文ライフサイクルイベント、オーダーブックの更新、TWAP約定データ、口座および残高イベント、HyperCoreからHyperEVMへのライターアクション、生ブロック、L2オーダーブックのスナップショット、L4オーダーブックのスナップショットおよび差分データ、ならびに テストネット mempoolトランザクションを含んでいます。

これが重要なのは、パブリックWebSocketフィードの適切な代替手段は、その戦略がどのような役割を果たしているかによって異なるからです。マーケットメーカーに必要なデータは清算モニターとは異なり、ダッシュボードに必要なデータは注文ルーティングツールとは異なります。

現在の価格水準の出来高分布を表示するStreamL2Book

StreamL2Book ブロックごとに、L2の注文帳の完全な集計スナップショットを送信します。各メッセージには、by の各価格水準における現在の買い注文と売り注文、および各水準ごとの総数量と注文数が含まれます。

使用方法 StreamL2Book 増分差からローカル・ブックを構築することなく、戦略で現在のby の価格水準の深さが必要な場合。このストリームは設定可能な深さをサポートしており、 n_levels 最大100件に加え、より広範な集計を行うためのオプションの価格帯分け機能も利用可能です。

公的機関と比較して l2Book 0.5秒ごとに5レベル、あるいは2秒ごとに20レベルを配信するフィード（その後5秒間隔に移行）は、マーケットメイキング、スプレッド監視、注文簿を考慮した約定、および注文簿に基づくアラートに最適です。

個々の注文レベルのステータスを表示するStreamL4Book

StreamL4Book 注文帳を個々の注文単位で配信します。サブスクライブ時には、現在の買い注文と売り注文の完全なスナップショットを送信します。その後は、ブロックごとの差分データを送信します。

使用方法 StreamL4Book 価格水準の集計だけでは不十分な場合。例としては、キュー分析、注文レベルの流動性調査、市場のミクロ構造に関する研究、および価格水準の合計だけでなく個々の未約定注文を追跡する必要があるシステムなどが挙げられる。

StreamL2Book そして StreamL4Book これらはgRPC 専用です。WebSocketやJSON-RPCでは利用できません。

チーム は、Hyperliquid のボットを新しいペースに合わせてどのように調整すべきでしょうか？

Hyperliquid のすべての連携を一度に移行する必要はありません。まず、by から始め、決定用の入力と表示用の入力を分けてください。

1. 各サブスクリプションを分類してください。

   注文、キャンセル、サイズ調整、またはリスク制限をトリガーするフィードは、優先的に移行すべきです。ダッシュボード、ユーザー で表示されるチャート、またはパッシブモニタリングを駆動するフィードは、多くの場合、WebSocketのままにしておくことができます。

2. public を置き換える l2Book 取引 の決定について。

   使用方法 StreamL2Book 戦略において、価格水準の深さ、注文簿の最上位の更新頻度、またはスプレッドの計算が必要な場合は、以下をご利用ください。 StreamL4Book 個別の注文状況やキューレベルの詳細情報が必要な場合。

3. ストリームモデルに基づいて、再接続の挙動を設計する。

   ～とともに StreamL2Book、各メッセージはそのブロックに関する完全なL2スナップショットであるため、コンシューマーは更新のたびにローカルの価格水準の状態を置き換えることができます。これにより、 StreamL4Book、スナップショットから初期化し、差分を適用し、再接続時には新しいスナップショットからリセットする。

4. 実行、分析、アラートはそれぞれ別々のパスで処理するようにしてください。

   一般的な運用構成としては、戦略のリアルタイム市場データにはgRPC 、ローカルで署名された注文にはHyperliquid 取引 API またはSDK 、バッチ処理や履歴データの読み取りには JSON-RPC、非同期イベントパイプラインにはStreams またはWebhooks 、調査や分析には SQL Explorer が使用されます。

5. 移行期間中は、両方のフィードを稼働させてください。

   ネットワークのアップグレードを行う前に、既存のパブリックWebSocketコンシューマーを、新しいgRPC コンシューマーと並行して実行してください。注文残高、観測スプレッド、更新間隔、約定品質、および戦略固有のリスク指標を比較してください。これにより、土壇場での エンドポイント 切り替えを回避し、具体的な切り替え計画を策定できます。

他にどのようなQuicknode ツールやサポート 、Hyperliquid 、取引 システムがありますか？

gRPC レイテンシに敏感なHyperCoreの市場データを探すなら、まずここをチェックすべきですが、すべてのワークロードを網羅する必要はありません。

• WebSocketはすべてのHyperliquid エンドポイントで利用可能です。現在も、ブラウザ上のダッシュボード、ポートフォリオビュー、モニタリング画面、および更新プロファイルが戦略と一致するすべての取引 ワークロードを支えています。

• JSON-RPC では、バックフィル、バッチブロック読み取り、ポートフォリオの状態、清算機関の状態、および HyperEVM コントラクトとの連携に対応しています。

• Streams また Webhooks フィルタリングされたイベントをバックエンドシステムやアラートパイプラインに送信できます。

• SQL Explorerは、Hyperliquid データのインデックス付き行500B以上に対してクエリを実行し、そのクエリをプログラム可能なRESTエンドポイントとして公開することができます。

QuicknodeのHyperliquid チェーンのページには、99.99%の稼働率を保証するSLA、月間60億件以上のHyperliquid APIリクエスト、および5,000億行以上のクエリ可能なデータも記載されています。ワークロードが単なるデモではなく、常時稼働する取引 システムである場合、こうした数値は重要な意味を持ちます。

Hyperliquid （gRPC ）をどのように使い始めればよいですか？

1. quicknode.com/signup で「Quicknode 」アカウントを作成してください。

2. xml-ph-0000@deepl.internalダッシュボードからHyperliquid エンドポイント Quicknode ダッシュボードから作成します。1つ エンドポイント は、HyperCoreおよびHyperEVM全体で管理されたアクセスを提供します。

3. 利用可能なHyperliquid データセットを確認し、各戦略の入力項目を、それに対応するストリームに割り当ててください。

4. Hyperliquid （gRPC ）のストリーミングAPIドキュメントを参照して、コンシューマーを接続してください。

5. ご自身の戦略に合ったストリームをお選びください： StreamL2Book 価格水準の総合的な詳細については、 StreamL4Book 個々の注文レベルの状態、または取引、注文、イベント、および注文簿の更新に関する標準データセット。

6. HyperCoreのgRPC サンプルリポジトリをクローンして、JavaScript、Python、Go、またはRustでサブスクリプションをテストしてください。

7. 『Hyperliquid 』ガイドライブラリおよびサンプルアプリライブラリにある実用例を確認してください。

HyperliquidのパブリックAPIの更新は、同ネットワークが共有エンドポイントを、より軽量で幅広いアクセスパターンへと移行させていることを示すものです。自動取引を行うトレーダーには、別のアプローチが必要です。具体的には、最新の注文簿、より多くのレベル、リアルタイムのstreams 、そして常時稼働システム向けに構築されたインフラストラクチャが求められます。

Quicknode ノードインフラを自ら運用することなく、そのセットアップへの管理されたパスを提供します。

まずは Quicknode Hyperliquid ドキュメントから始めてください。