A medida que el volumen de operaciones con derivados on-chain se expande, los Perp DEX están pasando del modelo AMM inicial hacia un modelo de libro de órdenes. Cada vez más traders quieren mantener el control de sus activos on-chain mientras disfrutan de una velocidad de emparejamiento, profundidad y experiencia de trading equiparables a las de los exchanges centralizados.
Hyperliquid ha ganado tracción precisamente en este contexto. A diferencia de los protocolos perpetuos tradicionales basados en AMM, utiliza una arquitectura nativa de capa 1 y un libro de órdenes on-chain, lo que permite que el emparejamiento, la gestión de posiciones y el control de riesgos operen dentro de un sistema unificado.
En Hyperliquid, una operación de futuros perpetuos implica mucho más que “colocar una orden y esperar a que se ejecute”. Internamente, el sistema pasa por varias etapas: depósito de activos, difusión de la orden, emparejamiento, actualización de la posición, cálculo del margen, liquidación de la tasa de financiación y supervisión del riesgo.
A diferencia de la mayoría de los Perp DEX, que dependen de la fijación de precios mediante AMM, Hyperliquid utiliza un libro de órdenes on-chain para gestionar las compras y ventas. Su lógica se asemeja mucho al motor de emparejamiento de un exchange tradicional. Tras enviar una orden, el sistema la empareja según prioridad de precio y tiempo, y actualiza la cuenta en tiempo real.
Un ciclo de trading completo incluye depositar activos, enviar una orden, emparejarla, abrir una posición, gestionar el margen, liquidar las tasas de financiación y, finalmente, cerrar la posición. Varios módulos trabajan juntos para formar el framework de trading perpetuo on-chain de Hyperliquid.

