Análisis Profundo del HIP-3: Una Perspectiva Centrada en los Desarrolladores

Propuesta de Mejora de Hyperliquid 3 (HIP-3) [1] introduce un cambio fundamental en cómo se crean y escalan los mercados perpetuos en Hyperliquid. Al abrir el proceso de listado de mercados a constructores externos, HIP-3 transforma el listado de una acción discrecional controlada por la plataforma a una interfaz a nivel de protocolo basada en reglas.

Desde su despliegue en mainnet, los mercados desplegados por constructores han generado más de $13 mil millones en volumen de trading en aproximadamente tres meses, demostrando que HIP-3 puede mejorar materialmente la escalabilidad y flexibilidad de la expansión de mercados. Sin embargo, este cambio no simplemente descentraliza el poder; también redistribuye la responsabilidad. Los riesgos que anteriormente eran absorbidos o mitigados por las operaciones centralizadas de la plataforma ahora recaen directamente sobre los constructores.

Como resultado, la pregunta central bajo HIP-3 ya no es si un mercado puede ser lanzado, sino si puede ser operado de forma segura a lo largo del tiempo. Este informe analiza HIP-3 desde una perspectiva centrada en el constructor, enfocándose en cómo se definen y operan los mercados, los riesgos que enfrentan los constructores, y cómo esos riesgos, en particular los relacionados con los oráculos, pueden mitigarse.

0x0 Antecedentes

La arquitectura de Hyperliquid [2] se aparta de este modelo al desacoplar la infraestructura de ejecución y riesgo de la definición de mercado. Su diseño de doble capa consiste en:

• HyperCore, una blockchain Layer 1 de propósito específico optimizada para el trading de derivados, que proporciona matching, liquidación y liquidación unificados.
• HyperEVM, una capa de aplicación compatible con EVM que permite lógica extensible e interacción con constructores.

Dado que la ejecución y la liquidación se aplican de forma uniforme a nivel de protocolo, los nuevos mercados pueden reutilizar la misma infraestructura central sin reimplementar la lógica de seguridad crítica. Sin embargo, los precios no pueden estandarizarse completamente. Las entradas de los oráculos, el diseño del apalancamiento y las operaciones en tiempo de ejecución varían inevitablemente según el mercado, lo que convierte a los precios en la interfaz principal donde la descentralización se encuentra con el riesgo.

A pesar de esta arquitectura, el proceso de listado para los mercados perpetuos nativos de Hyperliquid, también denominados perps operados por validadores, sigue pareciéndose a un enfoque CEX tradicional. El listado de nuevos contratos está impulsado en gran medida por el equipo central, mientras que los delistados se determinan mediante votaciones de validadores.

HIP-3 fue introducido para descentralizar este proceso de listado al habilitar mercados perpetuos desplegados por constructores. Formaliza la separación entre la definición de mercado y la ejecución aplicada por el protocolo, al permitir que los constructores definan y operen mercados, mientras el protocolo aplica límites estrictos de ejecución y riesgo. Como tal, HIP-3 representa un hito clave hacia un proceso de listado de perps completamente descentralizado.

0x1 Responsabilidades del Constructor: Definición y Operación

Bajo HIP-3, los constructores asumen la responsabilidad integral de la gestión del ciclo de vida del mercado. En esta sección, primero describimos el flujo de lanzamiento del mercado y luego nos enfocamos en los mecanismos operativos que más directamente determinan la estabilidad del mercado en producción.

0x1.1 Flujo de Lanzamiento de Mercado: Definición y Operación

Bajo HIP-3, lanzar un mercado no es una acción única. Como se ilustra en el flujo completo de lanzamiento de mercado a continuación, es un proceso que abarca dos fases distintas: definición de mercado (pasos 1 al 4) y operación de mercado (paso 5).

Durante la fase de definición de mercado, un constructor debe primero hacer staking de 500,000 HYPE en mainnet. Tras cumplir con el requisito de staking, el constructor puede desplegar un DEX perpetuo, que forma un dominio de trading independiente con su propio sistema de margen, libros de órdenes y configuraciones controladas por el desplegador. A nivel del DEX, el constructor selecciona un activo de cotización que se usará como colateral para todos los mercados en ese DEX. El activo de cotización seleccionado debe mantener el estado sin permiso, ya que perder este estado deshabilitará el DEX correspondiente. El constructor entonces define los parámetros centrales del mercado, incluyendo especificaciones del oráculo, parámetros del contrato como el símbolo y los límites de apalancamiento, y tablas de margen. Los primeros tres mercados pueden desplegarse directamente, mientras que los mercados adicionales requieren adquirir slots mediante una subasta holandesa.

