Builder imprescindible: Cómo identificar y mitigar riesgos en el mercado HIP-3

HIP-3（Propuesta de Mejora Hyperliquid 3） en línea desde hace tres meses en la red principal, el volumen acumulado de mercados personalizados desplegados por terceros ha superado los 13,000 millones de dólares. ¿Qué hay detrás de esta cifra? Es la descentralización del poder en la plataforma: el poder de “listar” que antes monopolizaban los exchanges centralizados ha sido transformado en un estándar abierto de interfaces. Los Builders solo necesitan apostar 500,000 HYPE tokens para desplegar mercados de contratos perpetuos en la base unificada de trading y liquidación de Hyperliquid.

Pero con la descentralización del poder, también se trasladan los riesgos. ¿Cómo identificar estos riesgos y cómo detectar señales de problema en la operación en tiempo real? Esa es una competencia clave que todo Builder debe dominar.

Fundamentos de la arquitectura: entender las fuentes de riesgo de HIP-3

Para identificar los riesgos en HIP-3, primero hay que comprender su diseño arquitectónico.

HIP-3 se construye sobre la arquitectura de doble capa de Hyperliquid. HyperCore es una blockchain personalizada optimizada para contratos, capaz de procesar 200,000 órdenes por segundo con finalidad determinista; HyperEVM es la capa de aplicación, que puede ejecutar contratos inteligentes. La genialidad de esta arquitectura radica en que: la coincidencia, liquidación y compensación son proporcionadas por el protocolo de forma unificada, sin que el Builder tenga que construir un sistema de trading desde cero.

Pero precisamente por eso, los límites de responsabilidad del Builder se vuelven claros pero frágiles — claros en que las responsabilidades están definidas (definir y operar el mercado), frágiles en que toda la responsabilidad se externaliza (el control del riesgo está completamente en manos del Builder).

El Builder debe apostar 500k HYPE y asumir dos responsabilidades principales:

• Definición del mercado: determinar las fuentes de precios del oráculo, las especificaciones del contrato (apalancamiento, tamaño mínimo de orden, etc.), selección de activos colaterales.
• Operación del mercado: mantener la alimentación de precios, ajustar la tabla de márgenes (límite de apalancamiento), detener el mercado si es necesario.

Una vez desplegado, la apuesta queda bloqueada por 30 días para solicitar su desbloqueo. Esto significa que cualquier mala operación puede ser sancionada con una votación de penalización por parte de los validadores — pero antes de votar, el Builder debe detectar la existencia del problema.

Mecanismo de precios en tres niveles: ¿cómo evaluar la salud del precio del Oracle?

El mecanismo de alimentación de precios en HIP-3 es el elemento más crítico y también el más propenso a riesgos. El Builder debe entender las tres entradas de precios en la interfaz setOracle:

oraclePx (obligatorio): calculado por el relayer del Builder, sirve como ancla para la tasa de financiación. markPx (opcional): uno o dos conjuntos de precios externos enviados por el Builder, candidatos a ser el precio de referencia. externalPerpPx (obligatorio): mediana ponderada de perp de CEX, para evitar que el mark price se desvíe bruscamente.

El precio final de referencia no se obtiene directamente del feed, sino que se toma la mediana entre el libro local (mediana de mejor bid/ask/último) y markPx. ¿Qué implica esto?

Implica que hay múltiples puntos de fallo en el cálculo del precio:

• Si el relayer está desconectado o sufre un ataque DDoS, oraclePx se interrumpe.
• Si el algoritmo de markPx tiene defectos, puede ser explotado por arbitraje.
• Si el libro local es delgado, la mediana puede distorsionar el precio.

Las restricciones en setOracle parecen estrictas:

• Frecuencia de actualización: mínimo 2.5 segundos entre llamadas, y si no se actualiza en 10 segundos, se vuelve a usar el precio local.
• Limitación de amplitud: markPx no puede variar más de ±1% en cada actualización, y se limita a un rango de 10 veces el precio de apertura del día.

Pero estas restricciones son menos efectivas en activos que no operan 24/7, como acciones.

