Definición de Oráculo y Estabilidad del Mercado: Construyendo Mercados Perpetuos Confiables en HIP-3

La evolución de cómo se lanzan los contratos perpetuos ha cambiado fundamentalmente. Donde las plataformas solían controlar qué activos podían comerciarse y bajo qué términos, HIP-3 ha redistribuido ese poder a constructores calificados que operan dentro de parámetros definidos. Desde su despliegue en la mainnet, más de 13 mil millones de dólares en volumen de transacciones han fluido a través de mercados operados por terceros, señalando una democratización genuina de la creación de mercados. Sin embargo, este cambio de guardián a sistema basado en reglas crea una paradoja crítica: una mayor flexibilidad del mercado exige una disciplina operacional más rigurosa. En el centro de este desafío se encuentra un concepto engañosamente simple con consecuencias desproporcionadas: la definición de oracle.

La arquitectura detrás del listado descentralizado: del Aprobado a los Estándares

Los intercambios centralizados tradicionales controlan el listado de contratos perpetuos mediante procesos internos opacos. Un equipo de producto evalúa un activo, toma una decisión comercial y lo despliega. El control de riesgo reside en la infraestructura del intercambio. HIP-3 invierte este modelo. En lugar de mantener un catálogo curado, Hyperliquid proporciona la infraestructura—HyperCore gestiona el emparejamiento y liquidación a escala, HyperEVM ejecuta contratos inteligentes—y invita a los constructores a superponer mercados sobre ella.

El mecanismo es sencillo en apariencia: apostar 500k tokens HYPE, desplegar un DEX (que mantiene su propio margen y libro de órdenes), lanzar tres mercados gratis, y luego adquirir slots adicionales mediante subastas holandesas. Pero esta simplicidad estructural oculta una complejidad profunda en la ejecución. El constructor ahora posee no solo la creación del mercado sino también las operaciones del mercado—alimentación de precios, gestión de parámetros, monitoreo de estabilidad continua. Lo que antes era responsabilidad de la plataforma se convierte en una superficie de responsabilidad del constructor.

Este cambio expone una tensión central: la descentralización requiere estandarización. El sistema debe establecer interfaces y restricciones claras; de lo contrario, el riesgo no desaparece—se fragmenta entre decenas de operadores independientes con capacidades variables.

Definición de Oracle: La Decisión Crítica Inicial

Cuando un constructor inicia la creación de un mercado, la primera y más importante decisión involucra la definición del oracle. Esto no es simplemente seleccionar una fuente de precios; abarca todo el marco conceptual para cómo los participantes del mercado determinarán si sus posiciones son rentables, enfrentan liquidaciones o activan mecanismos de emergencia.

Lo que realmente especifica la definición de oracle:

Una definición de oracle en HIP-3 incluye tres componentes: el oraclePx (el precio bruto de una fuente externa), el markPx opcional (precios de marca personalizados que suministra el constructor), y el externalPerpPx (mediana ponderada de los precios perpetuos de un exchange centralizado). Estos no son insumos intercambiables—cumplen funciones distintas en la jerarquía de cálculo de riesgo de HIP-3.

El oraclePx ancla las tarifas de financiamiento y sirve como referencia para los límites de precios. El markPx es calculado por el relayer del constructor combinando señales en cadena y fuera de cadena. El externalPerpPx proporciona una referencia de respaldo. HIP-3 combina estos en un precio de marca real mediante cálculo de mediana: primero la mediana del libro de órdenes local, luego combinada con las marcas externas suministradas por el constructor, y comparada con externalPerpPx. Este enfoque de múltiples fuentes teóricamente evita que una sola fuente de precios dicte liquidaciones.

Teóricamente.

Por qué la definición de oracle importa más que la tecnología:

La composición técnica de la definición de oracle es menos crítica que la capacidad operacional del constructor para mantenerla. Un constructor que elige una definición de oracle que depende de un relayer centralizado hereda la disponibilidad, seguridad y frecuencia de actualización de ese servidor como restricciones. Si la clave privada que asegura el relayer se ve comprometida, o si ataques DDoS impiden actualizaciones de precios, el oraclePx se estanca. Sin actualizaciones en los precios de marca, el sistema vuelve a los medianos del libro de órdenes local—justo cuando la liquidez es más escasa y el riesgo de manipulación alcanza su pico.

