速率限制與用戶限制
以下速率限制按 IP 地址適用：
- REST 請求共享每分鐘 1200 的聚合權重限制。
- 所有已記錄在文件中的
exchangeAPI 請求的權重爲1 + floor(batch_length / 40)。例如，非批量操作的權重爲1，長度爲 79 的批量下單請求的權重爲2。這裡的batch_length是 action 中陣列的長度，例如批量下單 action 中的訂單數量。 - 以下
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 存儲桶。 - 最多 10 個 WebSocket 連接
- 每分鐘最多新建 30 個 WebSocket 連接
- 最多 1000 個 WebSocket 訂閱
- 用戶特定的 WebSocket 訂閱中最多 10 個不同用戶
- 所有 WebSocket 連接每分鐘最多向 Hyperliquid 發送 2000 條消息
- 所有 WebSocket 連接上同時進行中（inflight）的 post 消息最多 100 條
rpc.hyperliquid.xyz/evm每分鐘最多 100 個 EVM JSON-RPC 請求。注意，其他 JSON-RPC 提供商擁有更精細的速率限制邏輯以及歸檔節點功能。
要獲得最低延遲的實時數據，請使用 WebSocket。完整的功能示例參見 Python SDK。
基於地址的限制
基於地址的限制按用戶適用，子帳戶被視爲獨立用戶。
速率限制邏輯允許自地址創建以來每累計交易 1 USDC 對應 1 次請求。例如，訂單價值爲 100 USDC 時，成交率需達到 1%。每個地址初始擁有 10000 次請求的緩衝額度。被限速時，地址每 10 秒允許一次請求。撤單的累計限制爲 min(limit + 100000, limit * 2)，其中 limit 是其他操作的預設限制。這樣，即使觸達基於地址的速率限制，仍然可以撤銷掛單。注意，該速率限制僅適用於操作（action），不適用於 info 請求。
每個用戶預設的掛單限制爲 1000 筆，且每 5M USDC 的交易量增加 1 筆，總計上限爲 5000 筆掛單。當某用戶已至少有 1000 筆其他掛單時再下單，如果該訂單是只減倉訂單或觸發訂單，則會被拒絕。
在高擁堵期間，地址被限制最多使用其前一日 Maker 份額佔比 2 倍的區塊空間。Maker 份額按與該資產對手續費等級的交易量貢獻相同的係數進行縮放。例如，處於增長模式的 HIP-3 資產對該速率限制的計入更少。Maker 份額按每個 UTC 日期計算一次。因此，在高流量期間，對於已通過 API 返回結果的撤單，不再重複發送會有所幫助。在擁堵期間，批量操作的權重同時與其批量大小和每操作的固定權重成正比。因此，將撤單或訂單合併批量處理會嚴格降低其權重並減少速率限制的佔用。
批量請求
包含 n 筆訂單（或撤單）的批量請求在基於 IP 的速率限制中被視爲 1 次請求，但在基於地址的速率限制中被視爲 n 次請求。