Hyperliquid Rate Limits 2026: REST, WebSocket & Address Caps
Hyperliquid rate limits: 1,200 REST weight/min per IP, info weights, WebSocket caps, address action budgets, worked polling examples and when to use a read-only tracker.
Hyperliquid Rate Limits Guide 2026: REST Weights, WebSocket Caps and Address Budgets
The short version: Hyperliquid rate-limits you in two layers. Per IP, REST calls share a 1,200 weight budget per minute (most
infocalls cost 20; a few cost 2;userRolecosts 60). Separately, each trading address has an action budget based on cumulative volume (starting buffer 10,000 requests). WebSockets have their own caps (10 connections, 1,000 subscriptions, 10 unique users). Hitting the ceiling is normal if you poll many wallets — which is why a read-only tracker like Hyperfolio exists.
If you are building a bot, a dashboard or a wallet tracker on Hyperliquid, you will meet rate limits before you meet anything exotic in the API. The docs are precise but spread across REST weights, WebSocket caps and address-based action limits. This guide puts the numbers in one place, shows what a realistic polling loop costs, and explains when you should stop polling and use a purpose-built tracker instead.
The three rate-limit layers on Hyperliquid
Hyperliquid does not use a single “N requests per second” number. Limits stack:
- IP / REST weight — every HTTP call to the API burns weight from a shared 1,200-per-minute bucket for that IP.
- WebSocket connection and subscription caps — independent of REST weight, but easy to blow if you open a socket per coin or per user.
- Address-based action limits — apply to signed trading actions (orders, cancels, etc.), not to public
inforeads. Sub-accounts count as separate users.
Public market and account reads (info) are free in the monetary sense, but they are not unlimited. Write actions are free of REST weight in the same way only if you stay under the address budget — and they still consume IP weight when sent over HTTP.
REST weight budget: 1,200 per minute per IP
All documented REST requests on an IP share one aggregated weight limit of 1,200 per minute. Weights depend on the endpoint:
| Request class | Weight | Notes |
|---|---|---|
| Exchange actions (orders, cancels, …) | 1 + floor(batch_length / 40) | Unbatched action = 1; a batch of 79 orders = 2 |
l2Book, allMids, clearinghouseState, orderStatus, spotClearinghouseState, exchangeStatus | 2 | Cheap reads — still add up if you poll every second |
userRole | 60 | Expensive; avoid in hot loops |
Other documented info requests | 20 | Default for fills, funding, meta, candles, … |
| Explorer API | 40 | blockList also has a per-block surcharge |
Several info endpoints add extra weight per 20 items returned: recentTrades, historicalOrders, userFills, userFillsByTime, fundingHistory, userFunding, nonUserFundingUpdates, twapHistory, userTwapSliceFills, userTwapSliceFillsByTime, delegatorHistory, delegatorRewards, validatorStats. candleSnapshot adds weight per 60 candles returned. Large history pulls are therefore much heavier than a single “weight 20” label suggests — see our historical data guide for candle and funding pagination.
What 1,200 weight actually buys you
Concrete budgets at the IP limit (approximate, ignoring item surcharges):
- Clearinghouse / mids / L2 book: weight 2 → about 600 calls/minute if that is all you do (10/second).
- Typical info (fills, funding, meta): weight 20 → about 60 calls/minute.
- userRole: weight 60 → about 20 calls/minute.
- Mixed tracker loop: one
clearinghouseState(2) + oneuserFillsByTime(20+) per wallet → you can afford on the order of ~50 wallets per minute before the IP bucket empties, less once fill pages get long.
Batched exchange requests count as one IP-weighted request (with the batch formula above) but as n requests against the address-based limit. That asymmetry matters for market makers who batch cancels.
WebSocket limits (separate from REST weight)
Official caps for WebSocket use:
- Maximum 10 WebSocket connections
- Maximum 30 new WebSocket connections per minute
- Maximum 1,000 subscriptions
- Maximum 10 unique users across user-specific subscriptions
- Maximum 2,000 messages sent to Hyperliquid per minute across all sockets
- Maximum 100 simultaneous in-flight post messages across all sockets
Mainnet URL: wss://api.hyperliquid.xyz/ws. Testnet: wss://api.hyperliquid-testnet.xyz/ws. The server closes a connection if it has not sent you a message for 60 seconds — send {"method":"ping"} and expect {"channel":"pong"} on quiet channels. Automated clients must reconnect; disconnects can happen without announcement, and missed data is available again in the snapshot ack or via the matching info request.
The “10 unique users” rule is the one that kills naive multi-wallet trackers: you cannot subscribe to userFills / clearinghouseState for dozens of addresses on one IP. For portfolio monitoring at scale, either fan out IPs carefully or use a product that already aggregates public state — Hyperfolio is built for that and never asks for keys.
Address-based limits (trading actions only)
Address limits apply per user; sub-accounts are separate users. They do not apply to info reads.
- Budget roughly 1 request per 1 USDC of cumulative traded volume since the address started, with an initial buffer of 10,000 requests.
- Example from the docs: an order notionally worth 100 USDC implies you need about a 1% fill rate against that budget model over time.
- When rate-limited, the address may send one request every 10 seconds.
- Cancels get a higher cumulative ceiling:
min(limit + 100000, limit * 2), so you can still flatten risk when the normal action budget is exhausted.
Open-order cap: default 1,000 open orders, plus one extra order per 5M USDC of volume, capped at 5,000. With at least 1,000 open orders already, new reduce-only or trigger orders can be rejected.
During high congestion, addresses are limited to roughly 2× their previous-day maker share of block space (scaled like fee-tier volume contribution; HIP-3 growth-mode assets count less). Resending cancels whose results already came back wastes that budget.
Related mode limit from account-abstraction docs: unified account and portfolio margin modes are limited to 50,000 user actions per day; standard mode has no such daily action cap. Builder fee recipient addresses must stay in standard mode.
Worked example: polling 20 wallets every 5 seconds
Suppose you refresh clearinghouseState (weight 2) for 20 addresses every 5 seconds:
- Calls per minute:
20 × (60/5) = 240 - Weight per minute:
240 × 2 = 480— fine on its own
Add a userFillsByTime (weight 20, plus item surcharge) once a minute per wallet:
- Extra weight:
20 × 20 = 400before surcharges - Total ≈ 880 — still under 1,200 until fill pages grow or you add
metaAndAssetCtxs, funding, spot state, etc.
Flip the interval to 1 second for “live” UI and the clearinghouse leg alone is 20 × 60 × 2 = 2,400 weight — double the IP budget. That is the moment most hobby trackers start getting 429s. Prefer WebSockets for the few addresses you truly need live, cache mids/OI, and for everything else use a tracker that already solved fan-out.
import time, requests
INFO = "https://api.hyperliquid.xyz/info"
WALLETS = ["0xabc…", "0xdef…"] # keep the list small per IP
def clearinghouse(user: str):
r = requests.post(INFO, json={"type": "clearinghouseState", "user": user}, timeout=30)
r.raise_for_status()
return r.json()
# ~weight 2 per call. Pace so total weight stays under ~1000/min headroom.
while True:
for w in WALLETS:
state = clearinghouse(w)
equity = state.get("marginSummary", {}).get("accountValue")
print(w, equity)
time.sleep(0.2) # crude pacing; use a real token bucket in production
time.sleep(5)
For signed trading bots, keep agent wallets and nonces clean (see the API wallet guide) and treat cancels as sacred budget when you are near the address cap.
Practical ways to stay under the cap
- Prefer WebSocket over REST polling for mids, trades, L2, user fills and clearinghouse updates on the few users you care about.
- Cache heavy info —
meta, asset contexts, OI and fee tiers change slowly compared to marks. - Page history deliberately — use S3 archives for bulk history instead of hammering explorer or long fill windows (historical data guide).
- Batch exchange actions when it reduces IP weight, but remember address limits still count each child action.
- Split read-only workloads across IPs only if you must — and never share one socket farm across unlimited user subscriptions (10-user cap).
- For portfolio tracking, skip the infra — paste addresses into app.hyperfolio.fun (free PWA, read-only, no API keys).
Hyperfolio vs rolling your own poller
Building a private PnL view is a weekend project until you add sub-accounts, funding, fees, HIP-3 DEXs, reconnects and rate limits. Hyperfolio already shows equity, open perps, closed PnL, funding and multi-venue books from public data. You do not burn your IP budget, you do not store keys, and you can watch master + sub-accounts together (see sub-accounts and multiple wallets).
If you trade on Hyperliquid, apply referral code HYPERFOLIO for 4% off fees on your first $25M of volume: app.hyperliquid.xyz/join/HYPERFOLIO. Details in the referral guide.
FAQ
What is the Hyperliquid REST rate limit?
Documented REST traffic shares 1,200 weight per minute per IP. Endpoint weights differ (2, 20 or 60 for common info calls; exchange actions use 1 + floor(batch/40)).
Do info requests count toward address-based limits?
No. Address-based limits apply to trading actions. info reads only consume IP (and WebSocket) budgets.
How many WebSocket connections can I open?
Up to 10 connections, 30 new connections per minute, 1,000 subscriptions and 10 unique users on user-specific feeds.
Why do I get rate-limited after a burst of cancels and orders?
You likely exhausted the address budget (volume-based) even if IP weight looked fine. Cancels have a higher ceiling than other actions, but it is not infinite. Back off to one request / 10 seconds when limited.
How do I track many Hyperliquid wallets without hitting limits?
Do not subscribe to dozens of users on one IP. Use a read-only aggregator such as Hyperfolio, or design a queued worker with caching, WebSockets for a small allowlist and S3 for history.
Skip the rate-limit treadmill: add your wallets on Hyperfolio and read live PnL without API keys. Trading on Hyperliquid? Code HYPERFOLIO for 4% off fees.
Try Hyperfolio for free
Track your Hyperliquid portfolio in real time with PnL, Smart Money, Markets, Perp Calculator, multi-venue portfolio and push alerts.
HYPERLIQUID
-4% feesTrade on Hyperliquid · 4% off fees
Hyperfolio is an independent app — no ads, no commissions, no sponsors. Referrals are our only funding; we truly appreciate you trading through our link.
Free for you · keeps Hyperfolio running
Related articles
Hyperliquid Historical Data 2026: Candles, Funding & S3
Where to get Hyperliquid historical data: candleSnapshot candles and the 5,000-candle limit, hourly funding history with pagination, your own fills, the S3 archives, rate limits and a Python script that exports candles to CSV.
GuideHyperliquid Open Interest 2026: Read OI, Caps & API
What open interest means on Hyperliquid, how to convert it to USD, how to read OI with price and funding, why orders get rejected at the open interest cap, HIP-3 caps, and a Python script to pull OI from the public API.
GuideHyperliquid Testnet Guide 2026: Faucet, API & Chain ID
How to use Hyperliquid testnet: claim 1,000 mock USDC from the faucet (mainnet deposit required), fix the email-login address issue, switch the API and Python SDK, and add HyperEVM testnet (chain ID 998).
GuideHyperliquid TP/SL Guide 2026: Take Profit & Stop Loss
How Hyperliquid TP/SL works: mark-price triggers, 10% market slippage tolerance, limit exits, position vs parent-order (OCO) attachment, API grouping, and common fill mistakes.
GuideHyperliquid TWAP Orders Guide 2026: Duration, Slippage & API
How Hyperliquid TWAP works: 5 minutes to 7 days, $100 minimum, 30s interval floor, 3% suborder slippage, ±20% randomize, catch-up caps, and the twapOrder / twapCancel API.
GuideHyperliquid Slippage & Price Impact Guide
Learn what slippage and price impact cost you on Hyperliquid, how to estimate them from the order book and which order types (limit, IOC, TWAP) reduce them.