Rate limits
The following rate limits apply per IP address:
REST requests share an aggregated weight limit of 1200 per minute.
All documented
exchangeAPI requests have a weight of1 + floor(batch_length / 40). For example, unbatched actions have weight1and a batched order request of length 79 has weight2. Here,batch_lengthis the length of the array in the action, e.g. the number of orders in a batched order action.The following
inforequests have weight 2:l2Book, allMids, clearinghouseState, orderStatus, spotClearinghouseState, exchangeStatus.The following
inforequests have weight 60:userRole.All other documented
inforequests have weight 20.All
explorerAPI requests have a weight of 40.
Maximum of 100 websocket connections
Maximum of 1000 websocket subscriptions
Maximum of 10 unique users across user-specific websocket subscriptions
Maximum of 2000 messages sent to Hyperliquid per minute across all websocket connections
Maximum of 100 simultaneous inflight post messages across all websocket connections
Use websockets for lowest latency realtime data. See the python SDK for a full-featured example.
Address-based limits
Address-based limits apply per user, with sub-accounts treated as separate users.
The rate limiting logic allows 1 request per 1 USDC traded cumulatively since address inception. For example, with an order value of 100 USDC, this requires a fill rate of 1%. Each address starts with an initial buffer of 10000 requests. When rate limited, an address is allowed one request every 10 seconds. Cancels have cumulative limit min(limit + 100000, limit * 2) where limit is the default limit for other actions. This way, hitting the address-based rate limit still allows open orders to be canceled. Note that this rate limit only applies to actions, not info requests.
Each user has an open order limit of 1000 orders.
Batched Requests
A batched request with n orders (or cancels) is treated as one request for IP based rate limiting, but as n requests for address-based rate limiting.
Last updated