Latency Budgeting on Hyperliquid: From REST Polls to Sub-Second Reads

By @CoinMarketMan - 08-Jun-2026

Hyperliquidにおけるレイテンシバジェッティング:RESTポーリングからサブ秒読み取りまで

Hyperliquidには、収益性と非収益性の差がミリ秒単位で測られる取引戦略のクラスが存在します。HyperliquidとCEXのパーペチュアル取引所間のファンディングレート裁定取引。第二波が発動する前にエントリーする必要がある清算カスケードのフェード。Money Printerコホートがネットロングに転じた同じ分にポジションを構築したいコホートフリップシグナル。

これらの戦略では、データをどのように読み取るかのアーキテクチャが戦略そのものよりも重要です。3秒遅れて発動する完璧にサイズ調整されたコホートフリップエントリーは、タイミング通りに発動する中程度のサイズのエントリーよりも悪いトレードです。レイテンシは「あれば便利」なものではなく、実行可能な戦略を形成するハード制約です。

この記事では、Hyperliquidベースの戦略のレイテンシバジェッティングについて解説します:各データソースが実際にかかる時間、RESTポーリングが破綻するポイント、WebSocketサブスクリプションとイベント駆動型アーキテクチャが実行可能性の境界をどのように変えるか。

レイテンシスタック

典型的なHyperliquid取引パイプラインには4つのレイテンシレイヤーがあり、それぞれがHyperliquidのL1でイベントが発生してからシステムが反応するまでの間にミリ秒(または秒)を追加します:

オンチェーン→インデクサー。 HyperliquidのL1で約定が成立してから、データプロバイダーのインデックスに表示されるまでの時間。HyperTrackerの場合、通常200-800ms。
インデクサー→あなたのコード。 インデクサーがデータを持ってから、あなたのコードがそれを見るまでの時間。RESTポーリング:ポーリング間隔に依存(典型的には1-30秒)。WebSocket:5-50ms。
あなたのコード→判断。 シグナルを処理して行動を決定するまでの時間。コードの複雑さに依存。レイテンシに敏感な戦略では100ms未満であるべき。
判断→約定。 コードがオーダーを発行してから、そのオーダーがHyperliquidの板に置かれるまでの時間。HyperliquidのL1へのネットワーク距離に応じて、典型的には80-300ms。

高速戦略の総レイテンシバジェット:WebSocketパスで約500ms-1秒、RESTポーリングパスで2-30秒。

RESTポーリングが破綻するポイント

RESTポーリングは、シンプルであるため、ほとんどの分析統合でデフォルトです — スケジュールに従ってHTTPリクエストを行い、取得したものを処理します。シグナルからアクションまでの時間が分単位で測られる戦略(ほとんどのリテールコピートレード)では問題なく機能しますが、時間に敏感なものでは激しく破綻します。

破綻ポイント:

ファンディング決済。 Hyperliquidのファンディングは1/8のレートで毎時決済されます。決済直前に極端な方向の正しい側にいることでファンディングを獲得する戦略の場合、ポジションを取る時間は数秒しかありません。5秒間隔のRESTポーリングでは、すでに50%の機会を逃しています。

清算カスケード。 Hyperliquidで大規模な清算がトリガーされると、二次清算(価格インパクトの範囲内に清算価格があったポジション)は数百ミリ秒以内に発動します。カスケードをフェードしたい戦略は、リバウンドの前にポジションを取るためにWebSocketレベルのレイテンシが必要です。

ニュース触媒によるコホートフリップ。 リアルタイムのニュースイベント(決算、規制発表、ETF承認)は、その後の10-60分間で複利的に増幅するコホートポジショニングの変化をトリガーします。最初の波を捉えるには、ポーリングではなく、データストリームにライブで接続している必要があります。

一般的なルール:実行を5秒遅らせたときに戦略のエッジが50%以上低下する場合、RESTポーリングは不適切です。

WebSocketサブスクリプションが実際に買うもの

HyperTracker APIは、すべてのリアルタイムデータでWebSocketサブスクリプションを公開しています:ポジション、約定、コホートポジショニング、ファンディングレート、清算。RESTとのアーキテクチャの違い:

REST(ポーリング): N秒ごとに、あなたのコードがサーバーに「現在の状態は何ですか?」と尋ねます。サーバーはスナップショットを返します。前のスナップショットと差分を取って変更を見つけます。レイテンシフロア = ポーリング間隔。

WebSocket(プッシュ): あなたのコードは永続的な接続を維持します。サーバーは変更が発生するたびに送信します。レイテンシフロア = ネットワークラウンドトリップ時間、場所に応じて典型的には20-100ms。

高頻度のコホート監視では、この差は意味があります。コホートポジショニングエンドポイントに対して5秒ごとにRESTポーリングすると、最大5秒の古さがコストになります。WebSocketの同等物は約50msです。

