Quicknode

12 de junio de 2026 — 10 minutos de lectura

On June 9, 2026, Hyperliquid's core team announced that several public WebSocket API feeds will push data less frequently after the next network upgrade. On June 11, 2026, the team adjusted the rollout based on user feedback: webData2 mantendrá su intervalo de pulsación actual de 5 segundos durante una actualización más de la red, según lo establecido l2Book pasará a 20 niveles cada 2 segundos, antes de pasar posteriormente a 5 segundos, y un nuevo fastAssetCtxs El feed de WebSocket conservará las diferencias de precios de referencia de 5 segundos para las interfaces.

Las fuentes de datos afectadas siguen incluyendo la profundidad del libro de órdenes, los precios medios, el contexto de los activos, el contexto de todos los activos de los DEX y webData2, que, según las previsiones, seguirá migrando a webData3.

En el caso de los paneles de control, los monitores de carteras y las vistas destinadas a los usuarios, los nuevos intervalos pueden resultar aceptables. Sin embargo, en el caso de los sistemas de negociación automatizados, estos intervalos modifican el modelo de datos. Una estrategia que cotice, calcule el volumen, cancele o derive órdenes a partir de instantáneas públicas de WebSocket necesita ahora un plano de datos diferente.

Hyperliquid's team was direct about the expected path for this workload:

En esta entrada se explica qué va a cambiar, por qué es importante para los bots y cómo trasladar las cargas de trabajo de Hyperliquid , que son sensibles a la latencia, a una infraestructura gestionada con Quicknode.

¿Qué ha cambiado en la API pública de WebSocket de Hyperliquid?

El l2Book El cambio es lo más importante para las estrategias automatizadas. Sin fast: true, la API pública devuelve 20 niveles cada 2 segundos tras la próxima actualización, y se prevé que posteriormente este intervalo pase a ser de 5 segundos. Con fast: true, devuelve 5 niveles cada 0,5 segundos. Ninguna de las dos opciones ofrece un libro completo en tiempo real para estrategias que dependen de la profundidad, el comportamiento de la cola o los cambios rápidos en el spread.

No se trata de una interrupción del servicio ni de un cambio radical en el sentido habitual. Es una línea divisoria entre la infraestructura pública compartida y el perfil de datos que necesitan los sistemas de negociación automatizados.

¿Por qué es importante que las actualizaciones de WebSocket sean más lentas para los bots de trading?

Para un bot, un libro obsoleto no supone un inconveniente. Lo interpreta como una entrada incorrecta.

Los creadores de mercado necesitan datos actualizados sobre la profundidad del mercado para cotizar en función del inventario en tiempo real y el spread. Los bots de ejecución necesitan los precios medios actuales y la presión del libro de órdenes para dimensionar las órdenes. Las estrategias de liquidación, arbitraje y basis necesitan que la diferencia entre la última instantánea y el bloque actual sea lo más pequeña posible.

Cuando un libro se actualiza cada 2 o 5 segundos, la estrategia no solo va con retraso respecto a ese intervalo, sino que actúa en función de una situación de mercado diferente. Esto afecta a:

• Plazo de presentación de ofertas y plazo de cancelación

• Cálculos del diferencial, el deslizamiento y la selección adversa

• Determinación del tamaño de las posiciones y controles de riesgo

• Indicadores de liquidación y financiación que activan órdenes

• Pruebas retrospectivas que parten de la base de que el flujo de datos es similar al de producción

La API pública puede seguir siendo útil para la interfaz de usuario, la monitorización pasiva y los datos de visualización no críticos. La lógica de negociación que depende de la profundidad de mercado actual requiere una fuente de datos diseñada específicamente para ello, ya sea una suscripción a WebSocket o un flujo de « gRPC ».

¿Qué recomienda « Hyperliquid » a los operadores que utilizan sistemas automatizados?

HyperliquidLa recomendación es ejecutar un nodo sin validación para obtener más niveles o actualizaciones en tiempo real streams. Esto proporciona a los operadores automatizados acceso directo al perfil de datos que necesitan, pero también conlleva tareas de infraestructura: gestión del nodo, actualizaciones, supervisión, gestión de reconexiones, planificación de la capacidad e integración de clientes.