El incidente del 14 de diciembre de 2025 en trade.xyz demostró esta dinámica. Los atacantes acumularon una posición corta de aproximadamente 398 contratos XYZ100 (~10 millones de dólares), creando deliberadamente un desequilibrio. El precio se desacopló de las fuentes externas por falta de profundidad en el libro de órdenes. Los poseedores de posiciones largas enfrentaron liquidaciones en cascada, cerrando aproximadamente 13 millones de dólares en posiciones. El mecanismo funcionó técnicamente—las liquidaciones se ejecutaron—pero el sistema transfirió pérdidas a los participantes menos preparados en lugar de prevenir la dislocación inicial.

Este escenario se vuelve mucho más probable cuando la definición de oracle asume anclas de precios externas estables durante horas fuera del mercado.

La división entre activos 24/7 y no 24/7: dónde la definición de oracle se vuelve crítica

La flexibilidad de HIP-3 para listar cualquier activo crea una diferencia categórica en los requisitos de definición de oracle.

Activos 24/7 (Criptomonedas perpetuas):

Para Bitcoin, Ethereum y otros activos comerciables las 24 horas, la definición de oracle puede apoyarse en múltiples fuentes de precios CEX/DEX combinadas con servicios especializados como Pyth. Estos activos se negocian continuamente en múltiples venues. Un constructor puede agregar varias fuentes de precios, aplicar cálculos de mediana y detectar valores atípicos. Cuando una fuente se desvíe, otras proporcionan un anclaje inmediato.

La definición de oracle para activos 24/7 sigue siendo desafiante—seleccionar fuentes ponderadas, gestionar la frecuencia de actualización, manejar caídas en exchanges—pero el mercado externo subyacente proporciona señales consistentes incluso si alguna fuente falla.

Activos no 24/7 (Acciones y commodities):

La definición de oracle para perpetuos de acciones requiere supuestos fundamentalmente diferentes. Durante horas de mercado, las fuentes de precios como Pyth ofrecen anclajes externos estables. Pero cuando la Bolsa de Nueva York cierra, el constructor enfrenta una decisión: detener las fuentes de precios (y restringir el comercio), o seguir cotizando basándose en señales internas con referencias externas solo en el “precio de cierre anterior”.

La mayoría de los constructores que implementan activos no 24/7 usan actualmente un mecanismo interno similar a trade.xyz—combinando el último precio externo con la dinámica del libro de órdenes interno, limitado para evitar desviaciones excesivas (normalmente 1/max_leverage). Esto es matemáticamente correcto; operacionalmente, peligroso.

Durante cierres de mercado, la profundidad del libro suele reducirse. Los creadores de mercado reducen cotizaciones, los participantes minoristas duermen, y el mercado se vuelve mucho más delgado. Una definición de oracle que limite el movimiento de precios a “1/10 del cierre anterior” (para apalancamiento 10x) suena conservadora. Pero cuando la liquidez desaparece, incluso un flujo modesto de órdenes genera movimientos de precios desproporcionados dentro de ese rango acotado. Cuando el mercado abre el lunes por la mañana y los datos externos vuelven a anclar, surgen brechas. Estas brechas activan liquidaciones en cascada o, en casos severos, eventos de reducción automática de posiciones (ADL) donde se cierran forzosamente operaciones rentables para cubrir pérdidas de posiciones insolventes.

Construir un marco defensible para la definición de oracle

Los constructores que intentan operar mercados estables necesitan estrategias de definición de oracle que anticipen modos de fallo en lugar de asumir estabilidad continua.

Anclajes de precios suplementarios durante cierres de mercado:

Para activos no 24/7, introducir señales de precios externas incluso durante cierres mejora sustancialmente la definición de oracle. Opciones incluyen:

• Blue Ocean ATS y venues de trading after-hours: Proporcionan descubrimiento de precios continuo fuera del horario regular, ofreciendo señales más actuales que el “precio de cierre anterior”. Un constructor puede ponderar datos de Blue Ocean ATS en la definición de oracle durante cierres, creando un punto de referencia menos manipulable.