コード面では、切り替えは複雑さを追加しますが、それほど多くはありません:

import websockets, json

async def subscribe_cohort_changes(asset="BTC"):
    async with websockets.connect("wss://api.hypertracker.cmm.app/ws") as ws:
        await ws.send(json.dumps({
            "subscribe": "cohort_positioning",
            "asset": asset,
            "cohorts": ["money_printer", "smart_money"]
        }))
        async for message in ws:
            event = json.loads(message)
            # event = {"cohort": "money_printer", "asset": "BTC",
            #         "long_ratio": 0.62, "delta_24h": +0.08, ...}
            handle_cohort_update(event)

これがサブスクリプション全体です。更新は発生するたびに流れます。

戦略タイプ別のレイテンシバジェット

異なる戦略は異なるレイテンシを許容します。大まかな分類:

| 戦略 | 許容可能なレイテンシ | 必要なアーキテクチャ | |---|---|---| | コピートレード(複数日保有) | 10-60秒 | 30秒RESTポーリング | | コホートバイアスシグナル(4時間-1日の判断) | 1-5秒 | 1秒RESTポーリングまたはWebSocket | | ファンディング裁定取引 | 200-500ms | WebSocket必須 | | 清算カスケードフェード | <200ms | WebSocket + コロケーション実行 | | ニュース駆動型コホートフリップ | <2秒 | WebSocket必須 |

ほとんどのビルダーが犯す間違いは過剰設計です。12時間保有でポジションを開くコピートレードダッシュボードを構築している場合、WebSocketは不要なインフラコストです。30秒間隔のRESTポーリングで完全に十分です。実際に重要な戦略のために複雑さのバジェットを節約してください。

アーキテクチャ:イベント駆動 vs ポーリング駆動

データレイヤーとしてWebSocketにコミットすると、システムアーキテクチャの残りの部分が変わります。ポーリング駆動システムはサイクルで動作します:N秒ごとに、状態をチェックし、決定し、行動します。イベント駆動システムは反応で動作します:イベントが到着したら、すぐに処理し、場合によっては行動します。

イベント駆動システムは正しく書くのが難しいです。なぜなら:

状態管理は並行的(1つを処理している間に複数のイベントが到着する可能性がある)
データ更新とあなたのアクション間の競合状態が可能になる
イベントが予測不可能な順序で発動するとデバッグが難しい

しかし、レイテンシに敏感な戦略では、選択肢はありません。ポーリングサイクルの最悪ケースのレイテンシは高すぎます。

Hyperliquidでのコホート監視のためのクリーンなイベント駆動パターン:

class CohortMonitor:
    def __init__(self):
        self.state = {}  # アセット別の現在のコホートポジショニング
        self.position_book = {}  # あなたのオープンポジション

    async def on_cohort_event(self, event):
        asset = event["asset"]
        cohort = event["cohort"]

        # 状態を更新
        self.state[(asset, cohort)] = event["long_ratio"]

        # トリガーをチェック
        if cohort == "money_printer":
            await self.check_money_printer_flip(asset, event)

    async def check_money_printer_flip(self, asset, event):
        # Money Printerはネットショートだったが、今はネットロング?それがシグナル。
        prev = self.state.get((asset, "money_printer_prev"), 0.5)
        if prev < 0.5 and event["long_ratio"] >= 0.55:
            await self.open_position(asset, side="long", size=...)

トリガーはWebSocketがイベントを配信した瞬間に発動します。ポーリング遅延なし、機会を逃すことなし。

コスト考慮事項

WebSocketサブスクリプションは、ほとんどのAPIティアでRESTポーリングよりもコストがかかります。HyperTrackerのPulseティア($179/月)にはWebSocketアクセスが含まれています。計算:サブ秒レイテンシが必要な戦略を実行していて、代わりにRESTをポーリングしている場合、月$179以上の価値があるトレードを失っています。計算してください。

無料ティアと最低の有料ティアはRESTのみです。上記のレイテンシに敏感な戦略以外では問題ありません。

より大きな枠組み

ほとんどのリテールビルダーは、データレイテンシを技術的な詳細として扱います。違います。これは、あなたがアクセスできる戦略のクラスを決定する戦略的制約です。データパイプラインが5秒の解像度を持っている場合、ファンディング裁定取引、カスケードフェード、ニュース駆動型エントリーから完全にロックアウトされます — シグナルがどれだけ優れていても、完全にです。

良いニュース:RESTポーリングとWebSocket間のギャップは開発努力において大きくなく、レイテンシバジェットの変更は戦略カテゴリー全体をアンロックします。Hyperliquidネイティブ戦略に取り組んでいるビルダーにとって、WebSocket投資は通常、あなたが行う最高ROIのインフラ決定です。

コホート + ポジションデータへのWebSocketアクセスを取得 →

レイテンシは戦略品質の静かな天井です。それを測定し、それを中心に設計し、それを下回るティアに支払ってください。