Rate limits de Hyperliquid: guía 2026 de pesos REST, topes WebSocket y presupuesto por dirección

En resumen: Hyperliquid te limita en dos capas. Por IP, las llamadas REST comparten un presupuesto de 1.200 de peso por minuto (la mayoría de info cuestan 20; algunas cuestan 2; userRole cuesta 60). Además, cada dirección de trading tiene un presupuesto de acciones según el volumen acumulado (buffer inicial de 10.000 peticiones). Los WebSockets tienen topes propios (10 conexiones, 1.000 suscripciones, 10 usuarios únicos). Si haces polling de muchas wallets, chocarás con el techo — por eso existe un tracker de solo lectura como Hyperfolio.

Si montas un bot, un dashboard o un tracker de wallets en Hyperliquid, te encontrarás con los rate limits antes que con cualquier rareza de la API. La documentación es precisa, pero está repartida entre pesos REST, topes de WebSocket y límites por dirección. Esta guía junta los números, enseña cuánto cuesta un bucle de polling realista y cuándo conviene dejar de sondear la API y usar un tracker ya hecho.

Las tres capas de rate limit en Hyperliquid

No hay un único “N peticiones por segundo”. Los límites se apilan:

1. Peso REST por IP — cada llamada HTTP consume peso de un cubo compartido de 1.200 por minuto para esa IP.
2. Topes de conexión y suscripción WebSocket — independientes del peso REST; fáciles de romper si abres un socket por moneda o por usuario.
3. Límites de acciones por dirección — aplican a acciones firmadas de trading (órdenes, cancels, etc.), no a lecturas públicas info. Las subcuentas cuentan como usuarios distintos.

Las lecturas públicas de mercado y cuenta (info) son gratis en dinero, pero no ilimitadas. Las acciones de escritura siguen consumiendo peso de IP por HTTP y, además, el presupuesto por dirección.

Presupuesto REST: 1.200 de peso por minuto por IP

Todas las peticiones REST documentadas de una IP comparten un límite agregado de 1.200 por minuto. El peso depende del endpoint:

Clase de petición	Peso	Notas
Acciones de exchange (órdenes, cancels…)	1 + floor(batch_length / 40)	Acción sin batch = 1; un batch de 79 órdenes = 2
l2Book, allMids, clearinghouseState, orderStatus, spotClearinghouseState, exchangeStatus	2	Lecturas baratas — aun así suman si haces polling cada segundo
userRole	60	Cara; evítala en bucles calientes
Resto de info documentadas	20	Por defecto para fills, funding, meta, velas…
API de explorer	40	blockList además tiene recargo por bloque

Varios endpoints info añaden peso extra por cada 20 ítems devueltos: recentTrades, historicalOrders, userFills, userFillsByTime, fundingHistory, userFunding, nonUserFundingUpdates, twapHistory, userTwapSliceFills, userTwapSliceFillsByTime, delegatorHistory, delegatorRewards, validatorStats. candleSnapshot añade peso por cada 60 velas. Las descargas históricas largas pesan mucho más que la etiqueta “peso 20” — ver la guía de datos históricos.

Qué te dan realmente 1.200 de peso

Presupuestos concretos en el límite de IP (aproximados, sin recargos por ítems):

• Clearinghouse / mids / libro L2: peso 2 → unas 600 llamadas/minuto si solo haces eso (10/segundo).
• Info típica (fills, funding, meta): peso 20 → unas 60 llamadas/minuto.
• userRole: peso 60 → unas 20 llamadas/minuto.
• Bucle de tracker mixto: un clearinghouseState (2) + un userFillsByTime (20+) por wallet → del orden de ~50 wallets por minuto antes de vaciar el cubo, menos si las páginas de fills son largas.

Las peticiones de exchange en batch cuentan como una petición con peso de IP (con la fórmula de batch), pero como n peticiones en el límite por dirección. Esa asimetría importa a los market makers que agrupan cancels.

Límites de WebSocket (aparte del peso REST)

Topes oficiales:

• Máximo 10 conexiones WebSocket
• Máximo 30 conexiones nuevas por minuto
• Máximo 1.000 suscripciones
• Máximo 10 usuarios únicos en suscripciones ligadas a usuario
• Máximo 2.000 mensajes enviados a Hyperliquid por minuto entre todos los sockets
• Máximo 100 mensajes post en vuelo a la vez entre todos los sockets

Mainnet: wss://api.hyperliquid.xyz/ws. Testnet: wss://api.hyperliquid-testnet.xyz/ws. El servidor cierra la conexión si no te ha enviado un mensaje en 60 segundos — manda {"method":"ping"} y espera {"channel":"pong"} en canales silenciosos. Los clientes automáticos deben reconectar; los cortes pueden ocurrir sin aviso, y los datos perdidos vuelven en el snapshot de ack o vía el info correspondiente.

La regla de “10 usuarios únicos” tumba los trackers multi-wallet ingenuos: no puedes suscribirte a userFills / clearinghouseState de docenas de direcciones en una sola IP. Para monitorizar carteras a escala, o repartes IPs con cuidado o usas un producto que ya agrega estado público — Hyperfolio está hecho para eso y nunca pide claves.

Límites por dirección (solo acciones de trading)

Aplican por usuario; las subcuentas son usuarios separados. No aplican a lecturas info.

• Presupuesto aproximado de 1 petición por cada 1 USDC de volumen acumulado desde el inicio de la dirección, con un buffer inicial de 10.000 peticiones.
• Ejemplo de la documentación: una orden de nocional 100 USDC implica necesitar del orden de un 1% de fill rate respecto a ese modelo de presupuesto a lo largo del tiempo.
• Cuando estás limitado, la dirección puede enviar una petición cada 10 segundos.
• Los cancels tienen un techo acumulado mayor: min(limit + 100000, limit * 2), para poder cerrar riesgo aunque el presupuesto normal esté agotado.