Subasta holandesa: Cada ronda dura 31 horas; el precio inicial cada vez es 2× el precio final anterior (último precio ganador / precio más bajo).

Una vez que los mercados están activos, el constructor entra en la fase de operación de mercado. Esta fase implica actualizar continuamente los precios del oráculo a través de la interfaz setOracle, mantener las configuraciones de apalancamiento y margen, monitorear la liquidez y el interés abierto, y ejecutar acciones de emergencia como detener el trading y liquidar posiciones cuando sea necesario.

En la práctica, la mayoría de las fallas graves bajo HIP-3 ocurren no durante la definición del mercado, sino durante la operación prolongada bajo condiciones de mercado tensas. Es importante destacar que la responsabilidad del constructor no termina inmediatamente después de detener los mercados. El unstaking solo es posible después de que todos los mercados estén liquidados, y el stake permanece sujeto a slashing durante el período de unstaking obligatorio.

0x1.2 Áreas de Enfoque Críticas: Precios y Solvencia

Los constructores enfrentan dos áreas de enfoque acopladas a lo largo de la definición y la operación del mercado: configuración del oráculo y formación de precios, y solvencia del mercado bajo presión. Estas dos áreas están estrechamente acopladas, ya que los fallos de precios pueden propagarse rápidamente hacia el estrés de solvencia a través de los controles de riesgo a nivel de protocolo.

1. Configuración del Oráculo y Formación de Precios

Hyperliquid define dos precios:

• Precio del Oráculo: una mediana ponderada de los precios medios spot de los principales exchanges externos, diseñada para ser independiente de los datos del mercado interno de Hyperliquid y utilizada principalmente para anclar el financiamiento.
• Precio de Marca: un precio de riesgo interno derivado de múltiples entradas, incluyendo el precio del oráculo y datos del mercado local, utilizado para el PnL (ganancias y pérdidas) no realizado y los controles de riesgo.

En resumen, el precio del oráculo ancla el financiamiento, mientras que el precio de marca impulsa las verificaciones de margen, las liquidaciones y los disparadores de TP (Toma de Ganancias) y SL (Stop Loss).

Bajo HIP-3, los roles del precio del oráculo y el precio de marca no cambian, pero el mecanismo de cómputo sí cambia:

a) Entradas a setOracle

• oraclePx (requerido): misma definición que en HyperCore.
• markPx (opcional): 0–2 candidatos de precio de marca calculados externamente.
• externalPerpPx (requerido): un valor de referencia para prevenir desviaciones repentinas del precio de marca.

Los constructores típicamente despliegan nodos de retransmisión para alimentar precios: oraclePx se calcula a partir de múltiples fuentes externas, markPx es calculado por el retransmisor con un algoritmo personalizado, y externalPerpPx a partir de la mediana ponderada de los precios medios de perps de múltiples CEXs.

b) Precio de marca real

• Calcular marca local: mediana(mejor oferta de compra, mejor oferta de venta, última operación).
• Tomar la marca local y markPx (0–2 valores) juntos y tomar la mediana para obtener el nuevo precio de marca.

c) Restricciones de setOracle

• Frecuencia de actualización: al menos 2.5s entre llamadas; si markPx no se actualiza en 10s, recurre al precio de marca local.
• Límites de amplitud: markPx puede cambiar como máximo ±1% por actualización; todos los precios se limitan dentro de 10× el precio de inicio del día.

¿Por qué el tipo de activo importa para los precios en HIP-3?

Bajo HIP-3, los mercados perpetuos pueden lanzarse para cualquier tipo de activo. Estos activos generalmente pueden dividirse en activos 24/7 (negociables las 24 horas del día) y activos no 24/7 (negociables solo durante horas de mercado específicas, sin trading spot fuera de esas horas). La diferencia en las horas de trading determina fundamentalmente cómo se obtienen y mantienen los precios.

Para activos 24/7 (p. ej., BTC), se pueden obtener precios relativamente estables de forma continua agregando datos de CEXs, DEXs o servicios de oráculos de confianza.

Para activos no 24/7 (p. ej., acciones), solo hay suficiente liquidez y precios de mercado externo confiables disponibles durante las horas de trading oficiales. Para mantener dichos activos negociándose continuamente en HIP-3, se debe usar un mecanismo de precios separado durante las horas fuera del mercado.

Tomando los mercados de perps de acciones en trade.xyz como ejemplo:

• Durante las horas de mercado, los precios estables del oráculo son proporcionados por servicios de oráculos externos como Pyth.
• Durante las horas fuera del mercado, los precios se ajustan en función del último precio de cierre del activo, combinado con la presión interna de compra/venta del libro de órdenes. El precio de marca está restringido a fluctuar dentro de ±1 / apalancamiento_máximo del último precio de cierre (p. ej., Tesla: apalancamiento 10× → ±10%).

2. Solvencia del Mercado Bajo Presión

Hyperliquid adopta dos mecanismos, liquidación y ADL (desapalancamiento automático), para mantener la solvencia del mercado. Bajo HIP-3, tanto la liquidación como el ADL siguen en gran medida el diseño de HyperCore. La diferencia principal es una restricción a nivel de protocolo: HLP (Proveedor de Hiperliquidez), que sirve como la bóveda del protocolo, no puede tomar posiciones de riesgo en los mercados HIP-3. Como resultado, el buffer de bóveda intermedio que puede absorber posiciones entre la liquidación del mercado y el ADL en HyperCore está ausente en HIP-3.

Dada la importancia de esta vía de liquidación a ADL durante condiciones de mercado tensas, revisamos la liquidación y el ADL en detalle a continuación. Toda la mecánica de solvencia analizada aquí asume margen aislado, el único modo de margen actualmente soportado en los mercados HIP-3.

a) Liquidación

La liquidación se activa cuando el valor neto de la posición (valor de posición aislada) es insuficiente para cumplir con el requisito de margen de mantenimiento, se vuelve liquidable. Todas las verificaciones relacionadas con la liquidación se basan en el precio de marca, no en un precio de ejecución particular.

La fórmula del precio de liquidación se define de la siguiente manera:

Donde:

• side: 1 para posiciones largas, -1 para posiciones cortas
• l es la tasa de margen de mantenimiento

El valor de MAINTENANCE_LEVERAGE está determinado por el nivel de margen correspondiente a la posición. De ese nivel, se obtiene la tasa de margen de mantenimiento mmr:

Cuando se configuran los niveles de margen, se aplica el mmr del nivel que corresponde al valor nocional de la posición al precio de liquidación.

• margen_disponible (aislado): margen_aislado - margen_de_mantenimiento_requerido

Una vez que una posición se vuelve liquidable, el sistema primero intenta cerrarla mediante órdenes de mercado en el libro de órdenes. Si la ejecución logra devolver el riesgo dentro de límites seguros, cualquier margen restante se devuelve al trader.

Sin embargo, en casos de profundidad insuficiente del libro de órdenes o brechas de precios, el precio de ejecución promedio real puede ser significativamente peor que el precio de marca, resultando en un "déficit de liquidación".

El valor de posición aislada se refiere al valor neto de una posición aislada al precio de marca actual, representando el margen asignado a esa posición después de tener en cuenta el PnL no realizado.

b) ADL (desapalancamiento automático)

En escenarios extremos, el mecanismo ADL (desapalancamiento automático) actúa como último recurso.

El ADL se activa cuando el valor de posición aislada se vuelve negativo. El sistema clasifica a las contrapartes rentables por PnL y apalancamiento, luego reduce o cierra forzosamente estas posiciones al precio de marca anterior (el precio de marca registrado anteriormente antes de que se active el ADL). Al usar las ganancias del lado ganador para compensar el déficit, el protocolo permanece solvente y no incurre en deudas incobrables.

El índice de clasificación se calcula como:

Aquí, notional_position se refiere al valor de mercado absoluto de la posición al precio de marca vigente, calculado como |tamaño_posición| × precio_de_marca. account_value denota el patrimonio de la cuenta al precio de marca, es decir, el valor del colateral más el PnL no realizado.

Ejemplo:

• Antes de que se active el ADL, el precio de marca del sistema = 3,000.
• Debido a las restricciones de setOracle, el nuevo precio de marca solo puede actualizarse a 2,970 (−1%).
• Sin embargo, el lado de oferta de compra del libro de órdenes es muy delgado. Después de que las órdenes de mercado de liquidación impactan el libro, el precio de ejecución promedio real = 2,910 (−3% relativo a 3,000).
• Las pérdidas en posiciones largas se liquidan a 2,910, lo que potencialmente lleva el valor de posición aislada por debajo de cero y crea un déficit, lo que activa el ADL.
• El ADL entonces selecciona posiciones del lado opuesto (cortos rentables) y las reduce/cierra forzosamente al precio de marca anterior = 3,000, trasladando el déficit a "el lado ganador ganando pasivamente menos".

