レート制限とユーザー制限
以下のレート制限はIPアドレスごとに適用されます：
- RESTリクエストは、毎分1200の集約ウェイト制限を共有します。
- ドキュメント化されたすべての
exchangeAPIリクエストのウェイトは1 + floor(batch_length / 40)です。例えば、バッチ化されていないアクションのウェイトは1、長さ79のバッチ注文リクエストのウェイトは2です。ここで、batch_lengthはアクション内の配列の長さ、例えばバッチ注文アクション内の注文数です。 - 以下の
infoリクエストのウェイトは2です：l2Book, allMids, clearinghouseState, orderStatus, spotClearinghouseState, exchangeStatus. - 以下の
infoリクエストのウェイトは60です：userRole。 - その他のドキュメント化されたすべての
infoリクエストのウェイトは20です。 - 以下の
infoエンドポイントは、応答で返される20アイテムごとに追加のレート制限ウェイトが課されます：recentTrades,historicalOrders,userFills,userFillsByTime,fundingHistory,userFunding,nonUserFundingUpdates,twapHistory,userTwapSliceFills,userTwapSliceFillsByTime,delegatorHistory,delegatorRewards,validatorStats。 candleSnapshotinfoエンドポイントは、応答で返される60アイテムごとに追加のレート制限ウェイトが課されます。- すべての
explorerAPIリクエストのウェイトは40です。blockListにはブロックごとに1という追加のレート制限があります。最近クエリされていない古いブロックは、より重くウェイト付けされる場合があることに注意してください。大規模なバッチリクエストには、代わりにS3バケットを使用してください。 - WebSocket接続は最大10
- 毎分の新規WebSocket接続は最大30
- WebSocketサブスクリプションは最大1000
- ユーザー固有のWebSocketサブスクリプションにわたる一意ユーザーは最大10
- すべてのWebSocket接続を通じてHyperliquidに送信されるメッセージは毎分最大2000
- すべてのWebSocket接続を通じて同時進行中のポストメッセージは最大100
rpc.hyperliquid.xyz/evmのEVM JSON-RPCリクエストは毎分最大100。他のJSON-RPCプロバイダーにはより洗練されたレート制限ロジックとアーカイブノード機能があることに注意してください。
最も低いレイテンシのリアルタイムデータにはWebSocketを使用してください。フル機能の例については、Python SDKを参照してください。
アドレスベースの制限
アドレスベースの制限はユーザーごとに適用され、サブアカウントは個別のユーザーとして扱われます。
レート制限ロジックでは、アドレス作成以来の累積取引量1 USDCにつき1リクエストが許可されます。例えば、注文額100 USDCの場合、これは1%の約定率を要求します。各アドレスは10000リクエストの初期バッファーから始まります。レート制限がかかっている場合、アドレスには10秒ごとに1リクエストが許可されます。キャンセルには累積制限 min(limit + 100000, limit * 2) があり、ここで limit は他のアクションのデフォルト制限です。これにより、アドレスベースのレート制限に達しても、未約定の注文をキャンセルすることは引き続き可能です。このレート制限はアクションのみに適用され、infoリクエストには適用されないことに注意してください。
各ユーザーには、ボリューム5M USDCごとに1注文が追加される、デフォルトで1000の未約定注文制限があり、合計5000の未約定注文が上限です。同じユーザーの他の未約定注文が少なくとも1000ある状態で注文が出されると、reduce-only注文またはトリガー注文の場合は拒否されます。
高い混雑時には、アドレスはブロックスペースのうち、前日のMakerシェア割合の2倍までに制限されます。Makerシェアは、そのアセットの手数料ティアーに対するボリューム貢献と同じ係数でスケーリングされます。例えば、成長モードのHIP-3アセットはこのレート制限に対するカウントが少なくなります。MakerシェアはUTC日付ごとに1回計算されます。したがって、高トラフィック時には、結果が既にAPI経由で返されているキャンセルを再送信しないことが有効です。混雑時には、バッチアクションのウェイトはバッチサイズとアクションごとの定数ウェイトの両方に比例します。したがって、キャンセルまたは注文をまとめてバッチ化することで、そのウェイトを厳密に減らし、レート制限の使用量を削減できます。
バッチリクエスト
n 件の注文（またはキャンセル）を含むバッチリクエストは、IPベースのレート制限では1リクエストとして扱われますが、アドレスベースのレート制限では n リクエストとして扱われます。