Riesgos en activos no 7×24H: trampas en precios durante el cierre

Para activos como BTC, que operan 24/7, el Builder puede confiar en fuentes de precios continuas de CEX/DEX. Pero ¿cómo determinar el precio durante el cierre en activos como acciones?

Actualmente, se usa un mecanismo especial basado en: el último precio de cierre + presión del libro interno. Es decir, el mark price se limita a fluctuar en un rango de ±10% (por ejemplo, con apalancamiento 10x) respecto al último cierre.

¿Cuál es el problema? Cuando el mercado externo carece de liquidez, la profundidad del libro interno también es escasa. Si entra una orden grande, puede causar movimientos falsos en el precio durante el cierre, especialmente si hay muchas posiciones largas.

El 14 de diciembre de 2025, el mercado XYZ100-USDC de trade.xyz (que replica NASDAQ100) fue manipulado: un atacante creó 398 posiciones cortas (valor aproximado 10M USDC), bajando artificialmente el precio y provocando liquidaciones masivas de largos en poco tiempo, con aproximadamente 13M USDC en posiciones largas forzadas a cerrar.

La raíz del problema:

• Falta de anclaje externo durante el cierre.
• Profundidad interna insuficiente para soportar volatilidad fuera del rango.
• La liquidación en marcha amplifica la caída del precio.

Riesgo de los oráculos: ¿cómo detectar amenazas de centralización y despegue?

El servidor relayer desplegado por el Builder tiene riesgos de centralización inherentes. La pérdida de claves privadas, ataques DDoS o errores en el algoritmo pueden interrumpir o manipular la alimentación de precios.

Cuatro señales clave para detectar riesgos en el oráculo:

1. Retraso o interrupción en la alimentación de precios

   • Monitoreo: timestamp de la última llamada a setOracle en la cadena.
   • Umbral de alerta: si no se actualiza en más de 10 segundos, el sistema vuelve automáticamente al precio local, aumentando el riesgo de despegue.
   • Respuesta: cambiar a relayer de respaldo, emitir alerta de salud.

2. Despegue del precio

   • Indicadores:
     • desviación entre oraclePx y el precio medio de CEX perp
     • diferencia entre markPx y oraclePx
     • divergencia entre libro local y mercado externo
   • Método: si ≥2 indicadores superan el umbral, se considera despegue.
   • Respuesta: reducir gradualmente el apalancamiento máximo, activar mecanismos de clamp más estrictos.

3. Saltos en apertura en activos no 7×24H

   • Monitoreo: diferencia entre precio interno y precio de apertura en el cierre.
   • Fuente de referencia: Blue Ocean ATS (negociación post-cierre) o cotizaciones CFD de fin de semana.
   • Detección: si el salto es >5%, emitir advertencia anticipada.

4. Liquidez falsa

   • Monitoreo: profundidad del libro y ratio de absorción (volumen de comer órdenes / volumen de órdenes pendientes).
   • Detección: caída rápida de la profundidad, aumento del spread, impacto en la relación de comer órdenes.
   • Respuesta: reducir límite de OI, limitar nuevas posiciones.

Trampas en la configuración de parámetros: riesgos que los Builders suelen pasar por alto

Muchos creen que establecer parámetros fijos es suficiente, pero en realidad, la capacidad de ajustarlos dinámicamente es la verdadera prueba de la operación.

Riesgos en la configuración:

1. Apalancamiento demasiado alto En mercados con baja liquidez, un apalancamiento excesivo aumenta la probabilidad de activación de ADL (desapalancamiento automático). Cuando las posiciones crecen rápidamente y la mayoría de las posiciones están cerca del límite, cualquier movimiento de precio puede desencadenar liquidaciones en cadena.

2. Cambios bruscos en la tabla de márgenes Modificar la tabla de márgenes de repente equivale a cambiar el margen de mantenimiento para todos los usuarios. Muchos se vuelven “liquidados” instantáneamente, causando liquidaciones masivas. Estas operaciones deben anunciarse con antelación y hacerse en fases.