0x2 Panorama de Riesgos para el Constructor

Bajo HIP-3, el riesgo ya no es abstracto ni puramente teórico para los constructores. A través del staking y el slashing gobernado por validadores, los fallos operativos y las configuraciones incorrectas pueden traducirse directamente en penalizaciones económicas. Como resultado, entender cómo se activa el slashing, y qué tipos de comportamiento del constructor pueden llevarlo a ocurrir, se convierte en el centro del modelo de riesgo del constructor. En consecuencia, esta sección primero explica el mecanismo de slashing como marco de responsabilidad, y luego analiza las dos fuentes primarias de riesgo para el constructor bajo HIP-3.

0x2.1 Mecanismo de Slashing y Responsabilidad

HIP-3 aplica la responsabilidad a través del staking y el slashing gobernado por validadores. El slashing está estrictamente basado en resultados. Hyperliquid no distingue entre comportamiento malicioso, errores operativos, compromiso de clave privada o fallo de dependencia de terceros.

Requisito de stake: En mainnet, los constructores deben mantener 500k HYPE en staking. Incluso si un constructor detiene todos sus mercados, deben continuar manteniéndolo durante 30 días (la responsabilidad no desaparece inmediatamente porque el trading esté detenido).

Si las acciones de un constructor resultan en un estado inválido, tiempo de inactividad prolongado o degradación significativa del rendimiento, el slashing puede activarse. Dependiendo de la gravedad, el slashing puede ir desde una reducción parcial del stake hasta la quema total del stake. Este diseño hace a los constructores económicamente responsables del comportamiento completo en tiempo de ejecución de sus mercados.

El porcentaje de slashing es decidido por votación de validadores, con límites superiores de referencia:

• Estado inválido / tiempo de inactividad prolongado: hasta 100%
• Tiempo de inactividad corto: hasta 50%
• Degradación del rendimiento: hasta 20%

Los tokens recortados se queman, no se redistribuyen.

Bajo HIP-3, el riesgo del constructor proviene principalmente de dos fuentes: configuración incorrecta de parámetros internos y dependencias externas de oráculos. Las siguientes secciones examinan estas dos fuentes en detalle y explican cómo pueden traducirse en resultados de slashing.

0x2.2 Riesgos por Configuración Incorrecta de Parámetros Internos

Los riesgos de configuración incorrecta incluyen apalancamiento excesivo en mercados de baja liquidez, diseño inadecuado de tablas de margen, cambios repentinos de parámetros que vuelven liquidables a un gran número de posiciones, y uso inapropiado de controles de emergencia como detener el trading.

Estos riesgos son en gran medida deterministas y prevenibles. Con suficiente cuidado, revisión y disciplina operativa, la mayoría de los errores de configuración interna pueden evitarse. Si bien son importantes, no son los riesgos más estructuralmente desafiantes bajo HIP-3.

1. setOracle

Los precios del oráculo típicamente provienen de los servidores retransmisores del constructor, lo que introduce riesgo de centralización. Si la clave privada se filtra o el retransmisor sufre un DDoS, el precio del oráculo del mercado puede ser manipulado maliciosamente o permanecer divergente durante mucho tiempo.

2. haltTrading

El constructor puede cancelar todas las órdenes en el mercado a través de haltTrading y cerrar posiciones al precio de marca actual. Esta operación debe usarse con cautela. Por ejemplo, si se detecta que el mercado está siendo manipulado maliciosamente por un atacante y se llama a haltTrading para cerrar al precio de marca, puede directamente realizar la ganancia no realizada del atacante (donde el atacante de otro modo podría tener dificultades para encontrar suficientes órdenes opuestas), y también puede llevar a deudas incobrables.

3. setMarginTableIds e InsertMarginTable

• InsertMarginTable: define una nueva tabla de margen, especificando los requisitos de margen y el apalancamiento máximo para una clase de activos.
• setMarginTableIds: vincula un mercado a un marginTableId especificado.

Para un mercado de baja liquidez / market-making insuficiente, establecer un apalancamiento máximo demasiado alto aumenta la probabilidad de activar el ADL.

Cambiar repentinamente el marginTableId es equivalente a modificar la tasa de margen de mantenimiento de las posiciones de los usuarios, lo que puede convertir muchas cuentas de seguras a liquidables al mismo tiempo, desencadenando liquidaciones en cascada.

4. setMarginModes

