Análisis profundo de HIP-3: Cómo Hyperliquid convierte la «actualización» en un permiso para desarrolladores

Redacción: Blocksec

HIP-3 (Propuesta de Mejora de Hyperliquid 3) ha estado en línea en la red principal durante aproximadamente 3 meses. Desde su lanzamiento, el volumen de transacciones acumuladas en mercados personalizados de terceros ha superado los 13 mil millones de dólares, lo que significa que la «nueva incorporación» está pasando de ser un proceso interno de los intercambios a convertirse en una capacidad de infraestructura que los desarrolladores externos pueden invocar directamente.

En los intercambios centralizados, la «nueva incorporación» es inherentemente un poder de la plataforma: qué activos pueden negociarse, cuándo se lanzan, cómo se establecen los parámetros, todo generalmente lo decide el proceso de operación y gestión de riesgos. Incluso en la cadena, categorías como los contratos perpetuos, que son infraestructura fundamental, a menudo están restringidas por el ritmo de despliegue y gobernanza de unos pocos equipos.

La innovación de HIP-3 radica en cambiar esto de «aprobación por la plataforma» a «apertura de interfaces»: siempre que se cumplan las condiciones, terceros podrán desplegar nuevos mercados de contratos perpetuos en la misma base de negociación y liquidación, externalizando sistemáticamente el poder de la incorporación centralizada a la ecosistema. Esta mejora no solo reduce la barrera a la innovación, sino que también fortalece la escalabilidad del mercado. Sin embargo, la apertura de interfaces trae riesgos potenciales de seguridad que no se pueden ignorar; garantizar que estos mercados operen de manera legal y sin comportamientos maliciosos sigue siendo una cuestión clave en el diseño de HIP-3.

0x1 Hyperliquid: La base de HIP-3

Hyperliquid es una infraestructura de negociación perpetua que opera en su propia cadena. Para HIP-3, lo más importante es que: la coincidencia, liquidación y liquidación final son proporcionadas unificadamente por la base del protocolo, permitiendo la reutilización de capacidades de mercado en lugar de construir un sistema de negociación desde cero.

Hyperliquid adopta una arquitectura de doble capa:

HyperCore: una cadena de bloques personalizada optimizada para contratos, capaz de procesar 200,000 órdenes por segundo y con finalidad determinista.

HyperEVM: capa de aplicación, que puede ejecutar contratos inteligentes y es compatible con EVM.

El mercado nativo de perp de Hyperliquid (perps operados por validadores) aún se asemeja más a los procesos tradicionales de CEX: el equipo oficial lanza contratos perpetuos según la voluntad de la comunidad; mientras que la eliminación se decide mediante votación de los nodos validadores.

El protocolo Hyperliquid apoyará los perp desplegados por los constructores (HIP-3), un hito clave para descentralizar completamente el proceso de listado de perp.

El protocolo Hyperliquid soportará contratos perpetuos desplegados por los constructores (HIP-3), que es un paso fundamental para lograr un proceso de incorporación totalmente descentralizado.

0x2 HIP-3: Mercados desplegados por desarrolladores

La idea de HIP-3 es simple: sin modificar la base de negociación y liquidación de Hyperliquid, abrir la capacidad de «agregar nuevos mercados perpetuos» a constructores que cumplan con los requisitos. Los constructores definen los parámetros clave del mercado y las responsabilidades de precios y operación, mientras que el protocolo usa un motor de margen y liquidación unificado para ejecutar y gestionar riesgos; así, la «nueva incorporación» pasa de ser un proceso de plataforma a una interfaz estándar invocable.

En resumen: el constructor puede listar un mercado de contrato perpetuo basado en HyperCore, establecer precios y ajustar parámetros del mercado de forma autónoma.

Responsabilidades y límites del constructor

En HIP-3, el constructor asume dos roles en un mercado perp (market): definir el mercado y operarlo.

Definición del mercado (Market definition):

La plataforma lo resume como definición de oracle + especificaciones del contrato. En términos operativos, al menos incluye:

Definición del oracle:

Incluye la definición del oraclePx inicial y la fuente de precios. El constructor debe definir claramente un activo o fuente de datos con características de integridad, dificultad de manipulación y sustancia económica; al registrar el activo, debe proporcionar un oraclePx inicial.

Especificaciones del contrato:

Definir claramente en la API parámetros del mercado como «símbolo del activo / unidad mínima de orden / apalancamiento máximo» (coin, szDecimals, maxLeverage, etc.).

Selección de DEX:

El constructor primero despliega un DEX perp (cada DEX con margen, libro de órdenes y configuración de deployer independientes), y puede elegir cualquier activo cotizado como colateral (por ejemplo USDC). Cada mercado perp tendrá un DEX correspondiente.

Operación del mercado (Market operation):

El equipo oficial lista los perp según la voluntad de la comunidad; la eliminación la decide mediante votación de los validadores.

Especificaciones detalladas:

• Actualización de precios de oracle:

Usando la interfaz setOracle para alimentar continuamente el precio del oracle del mercado.

• Límite de apalancamiento:

A través de la asignación de una tabla de márgenes (margin table) para restringir el apalancamiento máximo, con límites escalonados según tamaño de posición.

• Liquidación cuando sea necesario:

El constructor puede usar haltTrading para detener el mercado, activar la liquidación—cancelar órdenes y liquidar posiciones al precio de marca actual (mark price); este mismo mecanismo puede usarse para reactivar el mercado.

Actualmente, los mercados HIP-3 solo soportan posiciones aisladas (isolated-only); en el futuro, podrían soportar posiciones cruzadas (cross).

Proceso completo de listado de mercado

1. Stake

El constructor debe mantener 500k HYPE en garantía; incluso si detiene todos sus mercados en DEX, la garantía debe mantenerse 30 días.

2. Construcción

Tras cumplir con el umbral de garantía, el constructor puede desplegar un DEX perp. Cada DEX es un dominio de negociación independiente: margen, libro de órdenes y configuración de deployer.

3. Establecer colateral

El colateral del DEX puede ser cualquier activo cotizado, pero si dicho activo pierde la condición de «activo cotizado sin permiso» (decisión de validadores mediante votación), el DEX con ese colateral será desactivado.

4. Añadir mercados

Los primeros 3 mercados se pueden desplegar directamente; para añadir más, se requiere participar en una subasta holandesa para obtener «cupos adicionales».

5. Operar mercados

Tras listar, el trabajo del constructor es «mantener la estabilidad del mercado», es decir, gestionar la operación.

6. Unstake

Cuando todos los mercados en DEX hayan sido liquidado, la garantía de 500k HYPE puede desbloquearse. Al solicitar unstake, se entra en una cola de 7 días, durante la cual la garantía puede ser confiscada.

Subasta holandesa: ciclo actual de 31 horas, precio inicial es 2 veces el precio final (precio de transacción / mínimo).

setOracle: tres tipos de entrada de precios

En HyperCore, el precio del oracle se usa principalmente para anclar y calcular la tasa de financiamiento (funding), y el precio de marca (mark price) se usa para gestión de riesgos en liquidaciones y garantías (también para activar TP/SL).

En mercados nativos, el mark price no es un resultado directo del precio alimentado, sino la mediana de tres valores:

oraclePx + EMA(midPx - oraclePx)

mediana(mejor oferta, mejor demanda, última operación) (precio del libro local)

Precio medio ponderado de múltiples CEX de contratos perpetuos (perp mid prices)

El mecanismo de cálculo en HIP-3 no ha cambiado en cuanto a la función de oracle y mark price, pero sí en el mecanismo:

setOracle entrada

a. oraclePx (obligatorio))

Definido de acuerdo con HyperCore.

b. markPx (opcional)

Se pueden enviar de 0 a 2 conjuntos de precios externos como candidatos para el mark price real.

c. externalPerpPx (obligatorio)

Valor de referencia del mark price, para evitar desviaciones abruptas.

El relayer suele desplegar nodos para alimentar precios, y calcula oraclePx y markPx mediante algoritmos personalizados; externalPerpPx es la mediana ponderada de precios de múltiples CEX.