Tope de órdenes abiertas: 1.000 por defecto, más una orden extra por cada 5M USDC de volumen, con máximo 5.000. Con al menos 1.000 órdenes abiertas, las nuevas reduce-only o trigger pueden rechazarse.

En congestión alta, las direcciones quedan limitadas a unos 2× su maker share del día anterior del espacio de bloque (escalado como la contribución de volumen a los fee tiers; los activos HIP-3 en growth mode cuentan menos). Reenviar cancels cuyo resultado ya llegó malgasta ese presupuesto.

Límite de modo (docs de account abstraction): unified account y portfolio margin están limitados a 50.000 acciones de usuario al día; el modo standard no tiene ese tope diario. Las direcciones que cobran builder fees deben permanecer en modo standard.

Ejemplo: polling de 20 wallets cada 5 segundos

Supón que refrescas clearinghouseState (peso 2) de 20 direcciones cada 5 segundos:

• Llamadas por minuto: 20 × (60/5) = 240
• Peso por minuto: 240 × 2 = 480 — aceptable por sí solo

Añade un userFillsByTime (peso 20 + recargo por ítems) una vez por minuto y wallet:

• Peso extra: 20 × 20 = 400 antes de recargos
• Total ≈ 880 — sigue bajo 1.200 hasta que crezcan las páginas de fills o sumes metaAndAssetCtxs, funding, spot, etc.

Cambia el intervalo a 1 segundo para una UI “en vivo” y solo el clearinghouse ya son 20 × 60 × 2 = 2.400 de peso — el doble del presupuesto de IP. Ahí empiezan los 429 de casi todos los trackers caseros. Mejor WebSockets para las pocas direcciones que de verdad necesitas en vivo, cachea mids/OI y, para el resto, usa un tracker que ya resolvió el fan-out.

import time, requests

INFO = "https://api.hyperliquid.xyz/info"
WALLETS = ["0xabc…", "0xdef…"]  # lista pequeña por IP

def clearinghouse(user: str):
    r = requests.post(INFO, json={"type": "clearinghouseState", "user": user}, timeout=30)
    r.raise_for_status()
    return r.json()

# ~peso 2 por llamada. Ritmo para quedar bajo ~1000/min de margen.
while True:
    for w in WALLETS:
        state = clearinghouse(w)
        equity = state.get("marginSummary", {}).get("accountValue")
        print(w, equity)
        time.sleep(0.2)  # pacing tosco; en producción usa un token bucket
    time.sleep(5)

En bots con firma, mantén limpias las agent wallets y los nonces (ver la guía de API wallet) y trata los cancels como presupuesto sagrado cerca del tope por dirección.

Cómo quedarte bajo el límite en la práctica

1. Prefiere WebSocket al polling REST para mids, trades, L2, fills y clearinghouse de los pocos usuarios que te importan.
2. Cachea la info pesada — meta, contextos de activo, OI y fee tiers cambian despacio frente a los marks.
3. Pagina el historial con cabeza — usa archivos S3 para históricos masivos en lugar de martillear el explorer (datos históricos).
4. Agrupa acciones de exchange cuando reduzca peso de IP, recordando que el límite por dirección sigue contando cada hija.
5. Reparte lecturas en varias IPs solo si hace falta — y nunca compartas una granja de sockets entre usuarios ilimitados (tope de 10).
6. Para trackear el portfolio, sáltate la infra — pega direcciones en app.hyperfolio.fun (PWA gratis, solo lectura, sin API keys).

Hyperfolio frente a montar tu propio poller

Montar una vista privada de PnL es un fin de semana… hasta que entran subcuentas, funding, fees, DEX HIP-3, reconexiones y rate limits. Hyperfolio ya muestra equity, perps abiertos, PnL cerrado, funding y libros multi-venue con datos públicos. No quemas el presupuesto de IP, no guardas claves y puedes ver master + subcuentas juntas (ver subcuentas y varias wallets).

Si operas en Hyperliquid, usa el código de referido HYPERFOLIO para un 4% de descuento en comisiones en tus primeros 25 M$ de volumen: app.hyperliquid.xyz/join/HYPERFOLIO. Detalles en la guía de referidos.

FAQ

¿Cuál es el rate limit REST de Hyperliquid?

El tráfico REST documentado comparte 1.200 de peso por minuto por IP. Los pesos varían (2, 20 o 60 en info habituales; las acciones de exchange usan 1 + floor(batch/40)).

¿Las peticiones info cuentan para el límite por dirección?

No. Ese límite es solo de acciones de trading. Las lecturas info consumen presupuesto de IP (y de WebSocket).

¿Cuántas conexiones WebSocket puedo abrir?

Hasta 10 conexiones, 30 nuevas por minuto, 1.000 suscripciones y 10 usuarios únicos en feeds de usuario.

¿Por qué me limitan tras un pico de cancels y órdenes?

Seguramente agotaste el presupuesto de dirección (por volumen) aunque el peso de IP pareciera bien. Los cancels tienen techo más alto, pero no infinito. Cuando estás limitado, baja a una petición / 10 segundos.

¿Cómo trackeo muchas wallets de Hyperliquid sin pegarme al límite?

No te suscribas a docenas de usuarios en una IP. Usa un agregador de solo lectura como Hyperfolio, o un worker con cola, caché, WebSockets para una allowlist pequeña y S3 para el historial.

Sáltate la cinta de rate limits: añade tus wallets en Hyperfolio y mira el PnL en vivo sin API keys. ¿Operas en Hyperliquid? Código HYPERFOLIO para un 4% menos de comisiones.