Hyperliquid rate limits

System 1: per-IP limits

REST: a weight budget of 1,200 per minute

Every REST request costs weight against a 1,200-point-per-minute budget per IP:

• Exchange (trading) requests cost 1 + floor(batch_length / 40). An unbatched order is 1 point; a batch of 79 orders is 2.
• Cheap info requests cost 2 points: l2Book, allMids, clearinghouseState, orderStatus, spotClearinghouseState, exchangeStatus.
• Most other info requests cost 20 points, and userRole costs 60.
• History endpoints carry per-item surcharges. userFills, userFillsByTime, historicalOrders, fundingHistory, userFunding, recentTrades, and friends add 1 point per 20 items returned; candleSnapshot adds 1 per 60 items.
• Explorer requests cost 40, with extra weight on blockList and on old, cold blocks — the official docs themselves say to use the S3 bucket for bulk instead. (Agreed. More on that below.)

The detail that actually hurts in production: reads and writes share the same budget. Info requests and exchange requests draw from one 1,200-point per-IP pool, so a data-hungry process starves your own order flow. Ten full-page userFills calls (120 points each: 20 base + 1 per 20 fills) consume the entire minute — and the next request from that IP gets throttled even if it's an order you badly need to place. You can exhaust your write allocation without writing anything.

Websocket: connection and subscription caps

Per IP: 10 connections, 30 new connections per minute, 1,000 total subscriptions, 2,000 messages sent per minute, 100 simultaneous inflight post messages — and the sleeper that breaks builder apps: a maximum of 10 unique users across all user-specific subscriptions. A dashboard tracking 50 wallets cannot exist on the official websocket, no matter how it shards connections from one IP.

EVM RPC

The public rpc.hyperliquid.xyz/evm endpoint allows 100 JSON-RPC requests per minute.

System 2: per-address limits (requests you earn by trading)

Trading actions — orders, cancels, modifies — are limited per address, not per IP, and the budget is cumulative: 1 request for every 1 USDC ever traded by that address, with a starting buffer of 10,000 requests. With 100 USDC average order size, you break even at a 1% fill rate. Run out, and the address is throttled to one request per 10 seconds.

Details that matter in production:

• Cancels get extra headroom — the cancel budget is min(limit + 100,000, limit × 2), so a rate-limited account can still pull its open orders.
• Batching doesn't help here. A batch of n orders counts as 1 request against the IP budget but n against the address budget.
• This applies to actions only. Info requests never touch the address-based limit.
• Open orders have their own cap: 1,000 per user, plus one per 5M USDC of volume, hard-capped at 5,000. Past 1,000 open orders, new reduce-only and trigger orders are rejected.

System 3: congestion limits (block space by maker share)

During high congestion, each address is limited to 2× its previous-day maker share of block space, computed once per UTC date and scaled the same way volume counts toward fee tiers (so HIP-3 assets in growth mode count less). Practical consequence: under load, don't resend cancels whose results already came back — you're spending scarce block space on no-ops.

The wall that isn't a rate limit: 10,000 fills

userFills and userFillsByTime paginate by recency in pages of up to 2,000 — and only the most recent 10,000 fills per address are retrievable at all. For an active trader that's days of history, sometimes hours. No amount of patience, batching, or IP rotation produces fill number 10,001. It's not a throughput limit; the data simply isn't served.

Where each limit actually bites

• Wallet trackers and analytics dashboards hit the 10-unique-user websocket cap first, then the 10k fills wall.
• Backfills and research hit the per-item weight surcharges, then the wall.
• All-market consumers (every trade, every book) hit the 1,000-subscription cap — there is no official firehose.
• Trading systems that poll their own data hit the read/write contention: every info request spends budget that order placement needs.
• Market makers live inside the address-based and congestion systems, where request capacity is a function of volume and yesterday's maker share.

The token-based alternative

Hydromancer's limits attach to an API key, not an IP and not your trading volume. They're tiered (Starter / Growth / Scale), published in full in the docs, and sized for the workloads above:

* Lower on Starter by design: multi-coin and multi-address subscriptions mean one subscribe message does the work of dozens, so the message budget goes much further than the official one-coin-per-subscription model.

There's a second-order win hiding in the limit-basis row: reads move off your trading IP entirely. Every info request you send us is a point handed back to the official budget — which then does the only thing it must do: place and cancel orders.

To be clear about our side of the ledger: we have rate limits too, and we publish every number — default request weight is 2, heavier endpoints run 5–20 points, and the REST market-data endpoints (snapshots, l4Book) have a deliberately tight separate limiter (5 calls per 10 minutes; l4Book 10 per 5). You can't capacity-plan against “contact us,” so the full tables live in the docs, current as of today. Per-feed coin caps (e.g. l4BookUpdates up to 200 coins on Scale, tpslUpdates up to 200, bbo up to 200) are there too.

The requests you shouldn't be making at all

A chunk of rate-limit pain is polling for things that shouldn't be polled and backfilling through an API that was never meant for bulk:

• Backfills belong in the archive. Every fill, 1-second candle, and daily snapshot since launch is free in Reservoir — S3, no API key, no rate limit beyond what AWS can serve you. Walkthrough: How to get Hyperliquid historical data — for free.
• Live data belongs on a stream. Polling l2Book at 2 points a call is strictly worse than one websocket subscription per block. Full channel map: Hyperliquid data feeds, explained.

Archive for the past, streams for the present, REST for point lookups. Most “rate limit problems” dissolve into that sentence.

FAQ