Mercados de resultados HIP-4 de Hyperliquid: mecánica, flujo de trabajo API y verificación

Qué añade HIP-4 a HyperCore

HIP-4 introduce mercados de resultados en HyperCore de Hyperliquid. Según la documentación de Hyperliquid, los resultados son contratos totalmente colateralizados que liquidan dentro de un rango fijo, y HIP-4 se describe como una primitiva de propósito general útil para mercados de predicción e instrumentos similares a opciones con límites. El punto arquitectónico clave es que los resultados aportan no linealidad y contratos con fecha sin apalancamiento ni liquidaciones, y se componen con otras primitivas de HyperCore como el margen de cartera y HyperEVM.

El primer tipo de mercado es un resultado binario recurrente que liquida diariamente al precio de referencia de BTC en HyperCore. Los mercados de resultados múltiples están documentados como compatibles en el diseño pero no forman parte del lanzamiento inicial en mainnet, y las funciones adicionales se implementan por etapas. Trate cualquier lista específica de mercados, fuente de liquidación o denominación de colateral como algo que debe confirmar con la documentación actual y las respuestas de la API en vivo en lugar de asumirlo de escritos anteriores.

• Totalmente colateralizado: sin participación del motor de liquidación.
• Contratos con fecha: cada mercado tiene un vencimiento y una regla de liquidación.
• Tokens de dos lados: cada mercado de resultados tiene dos lados, comúnmente Sí y No.
• Componible: diseñado para interactuar con el margen de cartera y aplicaciones HyperEVM.

Supuestos y requisitos previos

Esta guía asume que puede acceder a un endpoint de la API de Hyperliquid (las API info y exchange) y que tiene un cliente HTTP funcional. La inspección de solo lectura no requiere clave. La colocación de órdenes requiere una cuenta con fondos y firma, lo cual está fuera del alcance aquí más allá de señalar dónde encaja. Si está eligiendo un endpoint para trading sensible a la latencia, la decisión concreta del proveedor corresponde a RPC Assistant; consulte la guía sobre los mejores proveedores RPC de Hyperliquid para trading de baja latencia y la descripción general de proveedores RPC de HyperEVM.

Para la planificación de infraestructura, tenga en cuenta que el trading de resultados es una superficie de API similar a spot con diferencias en los ID de activos. Su integración no debe asumir ID de activos estilo perpetuo. La documentación remite a los desarrolladores a la página de asset-ids para la codificación exacta.

El modelo mental del libro dual

Cada mercado de resultados consta de dos lados, cada uno con un token. Los tokens están etiquetados por sideSpecs en el endpoint de información outcomeMeta, a menudo Sí y No. Los libros de órdenes de los tokens Sí y No para el mismo resultado se fusionan para compartir liquidez. Una orden para comprar Sí a precio p es equivalente a una orden para vender No a 1-p.

Bajo el libro fusionado, la prioridad precio-tiempo se generaliza a prioridad precio-lado-tiempo: para órdenes en el mismo nivel de precio fusionado, las órdenes de venta en reposo se ordenan antes que todas las órdenes de compra duales en reposo. La mayoría de las operaciones abstraen el libro dual desde la perspectiva del usuario, pero la documentación señala que algunas ergonomías mejorarán en una futura actualización de la red. Un ejemplo documentado: el historial de órdenes puede devolver órdenes primarias y duales por separado si un usuario envía una orden que tanto coincide como queda en reposo en el libro.

Los usuarios avanzados pueden dividir y fusionar manualmente los resultados para convertir entre saldos primarios y duales. Para la mayoría de las integraciones, la regla práctica es razonar en el espacio de precios fusionados y dejar que la API maneje la representación dual, siendo consciente de que el historial de órdenes puede mostrar ambas piernas.

Matemáticas de liquidación y settleFraction

La liquidación convierte automáticamente Sí a settleFraction tokens de cotización y No a 1 - settleFraction tokens de cotización. En particular, settleFraction = 1 para liquidación binaria sí y settleFraction = 0 para liquidación binaria no. Esta es la identidad contable central: los dos lados siempre suman una unidad del activo de cotización en la liquidación, lo que hace que el contrato esté totalmente colateralizado.

Para un mercado de rango limitado o de resultados múltiples, la misma identidad se generaliza a través del conjunto de resultados. Al construir un modelo de pago, exprese cada posición como una fracción de la unidad de colateral y verifique que la suma a través de todos los resultados sea igual a uno. Si su modelo produce una suma distinta de uno, ha malinterpretado la definición del mercado o la fuente de liquidación.

def payout(side: str, settle_fraction: float) -> float:
    """Return quote-token payout per unit of collateral for a binary outcome."""
    if side.lower() == "yes":
        return settle_fraction
    if side.lower() == "no":
        return 1.0 - settle_fraction
    raise ValueError(f"unknown side: {side}")

# Example: binary yes settlement
assert payout("yes", 1.0) == 1.0
assert payout("no", 1.0) == 0.0
# Example: binary no settlement
assert payout("yes", 0.0) == 0.0
assert payout("no", 0.0) == 1.0
print("settlement identity holds")

Inspección de mercados en vivo a través de la API de información

El endpoint de información outcomeMeta es la fuente de verdad para los metadatos del mercado, incluidos sideSpecs. Comience cada integración obteniéndolo y registrando la respuesta sin procesar. No codifique etiquetas de lado o identificadores de mercado; son datos, no constantes. El siguiente script de solo lectura utiliza solo la biblioteca estándar y un endpoint de marcador de posición.

Ejecútelo contra su endpoint elegido y compare la lista de mercados devuelta con lo que muestra el frontend. Una discrepancia generalmente significa que está apuntando a una red diferente o a una caché obsoleta.

