Redacción: ponyo_fp (Equipo de investigación de Four Pillars)
Compilación: AididiaoJP, Foresight News
Puntos clave
HyperEVM debe verse como una capa de contratos inteligentes, cuyo valor central radica en permitir que las aplicaciones lean y utilicen directamente los datos de transacciones, garantías, posiciones y riesgos de HyperCore.
La forma más sencilla de juzgar si una aplicación HyperEVM tiene valor es hacer dos preguntas: ¿Por qué necesita EVM? ¿Por qué necesita Hyperliquid?
Funciones básicas como el intercambio, los préstamos y los envoltorios de activos son, por supuesto, necesarias, pero lo que realmente puede marcar la diferencia son aquellos productos que no pueden funcionar sin HyperCore.
A largo plazo, la forma última es una cuenta altamente integrada: el usuario solo necesita un saldo para completar simultáneamente todas las operaciones como trading, préstamos, yield farming, cobertura y pagos.
Prioridad al exchange
La mayoría de las plataformas de contratos inteligentes siguen la ruta de "primero la cadena, luego las aplicaciones": primero lanzan la infraestructura, subvencionan la liquidez, atraen desarrolladores y finalmente esperan que las aplicaciones formen naturalmente una atracción financiera.
El camino de Hyperliquid es completamente opuesto. Primero construye el exchange, posee libros de órdenes nativos para spot y perpetuos, cuota mental entre traders, un sistema de liquidez propio del protocolo y un volumen de transacciones real que ya fluye a través de HyperCore. Esto cambia por completo el posicionamiento de HyperEVM: no es otro lugar donde se puedan copiar arbitrariamente contratos DeFi, sino que busca hacer que el propio exchange sea programable.
Este artículo no es un inventario exhaustivo de todos los factores que pueden impulsar el crecimiento de Hyperliquid (HIP 3, código del constructor, margen de cartera, liquidez nativa, activos Unit, ciclo de tarifas, etc., también son importantes). Aquí nos centramos en una sola pregunta: ¿Qué características deben tener las aplicaciones que realmente merezcan existir en HyperEVM?
Una aplicación nativa valiosa de HyperEVM debe cumplir simultáneamente tres puntos:
- Poder expresar lógica general que HyperCore por sí solo no puede implementar (necesita la flexibilidad de EVM);
- Depender de un estado único que otras cadenas no poseen (capacidad de composición de HyperCore);
- Hacer que Hyperliquid como lugar financiero sea más útil.
HyperCore es donde reside el motor de transacciones, garantías y riesgo. HyperEVM es donde se escribe la lógica de la aplicación. A través de precompilaciones (precompiles), los contratos pueden consultar directamente datos de HyperCore como saldos, posiciones, precios, delegaciones de staking y participaciones en vaults; a través de CoreWriter, los contratos pueden escribir operaciones de vuelta a HyperCore.
Este diseño convierte al exchange en una fuente de entrada nativa para las aplicaciones. Las garantías, ejecución, liquidación y distribución pueden integrarse de manera más estrecha en el mismo libro mayor.
Por supuesto, no todas las aplicaciones HyperEVM deben buscar la "novedad". El ecosistema necesita primero tener primitivas familiares para que los usuarios puedan realizar naturalmente intercambios, préstamos, apalancamiento, reequilibrio y salida. Una superficie financiera local puede mantener el capital dentro del sistema y hacer que todo el ecosistema sea verdaderamente utilizable.
Pero las oportunidades más profundas no consisten en simplemente bifurcar (fork) un protocolo de préstamos existente y cambiar el frontend, sino en construir crédito, gestión de activos, pagos y finanzas estructuradas en torno al libro mayor del exchange, cosas que una cadena EVM común no puede replicar ni siquiera con incentivos.
CoreWriter tampoco convertirá a HyperEVM en una extensión sincronizada del libro de órdenes. Las operaciones entre entornos presentan problemas de restricciones de orden, escrituras con retraso y coordinación de estado; los constructores deben manejar rollbacks por fallos, ejecución retrasada, contabilidad de garantías entre entornos y gestión de riesgos. Esto, aunque reduce parte del espacio de diseño, también forma una barrera de entrada única.
Comprendiendo la matriz 2x2 de la economía HyperEVM
El mejor marco para evaluar una aplicación HyperEVM es una matriz bidimensional:
- Eje horizontal: ¿La aplicación necesita lógica EVM genérica?
- Eje vertical: ¿La aplicación se combina directamente con el estado o ejecución de HyperCore?
Las etiquetas de categoría no son importantes, lo clave es observar las dependencias que el producto no puede eliminar.
Finanzas EVM locales
Este tipo de aplicaciones necesita contratos inteligentes, pero sus modelos de producto son mayormente portables. Los AMM, mercados monetarios, CDP, enrutadores, lugares de opciones, productos apalancados y mercados de rendimiento pertenecen a este cuadrante.
Felix es un representante típico. HyperLend también comenzó aquí, como uno de los principales lugares de crédito en HyperEVM (su hoja de ruta posterior evolucionará hacia HyperCore programable).
Este cuadrante es fácil de subestimar, pero en realidad es muy importante. Cualquier centro financiero necesita bancos, brókeres, lugares de liquidez y mercados de transferencia de riesgo para poder sustentar productos de balance más complejos. La portabilidad los convierte en la capa base de la actividad del usuario.
Extensiones nativas del núcleo
Este tipo de aplicaciones dependen más directamente de Hyperliquid, pero el rol de EVM es principalmente envolver, tokenizar o combinar primitivas nativas.
Ejemplos típicos incluyen: Kinetiq, StakedHYPE, Kintsu, envoltorios HLP, activos asociados a Unit, etc. Su tarea central es hacer que los activos dentro de Hyperliquid sean más útiles.
Este cuadrante es crucial: el colateral es la materia prima de toda actividad financiera. Los mercados monetarios necesitan activos que los usuarios estén dispuestos a pedir prestados, los productos estructurados necesitan activos que se puedan pignorar o cubrir, y una cuenta unificada necesita saldos que puedan fluir libremente entre diferentes funciones.
HyperCore programable
Este es el cuadrante con mayor imaginación: la aplicación necesita tanto la lógica genérica de EVM como depende en profundidad del estado y ejecución de HyperCore. Aquí, la actividad del exchange comienza a "productizarse" realmente.
- Rysk: Convierte opciones en ingresos por volatilidad para los activos que el usuario ya posee;
- Liminal: Empaqueta estrategias de Hyperliquid como productos tokenizados;
- Hyperbeat: Estrategia delta neutral que combina posiciones en Core con la capacidad de composición ERC-20.
Derive se encuentra en una posición marginal: permite que HYPE y kHYPE sean colateral para opciones/perpetuos a través de vaults puenteados por HyperEVM, pero su lógica central de trading y liquidación permanece en su propio stack. Puede ampliar el uso de HYPE como colateral, pero no pertenece estrictamente a HyperCore programable nativo.
Actualmente, los proyectos que cumplen estrictamente con "activos custodiados por contrato + lectura del estado de HyperCore + uso de CoreWriter para ejecutar" todavía se encuentran en etapas tempranas. Valantis Prime es un caso representativo en beta pública: utiliza cuentas inteligentes HyperEVM como capa de control, opera HyperCore a través de CoreWriter y establece restricciones como permisos, proxies, claves de sesión, guardianes, etc., haciendo que la cuenta en sí sea una interfaz programable para el exchange.
HyperLend y Rysk también apuntan a la misma frontera desde diferentes ángulos, pero al final aún deben medirse con el criterio de "si realmente custodian activos y se integran profundamente con CoreWriter".
La cuenta financiera es la forma última
La aplicación HyperEVM más valiosa podría no parecerse en absoluto a una "aplicación", sino más bien a una cuenta.
Hoy, los usuarios de criptomonedas todavía tienen que cambiar entre múltiples interfaces: el saldo del exchange para trading, el saldo de la wallet para DeFi, las participaciones en vaults representan rendimientos, la capacidad de préstamo está oculta en mercados monetarios, la cobertura requiere abrir otra plataforma... Esta fragmentación no es solo un problema de experiencia, sino que refleja el hecho de que la liquidez, las garantías, la ejecución y el riesgo están dispersos en diferentes sistemas.
HyperEVM tiene la oportunidad de comprimir estos sistemas en la misma cuenta. El usuario solo necesita depositar una vez activos como BTC, ETH, SOL, HYPE, etc., y podrá partir desde el mismo saldo: operar en HyperCore, tomar préstamos en HyperEVM, obtener rendimiento a través de vaults, cubrirse con perpetuos y completar gastos directamente desde la cuenta de pagos. El producto no es un puente, el producto es ese saldo que puede fluir entre funciones.
Los exchanges centralizados entendieron esto hace tiempo: sus cuentas se sienten unificadas porque el trading, el margen, los préstamos y los rendimientos están en un entorno controlado. Pero el problema es que el libro mayor es cerrado, el motor de riesgo no es transparente y los desarrolladores externos no pueden construir libremente.
Las cadenas públicas genéricas son lo opuesto: el usuario controla realmente la cuenta, pero el stack financiero está altamente fragmentado.
Hyperliquid ocupa justo el punto óptimo: HyperCore proporciona infraestructura de liquidez y riesgo a nivel de exchange, HyperEVM proporciona una superficie de aplicación abierta. El resultado final es una cuenta financiera unificada que el usuario controla por completo, pero sustentada por HyperCore como un poderoso balance general, la realización más fuerte de la visión de "casa financiera integral".
La evidencia futura aparecerá a nivel de cuenta: el colateral sigue al usuario a través del trading, préstamos, ahorro, cobertura y gasto; el riesgo se valora en tiempo real desde el estado de HyperCore; las liquidaciones se ejecutan a través de la profundidad de HyperCore; los productos estructurados se cubren directamente con la liquidez de Core; los ERC-20 representan derechos de reclamación sobre diversas actividades financieras dentro del sistema.
La primera ola de HyperEVM hará que el ecosistema sea utilizable, la próxima ola hará que HyperCore sea verdaderamente programable.