• Cotizaciones CFD de fin de semana de proveedores como IG: Estas pronostican expectativas del mercado para la apertura de la próxima semana. Aunque no sustituyen directamente los precios spot, sirven como anclajes direccionales para “brechas de apertura esperadas” en la definición de oracle.

Estas fuentes comparten una característica clave: están disponibles durante cierres de mercado pero difieren estructuralmente de los mercados spot. La definición de oracle debe tratarlas como referencias y señales de riesgo, no como equivalentes incondicionales.

Diseñar derivaciones de precios transparentes y auditable:

La vulnerabilidad principal en la implementación actual de la definición de oracle es la centralización del relayer. Si las fuentes de precios provienen exclusivamente de un servidor privado del constructor, ese servidor se vuelve un punto único de fallo y ataque. Los constructores deberían construir sistemas de verificación de definición de oracle que permitan auditorías externas de la autenticidad de los precios.

Esto requiere divulgar públicamente: las fuentes de datos que alimentan el oracle, el algoritmo exacto que combina esas fuentes, las marcas de tiempo de muestreo para cada entrada, y los precios de marca resultantes. Para cada llamada setOracle, generar una prueba criptográfica que incluya los datos en bruto, los pasos de cálculo y los resultados finales. Serializar esto en un proofHash, que el relayer firma. Periódicamente, agregar estos hashes en árboles Merkle y publicar la raíz en la cadena.

Este enfoque transforma la definición de oracle de “confía en el servidor de precios del constructor” a “verifica la metodología del constructor”. Cualquier usuario puede recuperar datos históricos de precios, recomputar salidas usando los algoritmos publicados y confirmar si las fuentes del constructor coincidieron con las declaradas.

Cuando la definición de oracle falla: monitoreo e intervención

Incluso las definiciones de oracle bien diseñadas fallan bajo estrés extremo del mercado. Los constructores que operan en HIP-3 necesitan marcos de monitoreo que detecten la degradación antes de que se propague.

Monitoreo del lado del precio: detección de deriva del oracle:

Las fallas en la fuente de precios del oracle aparecen primero como discontinuidades—el relayer deja de actualizar. Los constructores deben monitorear observables en cadena: si dos actualizaciones consecutivas del oracle superan los 10 segundos, se activa una alerta de Nivel 1. El constructor revisa su infraestructura del relayer, potencialmente cambiando a nodos de respaldo.

Más insidioso es el desanclaje del precio: el precio del oracle se desvía gradualmente de los puntos de referencia externos. La definición del oracle del constructor puede depender de Pyth para perpetuos de acciones, pero los datos de entrada (que usan precios agregados de exchanges) divergen de las condiciones actuales del mercado. La definición del oracle se vuelve obsoleta sin parecerlo. Los umbrales de monitoreo deben comparar múltiples fuentes externas contra el oracle del constructor: si dos o más divergen en >X%, se escalan alertas.

En una alerta de Nivel 1, limitar el interés abierto usando setOpenInterestCaps. En Nivel 2 (desviación sostenida), ajustar los márgenes para reducir gradualmente el apalancamiento máximo por nivel. En Nivel 3, activar paradas de emergencia mediante haltTrading.

Monitoreo del libro de órdenes: detectar colapso de liquidez:

La definición de oracle solo es útil en la medida en que la estructura de liquidez del mercado lo permita. Si el libro se estrecha, los spreads se ensanchan y el impacto de órdenes agresivas aumenta, incluso precios precisos se vuelven peligrosos. Los constructores deben rastrear depth_band (volumen acumulado dentro de ±x% del precio medio), spread (diferencia entre mejor ask y mejor bid) y impact_ratio (volumen agresivo / depth_band). Cuando la profundidad se reduce mientras los spreads y los impact ratios aumentan simultáneamente, el riesgo de liquidación se dispara.

En un nivel 1, limitar el crecimiento del interés abierto. En nivel 2, reducir forzosamente el apalancamiento en posiciones de alto riesgo.

Monitoreo de concentración de posiciones: detectar cascadas de especulación:

Finalmente, monitorear si el mercado pasa de un coberturismo genuino a pura especulación. Rastrear la proporción del interés abierto en valor nominal respecto al volumen de comercio de 24 horas. Cuando el OI crece mucho más rápido que el volumen, el mercado se inclina hacia una exposición unilateral acumulada. Combinado con ganancias/pérdidas extremas en la mayoría de las posiciones, esto precede cascadas de liquidaciones. Los constructores deben alertar cuando estos ratios superen umbrales; si persisten, reducir los límites de OI.