Antes de operar, los usuarios deben puentear o depositar activos en la red de Hyperliquid. Como Hyperliquid se ejecuta en su propia capa 1 nativa, los activos no permanecen en la red principal de Ethereum, sino que se trasladan al entorno de ejecución de Hyperliquid.
Una vez dentro, los activos se registran en el estado de la cuenta on-chain y sirven como margen para operaciones futuras. A diferencia de los exchanges centralizados, los usuarios no tienen que entregar sus activos a un custodio tradicional; en su lugar, controlan los fondos directamente a través de su cuenta on-chain.
El sistema rastrea dinámicamente el margen disponible, el margen ocupado y el PnL no realizado. Cuando el usuario selecciona un nivel de apalancamiento, el perfil de riesgo de la cuenta cambia en consecuencia. Un apalancamiento más alto implica un colchón de seguridad más pequeño para mantener la posición, lo que hace más probable una liquidación.
Esta etapa define el rango de riesgo que el usuario puede asumir y es una parte fundamental del sistema de futuros perpetuos.
Una característica clave de Hyperliquid es el uso de un libro de órdenes on-chain en lugar de un pool de AMM para la fijación de precios. Cuando un usuario envía una orden, el sistema la difunde al motor de emparejamiento on-chain, que la empareja según prioridad de precio y tiempo.
Este proceso es similar al de un exchange tradicional. Las órdenes de compra se emparejan con la oferta de venta más baja, y las de venta con la oferta de compra más alta. Si una orden no se puede ejecutar de inmediato, permanece en el libro de órdenes esperando una contraparte.
Los usuarios pueden colocar órdenes de mercado o límite. Las de mercado se ejecutan al instante al mejor precio disponible, mientras que las límite solo se ejecutan cuando se alcanza el precio especificado. Que una orden se ejecute de inmediato también afecta la estructura de comisiones y el rol de maker o taker.
| Rol | Definición | Impacto en la liquidez |
|---|---|---|
| maker | Aporta liquidez colocando órdenes | Aumenta la profundidad del mercado |
| taker | Toma órdenes de forma agresiva | Consume liquidez del mercado |
Esta estructura explica por qué Hyperliquid se compara a menudo con los Perp DEX basados en AMM. El modelo de libro de órdenes prioriza la profundidad real de compraventa y el descubrimiento eficiente de precios, mientras que el modelo AMM depende de la fijación de precios del pool de liquidez.
Una vez que se ejecuta una orden, el sistema crea la posición y sigue continuamente los movimientos del precio de mercado. El patrimonio de la cuenta cambia en tiempo real con el mercado, actualizando datos como el precio de entrada, el precio de marca actual, el PnL no realizado y el ratio de margen.
El ratio de margen se expresa así:
$\text{Ratio de Margen}=\frac{\text{Patrimonio de la Cuenta}}{\text{Valor de la Posición}}$
Cuando el mercado se mueve a favor, el patrimonio de la cuenta aumenta; cuando va en contra, disminuye. Para reducir el riesgo de manipulación, la mayoría de las plataformas perpetuas no usan el último precio de negociación para evaluar el riesgo, sino un mecanismo de precio de marca. Hyperliquid también calcula el riesgo combinando datos de mercado externos con su libro de órdenes interno.
Esta actualización dinámica garantiza que el trading perpetuo esté siempre bajo una evaluación de riesgos en tiempo real.
Como los futuros perpetuos no tienen fecha de vencimiento, el sistema usa una tasa de financiación para mantener el precio del contrato cerca del mercado spot.
La tasa de financiación es un pago periódico entre traders largos y cortos. Cuando el precio perpetuo supera el precio spot, los largos suelen pagar a los cortos; cuando está por debajo, los cortos pagan a los largos.
La fórmula del pago de financiación es:
$\text{Pago de Financiación}=\text{Tamaño de la Posición}\times\text{Tasa de Financiación}$
Este mecanismo fomenta que el mercado se autoequilibre entre largos y cortos, reduciendo las desviaciones de precio a largo plazo respecto al spot. La tasa de financiación no es una comisión de la plataforma, sino un intercambio dinámico entre traders, y es un diferenciador clave frente a los futuros tradicionales.
El motor de riesgos supervisa constantemente los niveles de margen de todas las cuentas. Cuando el patrimonio de una cuenta cae por debajo del requisito de margen de mantenimiento, el sistema puede activar la liquidación.
La condición central es:
$\text{Patrimonio de la Cuenta}<\text{Margen de Mantenimiento}$
Una vez superado este umbral, el sistema reduce o cierra automáticamente parte de la posición, utilizando la liquidez del mercado para completar el cierre. El objetivo es evitar saldos negativos y mantener la estabilidad general del mercado.
Como Hyperliquid utiliza un libro de órdenes de alto rendimiento, su proceso de liquidación se asemeja más al de un exchange tradicional que al de algunos protocolos basados en AMM. Sin embargo, en condiciones extremas de mercado pueden producirse deslizamientos, reducción de liquidez y liquidaciones en cascada, por lo que el trading con alto apalancamiento siempre conlleva un riesgo considerable.
La mayoría de los protocolos perpetuos on-chain se construyen sobre cadenas de contratos inteligentes de propósito general. Hyperliquid, en cambio, optó por desarrollar su propia capa 1 nativa. Este diseño unifica el emparejamiento, las actualizaciones de estado, el cálculo de riesgos y la lógica de liquidación en un único entorno de ejecución.
Como resultado, Hyperliquid ofrece menor latencia, actualizaciones de estado de mayor frecuencia y una profundidad de libro de órdenes más estable.
| Capacidad | Impacto en la experiencia de trading |
|---|---|
| Menor latencia | Respuesta de órdenes más rápida |
| Actualizaciones de estado de alta frecuencia | Menor desincronización de precios |
| Libro de órdenes on-chain | Mejor profundidad y descubrimiento de precios |
| Motor de riesgos nativo | Liquidación y gestión de márgenes optimizadas |
Esta arquitectura explica por qué Hyperliquid se describe a menudo como una “experiencia de trading on-chain similar a un CEX”.
Aunque la experiencia de trading de Hyperliquid se asemeja a la de un exchange centralizado, su estructura subyacente es claramente diferente.
| Dimensión | Hyperliquid | CEX tradicional |
|---|---|---|
| Custodia de activos | Control de cuenta on-chain | Custodia centralizada de la plataforma |
| Transparencia del emparejamiento | Verificable on-chain | Invisible en el sistema interno |
| Mecanismo de liquidación | Ejecución de reglas on-chain | Control interno de la plataforma |
| Libro de órdenes | Libro de órdenes on-chain | Libro de órdenes centralizado |
| Riesgo | Contrato inteligente y riesgo on-chain | Riesgo de custodia y plataforma |
Esta diferencia explica por qué cada vez más traders exploran la tendencia de la "CEXificación on-chain". Hyperliquid busca lograr un nuevo equilibrio entre la autocustodia y el trading de alto rendimiento.
El modelo operativo de Hyperliquid se basa en un libro de órdenes on-chain, una capa 1 nativa y la gestión de riesgos de futuros perpetuos. Una operación completa no es solo una compra o venta simple: implica sistemas coordinados que incluyen emparejamiento, gestión de márgenes, tasas de financiación, supervisión de riesgos y liquidación.
En comparación con los Perp DEX iniciales, Hyperliquid prioriza el emparejamiento de alto rendimiento y una experiencia de trading cercana a los exchanges centralizados, manteniendo al mismo tiempo la transparencia on-chain y la autocustodia. Este modelo está impulsando el mercado de derivados on-chain desde una estructura AMM hacia una arquitectura de libro de órdenes de alto rendimiento.
No. Hyperliquid usa principalmente un libro de órdenes on-chain para el emparejamiento, no la fijación de precios mediante pools de liquidez AMM.
Porque su capa 1 nativa y su motor de emparejamiento de alto rendimiento proporcionan menor latencia, actualizaciones de estado más frecuentes y una profundidad de libro de órdenes más estable.
La tasa de financiación equilibra las posiciones largas y cortas y ayuda a mantener el precio perpetuo cerca del mercado spot.
Cuando el patrimonio de la cuenta cae por debajo del requisito de margen de mantenimiento, el sistema reduce o cierra automáticamente las posiciones para controlar el riesgo y evitar saldos negativos.
La mayor diferencia es su libro de órdenes on-chain y su arquitectura de capa 1 nativa, mientras que la mayoría de los Perp DEX tradicionales dependen del modelo AMM y cadenas de bloques de propósito general.