HIP-3 actualmente solo permite margen aislado y puede soportar margen cruzado en el futuro. Dentro de un DEX que aloja tanto mercados de alta como de baja liquidez, el margen cruzado puede habilitar el contagio de riesgo donde las pérdidas en mercados ilíquidos se propagan a mercados líquidos. Por lo tanto, hasta que el equipo oficial proporcione una solución madura, no se recomienda que los constructores introduzcan margen cruzado.

0x2.3 Riesgos por Dependencias Externas de Oráculos

Para los activos 24/7, el riesgo principal reside en la precisión y estabilidad de los servicios de oráculos externos, así como en los riesgos de centralización de los servidores retransmisores analizados anteriormente. Cualquier interrupción, retraso o manipulación en estas dependencias externas puede afectar directamente la integridad de los precios y los controles de riesgo posteriores.

Para los activos no 24/7, la superficie de riesgo es significativamente más amplia y se concentra principalmente en cómo se obtienen o calculan los precios del oráculo durante las horas de no trading.

Tomando trade.xyz como ejemplo, durante los períodos fuera del mercado los precios se derivan de una combinación del último precio disponible del oráculo externo y los precios internos del mercado. Los fines de semana, los mercados perpetuos de acciones a menudo sufren de liquidez severamente reducida—los libros de órdenes se adelgazan y los creadores de mercado reducen sus cotizaciones—mientras no hay precios de oráculos externos disponibles para proporcionar anclaje. Aunque se impone un límite estricto en el movimiento de precios (p. ej., 1 / apalancamiento_máximo), esta restricción aún puede ser demasiado laxa para activos de baja volatilidad. Los movimientos de precios dentro de este rango pueden sin embargo desencadenar liquidaciones a gran escala o incluso eventos ADL.

El 14 de diciembre de 2025, el mercado XYZ100-USDC en trade.xyz—un contrato perpetuo que sigue al NASDAQ-100—fue manipulado. Un atacante abrió posiciones cortas de 398 XYZ100 (aproximadamente $10M USDC en exposición nocional), causando un grave desvío de precio. Un gran número de posiciones largas fueron liquidadas, y las propias liquidaciones empujaron aún más los precios hacia abajo, resultando finalmente en aproximadamente $13M USDC en liquidaciones del lado largo.

Por otro lado, durante las horas de no trading, la ausencia de un precio de oráculo continuo y anclado externamente obliga a los mercados a depender de una banda de precios interna restringida formada por el "último precio externo + libro de órdenes interno" (p. ej., trade.xyz limita la fluctuación máxima a 1/apalancamiento_máximo).

El riesgo más crítico surge en la transición de reapertura del mercado. Los mercados externos pueden proporcionar repentinamente un precio de referencia claro y autoritativo. Si este precio exhibe una brecha significativa con respecto a los precios internos fuera de horario, el sistema enfrenta dos caminos desfavorables: o bien los precios permanecen limitados, resultando en una severa divergencia entre el valor razonable externo y los precios negociables, o bien el sistema cambia rápidamente de vuelta al anclaje externo, desencadenando una reprecificación abrupta. Ambos escenarios pueden concentrar la presión de liquidación dentro de una ventana de tiempo corta y, en casos extremos, llevar a un aumento en los eventos ADL.

0x3 Controles de Riesgo para el Constructor

La disciplina de configuración por sí sola no puede eliminar el riesgo. Las estrategias de mitigación más efectivas se centran en reducir la exposición a fallos de dependencia de oráculos.

0x3.1 Seleccionar Oráculos Estables

Para los activos negociados no 24/7 como las acciones, el principal desafío radica en los precios durante las horas fuera del mercado. Durante estos períodos, las referencias de precios estables y ancladas externamente son escasas, lo que hace que los mercados sean más susceptibles a la manipulación o a la deriva endógena bajo una liquidez delgada.

Actualmente, los enfoques de la industria generalmente se dividen en dos direcciones:

• Suspender las actualizaciones del oráculo y restringir el trading durante las horas fuera del mercado. Por ejemplo, el protocolo Lighter solo acepta órdenes de reducción cuando el mercado subyacente está cerrado. Protocolos como Ostium además reducen el apalancamiento máximo durante las horas fuera del mercado y liquidan forzosamente las posiciones que superan los nuevos límites.
• Adoptar un "mecanismo de precios interno", como se ve en trade.xyz, donde el protocolo continúa operando durante las horas fuera de mercado dependiendo de la liquidez interna y los algoritmos de precios cuando los datos externos no están disponibles.

Estos dos enfoques reflejan una compensación fundamental entre seguridad y experiencia del usuario. El primer enfoque prioriza controles de riesgo estrictos pero degrada significativamente la continuidad del trading y la experiencia del usuario. El segundo preserva el trading continuo pero, debido a la falta de referencias externas, aumenta el riesgo de que los precios internos diverjan del valor fundamental del activo.