2. Precio de marca real

El mark price en HIP-3 no se obtiene directamente del setOracle:

• Se calcula el mark local como la mediana de mejor oferta, mejor demanda y última operación.

• Se combina con los conjuntos de markPx (0-2) y se obtiene la mediana para definir el nuevo mark price.

3. Restricciones de setOracle

Frecuencia de actualización: al menos 2.5 segundos entre llamadas; si no se actualiza markPx en 10 segundos, se vuelve al mark local.

Variación: el markPx no puede variar más de ±1% por actualización; todos los precios se ajustan dentro de un rango 10 veces el valor de apertura del día.

7×24H y no 7×24H: diferencias en mecanismos de fijación de precios

En HIP-3, los mercados perpetuos soportan activos que pueden ser 7×24H (negociados en cualquier momento) o no 7×24H (solo en horarios específicos). La diferencia en horarios afecta cómo se obtiene el precio.

Para activos 7×24H (como BTC), se obtiene un precio estable de CEX/DEX o de oráculos confiables.

Para activos no 7×24H (como acciones), solo durante horarios de mercado abierto se puede obtener liquidez suficiente y precios estables. Fuera de horario, se usa otra mecánica de fijación basada en el último cierre y presión interna de órdenes, con límites de fluctuación (ejemplo: Tesla 10x -> 10%).

Liquidación

HIP-3 reutiliza la lógica de liquidación de HyperCore: cuando el valor neto de la posición (isolated position value) no cubre el margen de mantenimiento, se activa la liquidación.

La liquidación se basa en el mark price, no en una transacción específica.

Fórmula de precio de liquidación:

side = 1 (long), -1 (short)

l: tasa de margen de mantenimiento

El precio de liquidación se calcula según el nivel de margen y la categoría de la posición, usando la tasa de mantenimiento correspondiente.

Tras entrar en estado de liquidación, el sistema prioriza cerrar posiciones con órdenes de mercado; si se puede reducir el riesgo, el resto del margen se devuelve al trader.

En casos de poca profundidad o saltos, el precio de cierre puede ser muy diferente del mark price, creando un «gap de liquidación».

El valor de posición aislada: valor neto de una posición en mark price actual, incluyendo ganancias y pérdidas, menos el margen vinculado.

ADL (Auto-Deleveraging):

En casos extremos, el mecanismo ADL puede reducir posiciones forzadamente en orden de pérdidas no realizadas y apalancamiento, usando las ganancias de contrapartes para cubrir el gap y evitar pérdidas para el sistema.

El orden de reducción se basa en el precio de mark anterior y en la clasificación de las posiciones por ganancias y pérdidas.

Ejemplo: si el mark price se reduce de 3,000 a 2,970 por restricciones de setOracle, y la liquidación en mercado se realiza a 2,910, puede que la posición long quede en valor negativo, activando ADL y reduciendo posiciones en orden de ganancias.

0x3 Panorama de riesgos:

Responsabilidades y riesgos clave

Mecanismo de penalización (Slashing): autoridad para sancionar

HIP-3 delega «poder de incorporación y operación» a los constructores, pero también establece reglas de penalización: los constructores deben hacer staking de HYPE, y si operan mal, los validadores pueden votar para penalizar y quemar su stake.

Requisitos de staking

El mínimo en la red principal es 500k HYPE, y si suspenden todos sus mercados, deben mantener el stake durante 30 días (la responsabilidad no termina con la suspensión).

Votación y decisión

En caso de operaciones maliciosas, los validadores pueden iniciar una votación ponderada por stake para decidir la penalización.

Criterios de decisión

Se evalúa si las acciones del constructor causan estados inválidos, caídas prolongadas o degradación del rendimiento, sin distinguir causas específicas.

Proporción de penalización

El porcentaje de penalización lo decide la votación, con límites máximos:

• Estado inválido o caída prolongada: hasta 100%

• Caída breve: hasta 50%

• Degradación del rendimiento: hasta 20%