import json, urllib.request

RPC_URL = "https://YOUR_HYPERLIQUID_ENDPOINT"

def post_info(payload: dict) -> dict:
    req = urllib.request.Request(
        RPC_URL,
        data=json.dumps(payload).encode(),
        headers={"Content-Type": "application/json"},
        method="POST",
    )
    with urllib.request.urlopen(req, timeout=10) as resp:
        return json.loads(resp.read().decode())

meta = post_info({"type": "outcomeMeta"})
print(json.dumps(meta, indent=2)[:2000])

# Extract side labels for each market without assuming Yes/No
for market in meta.get("universe", meta.get("markets", [])):
    sides = market.get("sideSpecs") or market.get("sides")
    print(market.get("name"), "->", sides)

Resolución de ID de activos de resultados

El trading de resultados utiliza una API similar a spot, con diferencias clave en los ID de activos documentadas en la página de asset-ids de Hyperliquid. El flujo de trabajo práctico es: obtener metadatos de resultados, mapear cada mercado y lado a su ID de activo, luego usar ese ID en solicitudes de órdenes e información. Nunca reutilice un ID de activo spot o perpetuo para un mercado de resultados.

El ejemplo de curl a continuación muestra la forma de la solicitud. Reemplace RPC_URL con su endpoint y ajuste el tipo de carga útil para que coincida con la documentación actual si el nombre del tipo de información ha cambiado.

curl -s -X POST "$RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{"type":"outcomeMeta"}' \
  | python3 -m json.tool | head -n 80

Un procedimiento de verificación reproducible

Utilice este procedimiento para confirmar que su integración lee correctamente los datos de HIP-4. Es deliberadamente de solo lectura para que pueda ejecutarse en CI o en un portátil sin claves.

Paso 1: obtenga outcomeMeta y registre el recuento de mercados y las etiquetas de lado. Paso 2: para cada mercado, obtenga el libro de órdenes o el libro L2 para ambos lados y confirme que los niveles de precio fusionados son consistentes con la identidad comprar-Sí-es-igual-a-vender-No. Paso 3: elija un mercado cerca del vencimiento y confirme que el texto de la regla de liquidación coincide con la fuente documentada. Paso 4: vuelva a ejecutar el mismo script después de un intervalo conocido y compare las salidas para detectar cambios en el esquema.

Registre los resultados en una tabla como la siguiente. Deje los valores en blanco hasta que haya ejecutado realmente el procedimiento; no complete estimaciones.

• | Verificación | Esperado | Observado | Aprobado/Fallido |
• | outcomeMeta devuelve mercados | lista no vacía | | |
• | etiquetas de lado presentes | dos lados por mercado | | |
• | identidad del libro fusionado | comprar Sí p ~ vender No 1-p | | |
• | texto de la regla de liquidación | coincide con la documentación | | |
• | esquema estable entre ejecuciones | sin campos inesperados | | |

Solución de problemas comunes de integración

La mayoría de los problemas de integración de HIP-4 se dividen en unos pocos grupos. Si outcomeMeta devuelve una forma vacía o inesperada, confirme primero el endpoint y la red; un endpoint de testnet no mostrará mercados de mainnet. Si se rechazan los ID de activos, probablemente esté utilizando un ID de spot o perpetuo donde se requiere un ID de resultado. Si el historial de órdenes muestra dos entradas para una orden, esa es la división documentada primaria/dual cuando una orden tanto coincide como queda en reposo.

Si su modelo de pago no suma uno, vuelva a leer la definición del mercado y la fuente de liquidación. Si el problema es la latencia, mídala en lugar de adivinar: cronometre la solicitud de información desde su región de producción y compare endpoints. La comparación de rendimiento de Hyperliquid y las opciones de nodo dedicado son los lugares correctos para evaluar las compensaciones de infraestructura.

Limitaciones y compensaciones

HIP-4 está documentado como un despliegue por etapas. Los mercados de resultados múltiples no formaban parte del lanzamiento inicial en mainnet, y algunas ergonomías del libro dual están programadas para mejorar en una futura actualización de la red. Construya su integración para tolerar adiciones de esquema y nuevos tipos de mercado en lugar de asumir una forma fija.

Los resultados totalmente colateralizados eliminan el riesgo de liquidación pero también eliminan el apalancamiento; la eficiencia del capital es diferente a la de los perpetuos. El descubrimiento es otra compensación: el frontend de Hyperliquid está diseñado para traders activos, por lo que si sus usuarios esperan una experiencia de mercado de predicción estilo navegación, es posible que deba construir esa capa usted mismo sobre la API. Finalmente, la liquidación depende de la fuente definida; las fuentes objetivas y canónicas reducen la ambigüedad, pero aún debe verificar la regla para cada mercado que negocie.

Próximos pasos para desarrolladores

Una vez que la verificación de solo lectura pase, el siguiente paso es un flujo de órdenes firmado en un entorno de prueba, seguido de una capa de monitoreo que alerte sobre cambios en el esquema y eventos de liquidación. Para la selección de endpoints, use RPC Assistant en lugar de incrustar una elección de proveedor en su código; consulte la entrada del mejor proveedor RPC de Hyperliquid y la descripción general de precios de RPC para la planificación de capacidad. Si opera su propia infraestructura, revise el alojamiento de nodos blockchain y el directorio de redes antes de comprometerse con una topología.

Mantenga un registro de cambios de los tipos de información de los que depende y vuelva a ejecutar el procedimiento de verificación después de cualquier actualización de red documentada. Esa disciplina es lo que mantiene correcta una integración de mercados de resultados a medida que HIP-4 evoluciona.