3. Uso indebido de haltTrading El Builder puede detener el mercado, cancelar órdenes y liquidar a precio de mark. Pero si se usa mal, puede beneficiar a atacantes: al detener y liquidar a precio de mark, se aseguran ganancias potenciales, ya que no hay contrapartes reales en el mercado.

4. Modelo de margen cruzado (riesgo futuro) Actualmente, HIP-3 solo soporta margen aislado. En el futuro, si se soporta margen cruzado, los riesgos de baja liquidez en un mercado pueden propagarse a otros. Hasta que exista una solución madura, los Builders no deberían implementarlo.

Sistema de monitoreo de riesgos en múltiples dimensiones: una estructura de alertas completa

Dado que los riesgos están en todas partes, el Builder debe establecer un sistema de monitoreo en tiempo real, multidimensional y en múltiples niveles.

Monitoreo del lado de precios

Alerta nivel 1 (anomalías en feed):

• Indicador: intervalo entre llamadas a setOracle > 5 segundos
• Acción: verificar salud del relayer, cambiar a respaldo si es necesario
• Salida: alerta con info de todos los relayers

Alerta nivel 2 (despegue de precio):

• Indicador: desviación entre oraclePx y CEX perp > 2% y persistente > 5 segundos
• Acción: reducir OI mediante setOpenInterestCaps
• Luego: disminuir gradualmente el apalancamiento máximo en la tabla de márgenes

Alerta nivel 3 (desviación prolongada):

• Indicador: despegue persistente > 30 segundos
• Acción: activar mecanismos de clamp para limitar la volatilidad
• Finalmente: decidir si detener el mercado con haltTrading

Monitoreo del lado del libro

Señales de profundidad falsa:

• Indicador: profundidad real en rango de ±2% del precio, impact_ratio (volumen comer / volumen total) alto
• Alarma: caída rápida de profundidad, aumento del spread, impacto en comer órdenes
• Acción: reducir OI, prohibir nuevas posiciones

Detección de órdenes falsas:

• Señal: aumento rápido y desaparición súbita de la profundidad en corto tiempo
• Acción: reducir OI a nivel actual, detener nuevas entradas si hay fuerte despegue

Monitoreo del lado de las posiciones

El objetivo no es “predecir precios”, sino detectar si el mercado ha pasado de ser impulsado por trading a ser dominado por posiciones.

Señal de sobreapalancamiento:

• Cálculo: OI nominal / volumen en 24h
• Detección: aumento rápido indica posible inminente volatilidad
• Acción: emitir alerta, reducir apalancamiento

Señal de dominancia de la mayoría:

• Indicador: precio de apertura medio, tamaño de posición, PnL actual de la mayoría
• Alerta: si la mayoría está en ganancias o pérdidas extremas (ej. +20%), cualquier impacto externo puede causar cascada de liquidaciones
• Acción: reducir apalancamiento con anticipación

Validación de riesgos: hacer que los oráculos sean auditables y reproducibles

No basta con monitorear, el Builder debe hacer que el proceso de alimentación de precios sea “verificable”.

Construir un sistema de prueba de precios:

1. Divulgar algoritmos y fuentes

   • Publicar lógica completa de setOracle y parámetros
   • Listar todas las fuentes y pesos
   • Frecuencia y límites de volatilidad

2. Generar pruebas verificables fuera de cadena

   • Crear proof para cada setOracle:
     • Inputs: respuestas y timestamps de las fuentes
     • Cálculos intermedios
     • Outputs: precio final en la cadena
   • Firmar y serializar el proof, generar proofHash

3. Publicar MerkleRoot periódicamente

   • Agrupar proofHash en Merkle tree
   • Publicar MerkleRoot en la cadena cada hora o día
   • Permitir a cualquier usuario verificar la autenticidad de cada feed

4. Proveer herramientas de verificación open source

   • Entrada: timestamp o tx hash
   • Verificación de firma, timestamps, MerkleRoot
   • Recalcular y comparar el precio con datos en cadena

Este sistema permite que, incluso si el relayer es comprometido, los usuarios puedan verificar en cadena la validez de los precios y aportar evidencia en caso de anomalías.

Aislamiento de riesgos: estrategias personalizadas por activo