Las tokens penalizadas se queman, no se reembolsan a usuarios afectados.

Riesgos en parámetros

setOracle

El precio del oracle generalmente proviene del relayer del constructor, lo que implica riesgos centralizados: si se filtra la clave privada o sufre DDoS, el precio puede ser manipulado o desconectado.

haltTrading

El constructor puede usar haltTrading para cancelar órdenes y liquidar posiciones a precio de marca. Debe usarse con cautela, por ejemplo, en casos de manipulación del mercado, ya que puede realizar liquidaciones que beneficien al atacante o causar pérdidas.

setMarginTableIds / InsertMarginTable

InsertMarginTable define nuevas tablas de margen y límites de apalancamiento; setMarginTableIds vincula un mercado a una tabla específica. Configurar un apalancamiento demasiado alto en mercados poco líquidos aumenta el riesgo de activación de ADL y liquidaciones masivas.

Cambiar abruptamente la tabla de margen puede convertir posiciones seguras en liquidables, provocando cascadas de liquidaciones.

setMarginModes

Actualmente, HIP-3 solo soporta margen aislado (isolated); en el futuro, podría soportar margen cruzado (cross). En mercados con diferentes niveles de liquidez, el modo cruzado puede propagar riesgos de baja liquidez a mercados de alta liquidez, por lo que no se recomienda aún.

Riesgos de oráculos

Para activos 7×24H, los riesgos principales son la precisión y estabilidad del oracle externo y la centralización del relayer.

Para activos no 7×24H, el mayor riesgo es la obtención o cálculo del precio en horarios no negociables.

Por ejemplo, en trade.xyz, en horarios sin mercado, se usa el último precio externo y el interno, con límites de fluctuación (ejemplo: 1/max_leverage). Si en un evento como el 14/12/2025, el precio de XYZ100 se manipula, puede causar liquidaciones masivas.

Falta de precios estables y continuos en horarios no negociables puede generar saltos de precio y eventos de ADL, especialmente en la reapertura del mercado.

0x4 Estrategias de control de riesgos

1. Precio del oracle estable

Para activos no negociables todo el día, el desafío es la fijación en horarios de cierre: la falta de precios estables puede facilitar manipulaciones.

Las soluciones incluyen:

• Detener la actualización del oracle en horarios de cierre, limitando la negociación (ejemplo: Lighter).

• Ajustar el apalancamiento máximo en horarios de cierre, forzando liquidaciones si se exceden límites.

• Usar mecanismos internos de fijación, como en trade.xyz, que mantienen precios internos en ausencia de datos externos.

Estas soluciones reflejan un compromiso entre seguridad y experiencia: la primera prioriza la seguridad, sacrificando la fluidez; la segunda mantiene la continuidad, pero puede desviarse del valor real del activo.

Durante el cierre, se recomienda no dejar que la fijación sea solo interna, sino introducir referencias externas para reducir riesgos de desconexión y saltos.

Referencias externas útiles:

• Blue Ocean ATS: mercado post-cierre o nocturno, que puede ofrecer precios de referencia más actualizados que el cierre.

• IG weekend CFD quotes: precios de CFD en fin de semana, útiles como referencia o monitoreo.

2. Verificación de precios

El precio del oracle en HIP-3 proviene del relayer del constructor, lo que puede ser centralizado. Se recomienda implementar mecanismos de verificación de precios, permitiendo a cualquier usuario o entidad validar la veracidad y equidad del precio off-chain, similar a RedStone, empaquetando el valor, fuente y firma en la cadena.

Componentes:

• Datos públicos: algoritmos y procesos transparentes, lista de fuentes abiertas y sin intervención del constructor, especificaciones de transmisión de precios.

• Prueba de precios: generación de prueba (Proof) en cada setOracle, que incluye entradas, cálculos intermedios y resultados, firmados y hashados.

• Publicación de pruebas: mantener un registro de ProofHash en un árbol Merkle, publicando periódicamente el root.

• Verificación: herramientas abiertas o páginas web que permitan verificar firmas, timestamps y MerkleRoot, y comparar precios calculados con los oficiales.

