El estado del mercado de Hyperliquid es producido por una L1 de 24 validadores que calcula los precios oracle (de referencia) en cada bloque y selecciona a los productores de bloques mediante una subasta de constructores/disponibilidad de datos (HIP-3/4). Para leer ese estado, usa los endpoints de la API de información como metaAndAssetCtxs y la fuente de subasta, pero siempre compara la marca de tiempo del oracle devuelta con tu propio reloj para evitar actuar sobre precios obsoletos. Esta guía explica el mecanismo y proporciona ejemplos reproducibles con curl.
Respuesta directa: cómo leer el estado del mercado de Hyperliquid
Si necesitas un precio auditable en Hyperliquid, no improvises a partir de la parte superior del libro de órdenes. La referencia canónica es el precio oracle (de referencia) que el conjunto de validadores calcula y compromete en cadena con cada bloque. Lo lees a través de la API de información (por ejemplo, metaAndAssetCtxs o allMids), y cada respuesta incluye una marca de tiempo que indica cuándo se calculó ese oracle. Por separado, la subasta de constructores/disponibilidad de datos (HIP-3/4) determina quién propone los bloques y cómo se distribuyen las tarifas prioritarias; puedes observar el estado actual de la subasta a través del endpoint de información exchange/auction. Esta guía explica el mecanismo y te proporciona comandos ejecutables para verificar lo que estás viendo.
La regla práctica clave: compara siempre la marca de tiempo del oracle en la respuesta de la API con tu propio reloj del sistema antes de usar el precio para financiación, liquidación o cualquier decisión financiera. Si la marca de tiempo es más antigua que unos pocos segundos (la cadencia documentada es cercana al tiempo de bloque, pero los valores exactos varían), trata el precio como obsoleto y vuelve a consultar. La misma disciplina se aplica a los datos de la subasta, que solo se actualizan cuando comienza una nueva ronda.
Cómo produce Hyperliquid los precios oracle
Hyperliquid ejecuta su propia L1: una cadena de prueba de participación delegada con 24 validadores, un binario Rust no-EVM y un tiempo de bloque que el protocolo apunta pero que puede variar con la latencia de los validadores. El conjunto de validadores es responsable de mantener los datos de mercado canónicos, incluido el precio oracle de cada activo. Según la documentación de Hyperliquid sobre precios oracle, el precio oracle es una mediana en cadena de múltiples precios de intercambio, calculada por los validadores. Se actualiza con cada bloque de la red, y esa actualización es lo que ves en la API de información.
El precio oracle sirve como precio de referencia para los pagos de financiación y las liquidaciones. Deliberadamente no es el precio de la parte superior del libro, porque la parte superior de un libro de órdenes único puede ser manipulada o ser poco profunda. Al usar una mediana entre intercambios, Hyperliquid hace que el precio de referencia sea más robusto. Cuando llamas a metaAndAssetCtxs, el campo markPx en cada contexto de activo es ese precio oracle, y el campo oraclePx (cuando está presente) es el oracle bruto antes de cualquier ajuste de financiación. El campo time en la respuesta es la marca de tiempo Unix (en milisegundos) del bloque en el que se calculó ese oracle.
Para una mirada más profunda a la mecánica, la documentación de Hyperliquid sobre el endpoint de información enumera todos los tipos de solicitud. La solicitud metaAndAssetCtxs devuelve tanto los metadatos del activo como el contexto actual (incluyendo precio de referencia, precio oracle, financiación e interés abierto) para todos los activos. La solicitud allMids es una variante más ligera que devuelve solo el precio medio (que se deriva del libro de órdenes, no del oracle) y se usa a menudo para consultas rápidas. No confundas allMids con el precio oracle: allMids es el medio del libro L2, mientras que metaAndAssetCtxs te da el oracle.
La subasta de constructores y disponibilidad de datos (HIP-3/4)
La producción de bloques de Hyperliquid no es de libre acceso. En el protocolo base, los validadores producen bloques en un orden determinista, pero una subasta determina quién puede enviar las transacciones del siguiente bloque. Esta es la subasta de constructores: los productores de bloques (constructores) pujan para ganar el derecho a proponer un bloque, y la puja ganadora se paga en tarifas prioritarias que los usuarios adjuntan a sus transacciones. La documentación de Hyperliquid sobre exchange/auction describe el formato actual de la subasta y los campos devueltos por el endpoint de información exchange/auction.
HIP-3 (perpetuos implementados por constructores) extiende esta idea: permite a los constructores implementar sus propios mercados perpetuos, y esos mercados pueden tener subastas privadas donde solo el constructor que los implementa puede enviar bloques para ese mercado. Esto está documentado en la propuesta HIP-3. HIP-4 (de perpetuos a predicciones) es una propuesta más amplia que incluye una subasta de disponibilidad de datos para los datos de carga útil, pero al momento de escribir esto es una propuesta, no un mecanismo activo. Los documentos la describen como un diseño para cómo se fija el precio y se subasta la disponibilidad de datos, pero debes verificar el estado actual al momento de la lectura.
Para un lector, lo importante es que el estado de la subasta es observable. El endpoint de información exchange/auction devuelve la ronda de subasta actual, el activo (o 'HL' para la cadena principal), la puja y el tiempo en que termina la subasta. Puedes consultar esto para ver quién está ganando y cuándo comienza la siguiente ronda. Sin embargo, ten en cuenta que la fuente de la subasta solo está disponible a través de ciertas suscripciones: la suscripción WebSocket auction te da actualizaciones en tiempo real, mientras que el endpoint REST de información te da una instantánea. Consulta la guía de suscripciones WebSocket de Hyperliquid para obtener detalles sobre qué suscripciones existen.
¿Qué endpoint de información deberías consultar?
Diferentes casos de uso requieren diferentes fuentes de datos. La tabla a continuación resume la decisión.
| Caso de uso | Endpoint / suscripción | Qué te proporciona |
|---|---|---|
| Precio auditable (financiación, liquidación) | metaAndAssetCtxs (REST) o activeAssetCtx (WS) | Precio oracle (de referencia) con marca de tiempo |
| Libro de órdenes en tiempo real | l2Book (WS) o l2Book REST | Ofertas/demandas de la parte superior del libro, sin oracle |
| Precio histórico | candles (REST) o trades (REST) | OHLCV o historial de operaciones, cada uno con marcas de tiempo |
| Estado de la subasta | exchange/auction (REST) o auction (WS) | Puja actual, ronda, tiempo de finalización |
Para un precio que sea seguro de usar en lógica financiera, siempre prefiere metaAndAssetCtxs sobre allMids o l2Book. Estos dos últimos reflejan solo el libro de órdenes local, que puede estar desactualizado o ser manipulado. El precio oracle es el que el propio protocolo usa para liquidaciones y financiación, por lo que es la referencia más defendible.
Ejemplo ejecutable: lectura del precio oracle y del estado de la subasta
La salida esperada (abreviada) para metaAndAssetCtxs se ve así:
El campo time está en milisegundos. Compáralo con tu hora del sistema (también en ms) para calcular la obsolescencia. La respuesta de exchange/auction es una lista de objetos de subasta, cada uno con campos como type, asset, bid, time y endTime (también en ms).
# Obtener metaAndAssetCtxs (precios oracle)
curl -s https://api.hyperliquid.xyz/info -X POST -H 'Content-Type: application/json' \
-d '{"type":"metaAndAssetCtxs"}'
# Obtener exchange/auction (subasta actual)
curl -s https://api.hyperliquid.xyz/info -X POST -H 'Content-Type: application/json' \
-d '{"type":"exchange/auction"}'
# Obtener allMids (precios medios, no oracle)
curl -s https://api.hyperliquid.xyz/info -X POST -H 'Content-Type: application/json' \
-d '{"type":"allMids"}'
# Salida esperada (abreviada)
{
"meta": { ... },
"assetCtxs": [
{
"dayNtlVlm": "123456789.0",
"funding": "0.00001234",
"markPx": "65432.1",
"midPx": "65430.0",
"openInterest": "1234.5",
"oraclePx": "65431.0",
"premium": "0.00002",
"time": 1720000000000
}
]
}Tabla de resultados para completar: marca de tiempo del oracle vs. hora del sistema
Para verificar que no estás actuando sobre un precio obsoleto, ejecuta el comando curl anterior y completa la tabla a continuación. Usa una herramienta como date +%s%3N en Linux o Get-Date -Format 'yyyy-MM-dd HH:mm:ss.fff' en Windows para obtener tu hora del sistema en ms.
| # de consulta | time del oracle (ms) | Hora del sistema (ms) | Delta (ms) | ¿Obsoleto? (>5000 ms) |
|---|---|---|---|---|
| 1 | ||||
| 2 | ||||
| 3 |
Si el delta es consistentemente superior a unos pocos segundos, el endpoint de la API que estás usando puede estar retrasado, o la red misma puede estar experimentando latencia. Los documentos de Hyperliquid indican que el oracle se actualiza con cada bloque, pero el tiempo de bloque exacto no es fijo; depende del rendimiento de los validadores. Para un sistema de producción, establece un umbral que coincida con tu tolerancia al riesgo (por ejemplo, 5 segundos) y vuelve a consultar si se supera.
Solución de problemas y lista de verificación
Al leer el estado del mercado de Hyperliquid, puedes encontrarte con varias trampas comunes. Usa esta lista para diagnosticarlas.
- Unidades de marca de tiempo: El campo
timeen las respuestas de información está en milisegundos. Si lo comparas con una marca de tiempo Unix en segundos, pensarás que el precio es 1000 veces más antiguo de lo que es. Siempre convierte a la misma unidad. - Clave de intervalo incorrecta: Al consultar
candles, el campointervaldebe ser uno de los valores documentados (por ejemplo,1m,5m,15m,1h,4h,1d). Usar un valor no compatible devuelve un error o datos vacíos. - Confundir precio de referencia, índice y último precio:
markPxes el precio oracle utilizado para financiación/liquidaciones.oraclePxes el oracle bruto antes de cualquier ajuste de financiación.midPxes el medio del libro de órdenes.last(en operaciones) es el último precio operado. No usesmidPxcuando necesites el oracle. - Visibilidad de la fuente de subasta: El endpoint REST
exchange/auctiondevuelve la subasta actual, pero las actualizaciones en tiempo real requieren la suscripción WebSocketauction. Si no recibes actualizaciones, verifica que te hayas suscrito correctamente. - Variación de la cadencia: La cadencia de actualización del oracle está vinculada a la producción de bloques, que puede variar con la latencia de los validadores. Los documentos describen un tiempo de bloque objetivo, pero no garantizan un intervalo fijo. Siempre verifica la cadencia actual en los documentos al momento de la lectura.
- Límites de velocidad: La API de información tiene límites de velocidad. Si consultas con demasiada frecuencia, puedes recibir respuestas 429. Consulta la guía de límites de velocidad RPC de Hyperliquid para obtener detalles.
Limitaciones y compensaciones
Los mecanismos descritos aquí son ideas de protocolo documentadas, pero los parámetros exactos (tiempo de bloque, duración de la subasta, divisiones de tarifas) están sujetos a cambios y pueden variar según las condiciones de la red. Los documentos de Hyperliquid son la fuente autorizada; consúltalos siempre al momento de la lectura para obtener los valores más recientes. Por ejemplo, la documentación de Hyperliquid sobre exchange/auction especifica los campos de la subasta, pero la duración de cada ronda no está fijada en los documentos; está determinada por la lógica interna del protocolo.
Además, la subasta de constructores/disponibilidad de datos es un área en evolución. HIP-3 y HIP-4 son propuestas que pueden implementarse de manera diferente a lo descrito aquí. Al momento de escribir esto, HIP-3 está activa para mercados implementados por constructores, pero HIP-4 sigue siendo una propuesta. No asumas que todas las características descritas en HIP-4 están activas en la red principal.
Finalmente, la API de información te da una instantánea del estado en un bloque particular. Si necesitas un registro histórico, debes usar los endpoints candles o trades, que tienen sus propias limitaciones (por ejemplo, pueden no incluir cada actualización del oracle). Para un registro de auditoría completo, considera ejecutar tu propio indexador o usar un servicio de datos.
Próximos pasos y lecturas adicionales
Ahora que entiendes cómo leer los precios oracle y el estado de la subasta de Hyperliquid, puedes construir herramientas de trading o monitoreo más confiables. Para profundizar, explora los siguientes recursos:
- Descripción general de la red Hyperliquid – comprende la arquitectura de la cadena y los endpoints.
- Endpoints RPC de Hyperliquid (Asistente RPC) – encuentra el endpoint adecuado para tu caso de uso.
- Lectura de datos históricos de mercado de Hyperliquid – aprende a obtener velas y operaciones para realizar pruebas retrospectivas.
- Manejo de rechazos de órdenes y errores de API de Hyperliquid – soluciona problemas comunes de API.
- Suscripciones WebSocket de Hyperliquid – obtén actualizaciones en tiempo real de precios y subastas.
- Latencia y rendimiento RPC de Hyperliquid – mide y optimiza tu conexión.
- Centro de aprendizaje de OnFinality – más guías sobre protocolos de red.
- Precios RPC – descubre cómo OnFinality puede proporcionar acceso RPC confiable.
- Servicio API – conoce los servicios API gestionados de OnFinality.