Hyperliquid API のレート制限を先に設計する── 取引量が発注枠を決める仕組み

Hyperliquid に接続する処理を書くとき、レート制限は「あとで詰まったら調整する」項目として後回しにされがちです。ところがこの取引所の制限は二重構造になっており、片方は取引量に連動します。仕組みを知らずに設計すると、検証環境では問題なく動いていた発注処理が、本番で新規口座を使った瞬間に枠を使い切ります。

本稿では、公開されている制限の数値を整理し、設計にどう落とすかを示します。数値はすべて公式ドキュメントの記載で、末尾に出典を挙げています。

接続先は 2 つ

REST の接続先は、本番が https://api.hyperliquid.xyz、テストネットが https://api.hyperliquid-testnet.xyz です。パスは参照系が /info、発注系が /exchange に分かれます。

公式の SDK は Python 向けが提供されており、Rust と TypeScript はコミュニティ製、加えて CCXT が複数言語の統合を維持しています。SDK の選択は、保守の主体がどこかを確認したうえで決めます。

設計としては、まず接続先を設定として外に出すことです。テストネットで検証してから本番へ移す前提が置けるのは、この取引所の扱いやすい点なので、それを活かせる構成にしておきます。

制限その一 ── IP 単位の重み付け

IP 単位では、REST リクエストの合計の重みが毎分 1200 に制限されています。重要なのは、これが「リクエスト数」ではなく「重み」である点です。呼ぶ先によって 1 回あたりの重みが違います。

• 発注系（/exchange）── 1 + floor(batch_length / 40)
• 一部の参照系（l2Book, allMids, clearinghouseState, orderStatus, spotClearinghouseState, exchangeStatus）── 重み 2
• userRole ── 重み 60
• その他の参照系 ── 重み 20

この差は設計に直結します。板情報（l2Book）は重み 2 なので毎分 600 回まで呼べますが、その他の参照系は重み 20 なので毎分 60 回しか呼べません。「参照系だから軽い」という前提でポーリング間隔を決めると、10 倍見誤ります。

さらに、返却件数に応じて重みが加算される種類があります。recentTrades、historicalOrders、userFills などは 20 件ごとに、candleSnapshot は 60 件ごとに重みが足されます。大きな期間をまとめて 1 回で取りに行くと、リクエスト数は 1 でも重みは大きくなります。履歴の一括取得を回すバッチは、ここで詰まります。

発注系の 1 + floor(batch_length / 40) は逆に、まとめて送るほど 1 件あたりの重みが下がる形です。40 件までなら重み 1 で済みます。1 件ずつ送る実装は、この設計思想と噛み合っていません。

制限その二 ── アドレス単位の発注枠

こちらが見落とされやすい方です。アドレス単位では、累計 1 USDC の取引につき 1 リクエストという枠が与えられます。初期分として 10000 リクエストのバッファがあります。

つまり、取引していない口座は発注枠がほとんどありません。初期バッファの 10000 を使い切ると、それ以降は取引量に応じてしか枠が増えません。試験的に大量の注文と取消を繰り返す実装は、取引が成立しないまま枠だけを消費します。

取消については緩和があり、上限は min(limit + 100000, limit * 2) という形になります。とはいえ無制限ではありません。

建玉の本数にも上限があります。既定は 1000 本で、取引量 500 万 USDC ごとに 1 本追加、合計 5000 本が上限です。板に多数の指値を並べる戦略は、この上限を前提に組む必要があります。

設計への落とし込みは明確です。発注枠の消費を計測する仕組みを最初から入れる。「何回発注したか」ではなく「累計取引量に対してどれだけ消費したか」を見ます。この比率を監視していないと、枠を使い切った瞬間に理由が分からず止まります。

WebSocket の制限

WebSocket 側にも明確な数値があります。

• 接続数の上限 ── 10
• 毎分の新規接続 ── 30
• 購読数の上限 ── 1000
• ユーザー個別の購読にまたがるユニークユーザー数 ── 10
• 毎分の送信メッセージ数 ── 2000
• 同時に処理中の post メッセージ ── 100

接続 10 本という上限は、プロセスを増やして並列化する方式と相性が悪いことを意味します。銘柄ごとにプロセスを立てる構成は、すぐ頭打ちになります。1 接続に複数購読を載せる前提で組み、購読の管理を 1 か所に集約する形が素直です。

毎分 30 という新規接続の上限も効いてきます。切断のたびに即座に再接続するループを書くと、この上限に当たって再接続そのものができなくなります。再接続には待ち時間を指数的に伸ばす仕組みを入れておきます。

なお EVM の JSON-RPC は別枠で、rpc.hyperliquid.xyz/evm に対して毎分 100 リクエストです。

設計の順序

以上を踏まえると、設計の順序は次のようになります。

第一に、必要な情報を購読で取るか照会で取るかを決める。板情報を毎秒取りに行くなら WebSocket、日次のバッチなら REST、という切り分けを先に済ませます。両方を無自覚に使うと、どちらの制限にも中途半端に近づきます。

第二に、重みの合計を見積もる。呼ぶ先ごとの重みと呼ぶ頻度を掛けて、毎分 1200 に収まるかを机上で確認します。実装してから測るより速く、確実です。

第三に、発注枠の消費を監視項目に入れる。取引量に連動する制限は、他の取引所にはあまり無い性質なので、既存の監視の枠組みには入っていないはずです。

第四に、テストネットで異常系まで通す。制限に当たったときの挙動、再接続、取消の失敗。正常系だけを確認して本番へ移すと、最初の混雑時に止まります。

まとめ

Hyperliquid のレート制限は、IP 単位の重み付けと、アドレス単位の取引量連動という二重構造です。前者は呼ぶ先ごとの重みが 2 から 60 まで開いており、後者は取引していない口座に枠がほとんどありません。WebSocket は接続 10 本・購読 1000 という上限があり、プロセス並列で増やす方式とは噛み合いません。いずれも公開されている数値なので、実装前に机上で見積もれます。詰まってから調整するより、先に設計へ織り込むほうが確実です。

金融テクノロジー総合研究所では、暗号資産取引所への接続基盤の設計と実装を受託しています。既存構成の点検や、複数取引所をまとめる基盤の設計からご相談いただけます。Hyperliquid API 対応の詳細もあわせてご覧ください。ご相談はお問い合わせよりご連絡ください。

参考資料

• Hyperliquid Docs — API（本番・テストネットのベース URL、/info と /exchange、公式 SDK）
• Hyperliquid Docs — Rate limits and user limits（本稿のレート制限の数値はすべてここが出典）
• Hyperliquid Docs — WebSocket（購読形式）
• hyperliquid-python-sdk（公式 Python SDK）

FTL の技術スタックと受託開発の進め方は FTLの技術とは？ にまとめています。