Quicknode es una plataforma de desarrollo de blockchain que proporciona una infraestructura gestionada de Hyperliquid en HyperCore e HyperEVM a través de un único endpoint. Tanto WebSocket como gRPC son compatibles con todos los Hyperliquid endpoint . Para los equipos afectados por este cambio en la API pública, la funcionalidad más relevante es la transmisión en streaming de HyperCore gRPC . No porque WebSocket sea una herramienta inadecuada, sino porque vemos dónde se vuelve frágil a gran escala: tormentas de reconexiones, fragilidad de los flujos basados en paquetes y sobrecarga de la carga útil en suscripciones a múltiples mercados.

Quicknode's Hyperliquid documentos Enumerar la compatibilidad con « gRPC » en todo el conjunto de datos de HyperCore streams, con transmisión bidireccional, una latencia inferior a un milisegundo para los datos de mercado y compresión nativa zstd que puede reducir el ancho de banda en aproximadamente un 70 %. Acceso a /hypercore JSON-RPC, /hypercore WebSocket e HyperCore gRPC requieren el plan Build o superior.

Empieza por consultar la documentación de «Quicknode » (Hyperliquid ) y la referencia de la API de streaming «Hyperliquid » (gRPC ).

¿Qué conjuntos de datos de HyperCore deberían utilizar los operadores automatizados?

La diferencia clave no es solo una plataforma privada endpoint, sino el acceso a los conjuntos de datos de HyperCore, que se adaptan a las cargas de trabajo de negociación automatizada.

QuicknodeLos conjuntos de datos de «Hyperliquid » abarcan operaciones ejecutadas, eventos del ciclo de vida de las órdenes, actualizaciones del libro de órdenes, datos de ejecución TWAP, eventos relacionados con cuentas y saldos, acciones de escritura de HyperCore a HyperEVM, bloques sin procesar, instantáneas del libro de órdenes de nivel 2, instantáneas y diferencias del libro de órdenes de nivel 4, y transacciones del mempool de « testnet ».

Esto es importante porque la opción más adecuada para sustituir una fuente pública de WebSocket depende de la función que desempeñe la estrategia. Un creador de mercado necesita datos distintos a los de un monitor de liquidaciones, y un panel de control necesita datos distintos a los de un enrutador de órdenes.

StreamL2Book para conocer la profundidad del nivel de precios actual

StreamL2Book proporciona una instantánea completa y agregada del libro de órdenes de nivel 2 en cada bloque. Cada mensaje incluye las ofertas de compra y venta actuales por nivel de precio, junto con el volumen total y el número de órdenes en cada nivel.

Uso StreamL2Book cuando tu estrategia requiere información actualizada sobre la profundidad del mercado por nivel de precio sin tener que crear un libro de órdenes local a partir de diferencias incrementales. El flujo admite una profundidad configurable, con n_niveles hasta 100, además de una clasificación opcional por tramos de precios para una agregación más amplia.

En comparación con un servicio público l2Book Un feed que transmite 5 niveles cada 0,5 segundos o 20 niveles cada 2 segundos, antes de pasar posteriormente a intervalos de 5 segundos; esta es la opción más adecuada para la creación de mercado, la supervisión de diferenciales, la ejecución con información sobre la profundidad del mercado y las alertas basadas en el libro de órdenes.

StreamL4Book para el estado de cada pedido individual

StreamL4Book Proporciona el libro de órdenes con un nivel de detalle por orden individual. Al suscribirse, envía una instantánea completa de las ofertas de compra y venta pendientes. A partir de ahí, envía diferencias por bloque.

Uso StreamL4Book cuando los niveles de precios agregados no son suficientes. Entre los ejemplos se incluyen el análisis de colas, los estudios de liquidez a nivel de orden, la investigación sobre la microestructura del mercado y los sistemas que necesitan realizar un seguimiento de las órdenes pendientes individuales, en lugar de limitarse únicamente a los totales a nivel de precios.

StreamL2Book y StreamL4Book Son exclusivas de gRPC. No están disponibles a través de WebSocket ni de JSON-RPC.

¿Cómo deberían adaptar los equipos los bots de « Hyperliquid » al nuevo ritmo?

No es necesario que traslades todas las integraciones de Hyperliquid de una sola vez. Empieza por separar los datos de decisión de los datos de visualización.

1. Clasifica cada suscripción.

   Las fuentes de datos que activan órdenes, cancelaciones, ajustes de tamaño o límites de riesgo deben priorizarse. Las fuentes de datos que alimentan paneles de control, gráficos visibles para el usuario o la supervisión pasiva suelen poder seguir utilizándose a través de WebSocket.

2. Sustituir «público» l2Book para la toma de decisiones de inversión.

   Uso StreamL2Book si tu estrategia requiere profundidad de precios, datos actualizados de los precios de oferta y demanda o cálculos de diferenciales. Utiliza StreamL4Book si se necesita información sobre el estado de un pedido concreto o detalles a nivel de cola.