Durante los períodos fuera del mercado, los precios del protocolo deben evitar degenerar completamente en un precio puramente interno. En cambio, introducir anclajes de referencia externos puede reducir los riesgos de desacoplamiento y brechas. Las posibles referencias incluyen:

• Blue Ocean ATS. Como plataforma de trading fuera de horario/nocturna, puede proporcionar un grado de referencia de precio continuo durante los cierres (más oportuno que el "último cierre"), ayudando a generar precios de oráculo durante el período de cierre o sirviendo como línea base de monitoreo para el desacoplamiento.
• Cotizaciones de CFD de fin de semana de IG. Las cotizaciones de CFD de fin de semana pueden proporcionar una señal de precio alternativa que refleja las "expectativas del mercado del fin de semana", adecuada como ancla externa o comparación de monitoreo durante los cierres para ayudar a detectar con anticipación la dirección y magnitud probable de una "brecha de apertura".

La característica común de estas fuentes es su capacidad para proporcionar señales de precios durante las horas fuera del mercado. Sin embargo, no comparten la misma estructura de mercado que el mercado spot subyacente y, por lo tanto, son más adecuadas como anclajes, referencias o señales de alerta temprana, en lugar de sustitutos incondicionales.

0x3.2 Verificación de Precios

Bajo HIP-3, los precios del oráculo provienen de servidores retransmisores operados por constructores, lo que introduce preocupaciones de centralización. Para mitigar esto, se alienta a los constructores a implementar un marco de verificación de precios que permita a cualquier usuario o institución verificar la corrección y equidad de los precios fuera de la cadena—similar a RedStone, que empaqueta precios junto con fuentes de datos y pruebas criptográficas.

1. Transparencia de Datos

• Especificación del algoritmo: divulgar públicamente los algoritmos de precios y la lógica de cálculo.
• Lista de fuentes de datos: todas las fuentes deben ser públicas, inmunes a la manipulación del constructor, y documentadas con interfaces y parámetros detallados.
• Reglas de envío de precios: permisos, condiciones de activación, frecuencia de actualización y restricciones de volatilidad para setOracle.

2. Pruebas de Precio

Para cada llamada a setOracle, generar una prueba correspondiente que contenga:

• Entradas: respuestas crudas (o normalizadas) de cada fuente de datos en el timestamp de muestreo.
• Cómputo: valores intermedios reproducibles en cada paso de cálculo.
• Salidas: el precio del oráculo enviado en cadena.

Cada prueba se serializa en un proofHash, que luego es firmado por el oracleUpdater.

3. Compromisos en Cadena

• Mantener una lista secuencial de entradas proofHash en un árbol de Merkle.
• Periódicamente (p. ej., cada hora o diariamente) publicar el MerkleRoot en cadena.

4. Verificación

• Proporcionar herramientas de código abierto o una página web donde los usuarios ingresen un rango de tiempo o un hash de transacción de setOracle
• Verificar firmas, timestamps y MerkleRoot, etc.
• Recalcular los precios del oráculo usando el algoritmo público para comparación.

0x3.3 Monitoreo de Riesgos

La verificación de precios hace que setOracle sea recalculable y auditable, estableciendo si los feeds de precios son confiables. Sin embargo, no puede proteger contra el deterioro del mercado en vivo. Las interrupciones del feed, la divergencia de precios y la degradación de la liquidez—cuando se combinan con un alto interés abierto (OI)—pueden fácilmente escalar anomalías localizadas en riesgos sistémicos como liquidaciones en cascada o incluso eventos ADL.

Por lo tanto, las anomalías del mercado deben detectarse y convertirse en señales observables lo antes posible, y abordarse dentro de una ventana de tiempo para contener el riesgo dentro de límites manejables.

Para hacer que el monitoreo sea accionable en lugar de fragmentado, organizamos las señales en tres capas, cada una mapeada a un modo de fallo distinto y prioridad de respuesta.

