Rate limits

The following rate limits apply per IP address:

• REST requests share an aggregated weight limit of 1200 per minute.

  • All documented exchange API requests have a weight of 1 + floor(batch_length / 40). For example, unbatched actions have weight 1 and a batched order request of length 79 has weight 2. Here, batch_lengthis the length of the array in the action, e.g. the number of orders in a batched order action.

  • The following info requests have weight 2: l2Book, allMids, clearinghouseState, orderStatus, spotClearinghouseState, exchangeStatus.

  • The following info requests have weight 60: userRole .

  • All other documented info requests have weight 20.

  • All explorer API 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 rate limits

The rate limiting logic will allow 1 request per 1 USDC traded cumulatively since address inception.

Using an order value of 100 USDC, this only requires a fill rate of 1%.

Each address starts with an initial buffer of 10000 requests. When rate limited, an address will still be 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 will still allow open orders to be canceled.

Note that this rate limit only applies to actions, not info requests.

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.