Los riesgos varían mucho según el tipo de activo, por lo que los umbrales y monitoreos deben ajustarse.

Activos 7×24H (BTC, ETH):

• Ventajas: precios externos continuos
• Monitoreo clave: estabilidad del relayer, desviaciones con CEX
• Umbrales: más laxos (despegue >3%)

Activos no 7×24H (acciones):

• Desventajas: sin precios externos durante cierre
• Monitoreo clave: saltos en apertura, volatilidad falsa en cierre
• Umbrales: más estrictos (despegue >1%)
• Fuente: cotizaciones post-cierre o CFD
• Medidas especiales: reducir apalancamiento en horarios críticos

Liquidaciones y ADL: entender la cadena de riesgos extremos

La liquidación en sí no es un riesgo, sino la reacción en cadena que puede generar.

HIP-3 sigue la lógica de liquidación de HyperCore: cuando el valor neto de la posición no cubre el margen de mantenimiento, se activa la liquidación. La liquidación se realiza preferentemente con órdenes de mercado en el libro, pero si la profundidad es insuficiente, el precio de liquidación puede desviarse significativamente del mark price, creando un “gap de liquidación”.

Este gap activa el mecanismo de ADL (desapalancamiento automático):

• Selecciona posiciones ganadoras contrarias
• Reduce posiciones a precio de mark anterior
• Usa las ganancias de los contrapartes para cubrir el gap

Pero la activación de ADL indica que el mercado está en estado extremo. Cuando se activa, los beneficios de los ganadores se reducen, lo que puede minar la confianza y generar más riesgos.

¿Cómo detectar que ADL se acerca?

• Monitorear concentración de posiciones, tamaño de OI, profundidad del libro
• Indicador: ratio OI / profundidad rápida en aumento
• Prevención: reducir apalancamiento, limitar nuevas posiciones

Responsabilidad y auditoría futura: estandarización, verificación y supervisión

El núcleo de HIP-3 es: descentralizar el poder, pero formalizar la responsabilidad en el protocolo.

Los verificadores pueden votar para penalizar a Builders que operen mal, con penalizaciones proporcionales a la gravedad:

• Estado inválido o caída prolongada: hasta 100%
• Caídas cortas: hasta 50%
• Degradación del rendimiento: hasta 20%

Los tokens apostados se queman, no se reembolsan a usuarios afectados. ¿Qué implica esto? La reputación y los tokens del Builder se ven afectados, creando un fuerte incentivo para operar responsablemente.

Pero para que la penalización sea efectiva, se requiere:

1. Riesgos observables: monitoreo completo y en tiempo real
2. Responsabilidad trazable: pruebas verificables de precios
3. Decisiones ejecutables: mecanismo de votación transparente y eficiente

Resumen: de “puedo desplegar” a “puedo operar estable”

HIP-3 reemplaza la aprobación centralizada por interfaces abiertas, y los más de 130,000 millones de dólares en volumen de mercado de terceros demuestran la viabilidad. Pero la contrapartida es que: el control de riesgos que antes asumía la plataforma ahora recae en la calidad de entrada y operación del Builder.

Desde la perspectiva del Builder, no basta con “desplegar el mercado”, sino que es crucial “identificar riesgos” y “responder a tiempo”. Para ello, se requiere:

1. Comprender las fuentes de riesgo: desde arquitectura, precios, parámetros, liquidez
2. Establecer sistemas de monitoreo: alertas en tiempo real en precio, libro y posición
3. Implementar mecanismos de verificación: transparencia y capacidad de reproducir precios
4. Preparar planes de contingencia: cuándo reducir apalancamiento, limitar OI o detener el mercado

La seguridad a largo plazo depende de si el Builder puede implementar soluciones confiables de oráculos, ajustar parámetros racionalmente y mantener un monitoreo efectivo del mercado.

HIP-3 no busca facilitar más despliegues sin control, sino estandarizar el proceso — que pueda desplegarse, operar y ser responsable. Y que este sistema funcione de manera estable, en última instancia, depende de la comprensión profunda y la ejecución efectiva del riesgo por parte del Builder.