• El monitoreo del lado del precio detecta fallos del feed del oráculo y desacoplamientos que pueden invalidar los controles de riesgo en la fuente, por lo que se trata como la prioridad más alta y normalmente se aborda mediante conmutación por error del retransmisor, límites de interés abierto y reducciones de apalancamiento.
• El monitoreo del lado del libro de órdenes captura la retirada de liquidez y la profundidad falsificada que amplían el deslizamiento de liquidación y el riesgo de déficit, por lo que las intervenciones se centran en limitar la exposición incremental y forzar el desapalancamiento cuando aumenta la fragilidad.
• El monitoreo del lado de posiciones rastrea la acumulación rápida de interés abierto y la concentración de un solo lado que hace a los mercados vulnerables a las cascadas, y generalmente tiene menor prioridad que las señales de precio y liquidez, sirviendo principalmente como una capa de alerta temprana que informa límites más estrictos y alertas elevadas.

Las siguientes secciones detallan cada capa a su vez, junto con los puntos de monitoreo correspondientes y las acciones recomendadas.

1. Monitoreo del Lado del Precio

a) Fallo del Feed del Oráculo

Métricas:

• Usar observables en cadena para juzgar si el feed está estancado:

Umbrales:

• Nivel 1: ( ∆t > 5s ) — el proceso del retransmisor puede estar estancado o bloqueado
• Nivel 2: ( ∆t > 15s ) — los precios en cadena pueden estar severamente desacoplados y cada vez más impulsados por el mercado

Acciones:

• Nivel 1: realizar verificaciones de salud del retransmisor, cambiar a retransmisores de respaldo y emitir alertas con diagnósticos de salud
• Nivel 2: llamar a setOpenInterestCaps para reducir el límite de OI

b) Desacoplamiento de Precio

Métricas:

• Señal A (d1): desviación entre el precio de marca y el precio del oráculo.

• Señal B (d2): desviación entre el precio medio del libro de órdenes y el precio del oráculo.

• Señal C (d3): desviación entre el precio de marca y el precio medio.

• Señal D (ext_diff): desviación entre el precio del oráculo y el precio de referencia externo.

Lógica de Umbral:

• Nivel 1: al menos 2 de A, B, D superan los umbrales.
• Nivel 2: al menos 3 de A, B, C, D superan los umbrales durante X segundos.

Acciones:

• Nivel 1: reducir el límite de OI mediante setOpenInterestCaps.
• Nivel 2: actualizar gradualmente las tablas de margen para reducir el apalancamiento máximo por niveles, y habilitar mecanismos de limitación en los retransmisores.
• Nivel 3: alertas persistentes bajo condiciones de Nivel 2. El constructor entonces evalúa si invocar haltTrading.

2. Monitoreo del Lado del Libro de Órdenes

a) Retirada de Liquidez

Métricas:

• depth_band(±x%): liquidez del libro de órdenes disponible dentro de ±x% del precio medio.
• spread = mejorPrecioVenta - mejorPrecioCompra: diferencial de precio para medir el ensanchamiento del spread.
• aggressiveVolume_Δt: volumen tomador dentro de Δt (agregado por lado de operación).
• impact_ratio: indicador de fragilidad del mercado (valores más altos indican mayor vulnerabilidad al impacto en el precio).

Patrones de Riesgo:

• depth_band disminuye mientras spread e impact_ratio aumentan.

Acciones:

• Nivel 1: establecer límite de OI = OI actual mediante setOpenInterestCaps, limitando las posiciones incrementales.
• Nivel 2: forzar el desapalancamiento mediante setMarginTableIds, mientras se liquidan posiciones de alto apalancamiento y alto riesgo.

b) Liquidez Falsificada

Patrones de Riesgo:

• Picos repentinos en depth_band seguidos de colapso dentro de una ventana de tiempo corta.

Acciones:

• Nivel 1: llamar a setOpenInterestCaps para establecer límite de OI = OI actual.
• Nivel 2: si se combina con desacoplamiento severo, considerar detener el mercado.

3. Monitoreo del Lado de Posiciones

El monitoreo del lado de posiciones no intenta predecir la dirección del precio. En cambio, identifica transiciones de actividad de trading equilibrada a acumulación de posiciones de un solo lado. Cuando el OI se acumula rápidamente, las posiciones se vuelven altamente concentradas y el PnL del lado mayoritario alcanza extremos, incluso perturbaciones exógenas menores pueden desencadenar cascadas de liquidación o eventos ADL.

Como resultado, las acciones del lado de posiciones típicamente tienen menor prioridad que las intervenciones del lado del precio y del libro de órdenes.

a) OI Excesivo a Corto Plazo

Métricas:

• OI_notional: nocional del interés abierto.
• Volume_24h_notional: volumen nocional de 24 horas.

Una ratio que aumenta rápidamente indica un cambio de rotación activa a acumulación especulativa de posiciones y a menudo precede a una volatilidad brusca.

Acciones:

• Nivel 1: activar alertas cuando se superan los umbrales.