Gobernanza mediante staking: responsabilidad en decisiones de definición de oracle

El mecanismo de HIP-3 para responsabilizar a los constructores se centra en el staking. Los constructores deben mantener 500k HYPE en staking en todo momento. Los validadores pueden votar para reducir este stake si las acciones del constructor generan estados de mercado inválidos, largos periodos de inactividad o degradación del rendimiento.

Este mecanismo de staking hace que las decisiones sobre la definición de oracle tengan consecuencias financieras concretas. Un constructor que implemente una definición negligente—aceptando una sola fuente centralizada, sin monitorear la deriva, o ignorando riesgos de precios fuera de horario—puede generar cascadas de liquidación. Los validadores que detecten fallos repetidos o un colapso del mercado directamente atribuible a una definición de oracle inadecuada pueden votar para reducir todo el stake del constructor.

Esto transforma la definición de oracle de una decisión técnica a una decisión de gobernanza. Los validadores ratifican o penalizan implícitamente las elecciones del constructor mediante votos de slashing. Con el tiempo, esto crea una presión evolutiva: los constructores que implementen definiciones robustas sobreviven; los que corten esquinas acumulan votos de slashing.

El mecanismo no es perfecto—los validadores pueden carecer de la sofisticación técnica para evaluar con justicia las decisiones de oracle, o votar por motivos ajenos a la calidad operacional—pero establece un umbral mínimo de responsabilidad.

La implicación más amplia: descentralización como redistribución del riesgo

La innovación central de HIP-3 no es eliminar el riesgo; es redistribuirlo. Donde los exchanges centralizados internalizan el riesgo operacional (mantener fuentes de precios, prevenir manipulaciones, gestionar liquidaciones), HIP-3 externaliza esas responsabilidades a los constructores. El protocolo proporciona infraestructura; los constructores aportan excelencia operacional.

Esto solo funciona cuando los constructores entienden realmente en qué han asumido responsabilidad. La definición de oracle representa una de las superficies de ataque más subestimadas. Parece simple—elegir una fuente de precios—pero abarca la selección de feeds, gestión del relayer, precios fuera de horario, mecanismos de respaldo, marcos de verificación, monitoreo continuo y responsabilidad de gobernanza.

Los mercados construidos con definiciones de oracle descuidadas fallarán. Los que tengan definiciones pensadas, monitoreo adecuado y mecanismos de verificación transparentes podrán sostener actividades comerciales sustanciales. Los 13 mil millones de dólares en volumen de comercio a través de mercados HIP-3 indican que existen constructores adecuados. Pero cada mercado fallido—cada cascada de liquidaciones atribuible a fallos en la definición de oracle—transfiere capital de traders desprevenidos a operadores de plataformas y a arbitradores sofisticados.

Los constructores que ingresen a HIP-3 deben abordar la definición de oracle no como un detalle técnico, sino como la decisión arquitectónica fundamental que determinará si su mercado operará con integridad o fallará bajo estrés.

Navegando el camino a seguir

Para los constructores que diseñan acceso al mercado, plantillas de parámetros, sistemas de alerta y procedimientos de emergencia basados en HIP-3, el éxito depende de tratar la definición de oracle como un problema de diseño desde los primeros principios. Esto implica modelar explícitamente cómo se comporta su definición de oracle en escenarios: caídas de exchange, ataques DDoS a su relayer, brechas entre precios internos y externos en horas fuera de mercado, y cascadas de liquidación en condiciones de baja liquidez.

Implica implementar marcos de verificación que permitan auditorías externas de su metodología de precios. Implica establecer umbrales de monitoreo y procedimientos de escalamiento con reglas de decisión claras. Y, lo más importante, reconocer que la complejidad de mantener definiciones de oracle confiables bajo estrés no ha desaparecido—simplemente se ha desplazado del exchange a los constructores.

Quienes tomen en serio la definición de oracle operarán mercados estables y confiables. Quienes no, serán casos de estudio sobre cómo fallan los sistemas descentralizados.