3. Diseña el comportamiento de reconexión basándote en el modelo de flujo.

   Con StreamL2Book, cada mensaje es una instantánea completa de L2 para ese bloque, por lo que tu consumidor puede actualizar el estado local del nivel de precios con cada actualización. Con StreamL4Book, inicializar a partir de la instantánea, aplicar las diferencias y restablecer a partir de una nueva instantánea al volver a conectarse.

4. Mantén la ejecución, el análisis y las alertas en vías separadas.

   Un patrón de producción habitual es gRPC para los datos de mercado en tiempo real de la estrategia, la API de negociación Hyperliquid o SDK para las órdenes firmadas localmente, JSON-RPC para lecturas por lotes e históricas, Streams o Webhooks para flujos de eventos asíncronos, y SQL Explorer para estudios o investigaciones.

5. Mantén ambas alimentaciones durante la transición.

   Antes de actualizar la red, ejecuta tu consumidor de WebSocket público actual junto al nuevo consumidor de gRPC . Compara la antigüedad de la cartera, el spread observado, los intervalos entre actualizaciones, la calidad de ejecución y cualquier métrica de riesgo específica de la estrategia. Esto te proporcionará un plan de transición concreto, en lugar de tener que recurrir a un cambio de última hora a endpoint .

¿Qué otras herramientas de Quicknode son compatibles con los sistemas de negociación de Hyperliquid ?

gRPC Debería ser el primer lugar al que acudir para buscar datos de mercado de HyperCore en los que la latencia sea un factor clave, pero no es necesario que gestione todas las cargas de trabajo.

• WebSocket está disponible en todas las instancias de Hyperliquid endpoint . Sigue siendo la base de los paneles de control del navegador, las vistas de carteras, las interfaces de supervisión y cualquier tarea de negociación en la que el perfil de actualización se ajuste a la estrategia.

• JSON-RPC puede gestionar el rellenado de datos, las lecturas por lotes de bloques, el estado de la cartera, el estado de la cámara de compensación y la interacción con contratos HyperEVM.

• Streams y Webhooks puede enviar eventos filtrados a los sistemas de fondo y a los canales de alertas.

• SQL Explorer puede consultar más de 500 mil millones de filas indexadas de datos de Hyperliquid y exponer las consultas como puntos finales REST programables.

QuicknodeLa página de la cadena « Hyperliquid » también indica un SLA con un tiempo de actividad del 99,99 %, más de 6 000 millones de solicitudes a la API de Hyperliquid al mes y más de 500 000 millones de filas de datos consultables. Esas cifras son importantes cuando la carga de trabajo no es una demostración, sino un sistema de negociación que funciona de forma ininterrumpida.

¿Cómo se empieza a utilizar Hyperliquid gRPC ?

1. Crea una cuenta en Quicknode en quicknode.com/signup.

2. Crea una « Hyperliquid » (endpoint ) desde el panel de control de «Quicknode ». Una « endpoint » proporciona acceso gestionado tanto a HyperCore como a HyperEVM.

3. Revisa los conjuntos de datos disponibles en Hyperliquid y asigna cada dato de entrada de la estrategia al flujo correspondiente.

4. Utiliza la documentación de la API de streaming deHyperliquid gRPC para conectar tu aplicación cliente.

5. Elige la vía que mejor se adapte a tu estrategia: StreamL2Book para la profundidad del nivel de precios agregado, StreamL4Book para el estado de cada orden individual, o los conjuntos de datos estándar sobre operaciones, órdenes, eventos y actualizaciones del libro de órdenes.

6. Clona el repositorio de ejemplos de HyperCore gRPC para probar las suscripciones en JavaScript, Python, Go o Rust.

7. Consulta los ejemplos prácticos de la biblioteca de guías de « Hyperliquid » y de la biblioteca de aplicaciones de ejemplo.

HyperliquidLa actualización de la API pública es una señal de que la red está orientando los puntos de acceso compartidos hacia modelos de acceso más ligeros y amplios. Los operadores automatizados necesitan un enfoque diferente: profundidad de mercado actual, más niveles, datos en tiempo real streams y una infraestructura diseñada para sistemas siempre activos.

Quicknode ofrece una vía gestionada para realizar esa configuración sin que tengas que gestionar tú mismo la infraestructura de Node.js.

Empieza por los Quicknode Hyperliquid documentación.