b) PnL del Lado Mayoritario

El lado mayoritario se refiere al lado (Largo o Corto) con más tenedores de posiciones dentro de la ventana de observación.

Métricas:

• avgEntry_major: precio de entrada promedio de las posiciones del lado mayoritario.
• size_major: tamaño total de posición del lado mayoritario.
• equity_major: patrimonio total del lado mayoritario.

El PnL del lado mayoritario y su ratio se definen de la siguiente manera:

Acciones:

• Nivel 1: alerta al superar el umbral.
• Nivel 2: si persiste, considerar llamar a setOpenInterestCaps para reducir el límite de OI.

0x4 Conclusión

La narrativa central de HIP-3 es sencilla. Transforma los listados de mercado de un proceso discrecional controlado por unos pocos en una capacidad a nivel de protocolo que cualquier constructor calificado puede invocar una vez que se cumplen los requisitos. Al hacer staking, los constructores pueden lanzar sus propios DEXs perp en HyperCore, listar un conjunto inicial de mercados sin costo y adquirir slots adicionales a través de subastas. Esto cambia la expansión del mercado de esperar aprobación a escalado sin permisos basado en reglas.

Lo que también es igualmente claro es que HIP-3 no elimina el riesgo. Lo reposiciona y lo reformula. Las responsabilidades previamente absorbidas por los controles de riesgo a nivel de plataforma ahora son en gran medida asumidas por los constructores a través de sus entradas y calidad operativa. Esto incluye los precios del oráculo y la cadencia de actualización mediante setOracle, la selección y restricciones de markPx, el diseño de apalancamiento escalonado a través de tablas de margen, los rangos de precios fuera del mercado para activos no 24/7, y controles poderosos como haltTrading, que pueden contener pérdidas o amplificarlas. Bajo una liquidez delgada, la configuración incorrecta o el fallo operativo pueden magnificarse en cascadas de liquidación, pérdidas por brechas y, en última instancia, eventos ADL. La pregunta ya no es "¿Puede listarse un mercado?" sino más bien "¿Puede mantenerse estable después del listado?"

A nivel de protocolo, Hyperliquid aborda esta redistribución de riesgos convirtiendo los permisos en permisos responsables. El staking, combinado con el slashing gobernado por validadores, establece consecuencias económicas claras para la mala operación del constructor. Las restricciones sobre precios y apalancamiento, incluyendo límites, intervalos de actualización, límites de volatilidad y requisitos de margen aislado, apuntan a mantener los riesgos de cola más peligrosos dentro de límites manejables. En este marco, la propuesta de valor de HIP-3 queda clara: escalar a través de la apertura, seguridad a través de restricciones, y sostenibilidad a largo plazo a través de la verificabilidad y la responsabilidad.

HIP-3 no hace que los listados sean más libres. Los hace más estandarizados, desplegables, operables y sujetos a slashing. Si esta estandarización puede operar a escala depende en última instancia de la calidad real del diseño del oráculo, los parámetros de apalancamiento y riesgo, y el monitoreo en tiempo de ejecución. Si está diseñando reglas de acceso al mercado, plantillas de parámetros, sistemas de alertas o flujos de trabajo de emergencia sobre HIP-3, o si requiere auditoría y soporte de seguridad continuo, no dude en contactar a BlockSec en [email protected].

Referencias

[1] https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-improvement-proposals-hips/hip-3-builder-deployed-perpetuals

[2] https://hyperliquid.gitbook.io/hyperliquid-docs

Acerca de BlockSec

BlockSec es un proveedor integral de seguridad blockchain y cumplimiento cripto. Construimos productos y servicios que ayudan a los clientes a realizar auditorías de código (incluyendo contratos inteligentes, blockchain y billeteras), interceptar ataques en tiempo real, analizar incidentes, rastrear fondos ilícitos y cumplir con las obligaciones AML/CFT, a lo largo de todo el ciclo de vida de los protocolos y plataformas.

BlockSec ha publicado múltiples artículos de seguridad blockchain en conferencias de prestigio, reportado varios ataques de día cero en aplicaciones DeFi, bloqueado múltiples hackeos para rescatar más de 20 millones de dólares, y asegurado miles de millones en criptomonedas.

• Sitio web oficial: https://blocksec.com/

• Cuenta oficial de Twitter: https://twitter.com/BlockSecTeam

• 🔗 Servicio de Auditoría BlockSec : Enviar una solicitud

• 🔗 Aplicación de Seguridad Phalcon: Reservar una demo

• 🔗 Phalcon Compliance