Hyperfolio
Guide

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.

October 19, 20269 min

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 info calls cost 20; a few cost 2; userRole costs 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:

  1. IP / REST weight — every HTTP call to the API burns weight from a shared 1,200-per-minute bucket for that IP.
  2. WebSocket connection and subscription caps — independent of REST weight, but easy to blow if you open a socket per coin or per user.
  3. Address-based action limits — apply to signed trading actions (orders, cancels, etc.), not to public info reads. 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 classWeightNotes
Exchange actions (orders, cancels, …)1 + floor(batch_length / 40)Unbatched action = 1; a batch of 79 orders = 2
l2Book, allMids, clearinghouseState, orderStatus, spotClearinghouseState, exchangeStatus2Cheap reads — still add up if you poll every second
userRole60Expensive; avoid in hot loops
Other documented info requests20Default for fills, funding, meta, candles, …
Explorer API40blockList 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) + one userFillsByTime (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 = 400 before 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

  1. Prefer WebSocket over REST polling for mids, trades, L2, user fills and clearinghouse updates on the few users you care about.
  2. Cache heavy info — meta, asset contexts, OI and fee tiers change slowly compared to marks.
  3. Page history deliberately — use S3 archives for bulk history instead of hammering explorer or long fill windows (historical data guide).
  4. Batch exchange actions when it reduces IP weight, but remember address limits still count each child action.
  5. Split read-only workloads across IPs only if you must — and never share one socket farm across unlimited user subscriptions (10-user cap).
  6. 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% fees

Trade 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.

Use referral

Free for you · keeps Hyperfolio running

Related articles