3. Monitoreo de riesgos

La verificación de precios hace que setOracle sea auditable, pero no previene que el mercado se descontrole: interrupciones, desviaciones y profundidades reducidas, combinadas con grandes posiciones abiertas, pueden derivar en cascadas de liquidaciones y ADL.

Por ello, es importante detectar anomalías tempranamente y activar medidas correctivas en tiempo, para mantener los riesgos controlados.

1. En el lado del precio

a. Fallo del oracle

Indicadores:

• Monitoreo de la salud del relayer, detección de fallos y cambio a relayer alternativo, con alertas.

• Reducción del límite de interés abierto (OI cap) mediante setOpenInterestCaps.

b. Desconexión del precio

Indicadores:

• Cuando 2 o más de los siguientes umbrales se superan simultáneamente y persisten:

  • A, B, D: ≥ 2

  • A, B, C, D: ≥ 3 y por X segundos

Acciones:

• Reducir OI límite.

• Ajustar márgenes y apalancamientos, activar mecanismos de clamp en relayer.

• En caso de desviación prolongada, activar alertas y decidir si detener mercado.

2. En el lado del libro

a. Profundidad y spread

Indicadores:

• Depth_band: volumen en rango ±x% alrededor del precio medio.

• Spread: diferencia entre mejor oferta y demanda.

• Impact ratio: volumen de órdenes agresivas en relación a profundidad.

Acciones:

• Reducir OI límite y apalancamiento en niveles de riesgo.

• Forzar reducción de apalancamiento en mercados con alta volatilidad o profundidad insuficiente.

b. Ordenes falsas

Indicadores:

• Ráfagas de aumento y caída rápida en profundidad.

Acciones:

• Reducir OI límite.

• Si hay desviación significativa, considerar detener mercado.

3. En el lado de las posiciones

El monitoreo busca detectar si el mercado pasa de ser impulsado por negociación a ser dominado por posiciones: acumulación rápida, concentración y ganancias/pérdidas extremas aumentan el riesgo de cascadas de liquidación.

a. OI excesivo a corto plazo

Indicadores:

• OI_national: tamaño de la posición abierta.

• Volumen 24h: volumen de negociación en 24 horas.

• La proporción OI / Volumen 24h aumenta rápidamente, indicando posible cambio de comportamiento.

Acciones:

• Alertar cuando se superen límites.

b. Ganancias y pérdidas de la mayoría

Indicadores:

• Mayoría: lado con más posiciones abiertas.

• Precio medio de entrada de la mayoría.

• Tamaño de la posición mayoritaria.

• Ganancias/pérdidas de la mayoría.

Acciones:

• Alertar en límites.

• Si persiste, reducir OI mediante setOpenInterestCaps.

0x5 Conclusión

El núcleo de HIP-3 es transformar la «nueva incorporación» de un proceso decidido por unos pocos en una capacidad protocolar accesible mediante requisitos. Los constructores, mediante staking, pueden lanzar su propio DEX perp en HyperCore, listar mercados gratuitos inicialmente y, mediante subastas, obtener más cupos, expandiendo el mercado de forma regulada.

Pero también es claro que HIP-3 no elimina riesgos, solo los reconfigura: las responsabilidades en la entrada y operación del sistema recaen más en la calidad del input y gestión del constructor (precio del oracle, frecuencia, selección de markPx, niveles de margen, fijación en horarios no 7×24H, poderes de haltTrading). Un manejo inadecuado puede escalar en cascadas de liquidación, creando brechas y ADL. La cuestión no es solo «puede listar», sino «puede operar con estabilidad».

La respuesta del protocolo a estos riesgos externos es convertir permisos en responsabilidades verificables: staking y votación de validadores para sancionar, y restricciones en precios y apalancamientos (clamp, intervalos, límites de volatilidad, aislamiento) para mantener los escenarios peligrosos en rangos controlados. Así, la verdadera misión de HIP-3 es: ampliar la capacidad mediante apertura, pero garantizar la seguridad mediante restricciones, y a largo plazo, mediante verificabilidad y responsabilidad.