Hyperliquid: Las guerras del frontend

Fuente: CryptoNewsNet
Título original: Hyperliquid: Las guerras del frontend
Enlace original:
Una de las innovaciones clave de Hyperliquid son los códigos de constructor (builder codes). Estos códigos funcionan como un parámetro a nivel de protocolo en las cargas útiles de transacción, permitiendo a las interfaces añadir una dirección de constructor para la captura automática de comisiones en cadena. Los constructores pueden añadir un recargo de hasta 100 puntos básicos (1%) en spot y 10 puntos básicos (0.1%) en perps.

Esta desvinculación de la ejecución respecto a la liquidación permite a los frontends monetizar el flujo propietario sin la complejidad técnica de mantener un libro de órdenes o la ineficiencia de capital de arrancar liquidez. Como se muestra a continuación, los frontends de terceros integran perps de Hyperliquid y añaden sus propios niveles de comisiones variables, creando de forma efectiva un panorama de precios diferenciado para la misma ejecución subyacente.

Así, los códigos de constructor han desatado un potente efecto de volante de distribución. Casi el 40% de los usuarios activos diarios ahora operan a través de frontends de terceros en lugar de la interfaz nativa, una cuota que cruzó brevemente el 50% a finales de octubre. Solo los tres principales constructores, Based, Phantom y pvp.trade, han capturado colectivamente más de $31 millones en comisiones.

Desde la perspectiva de la estructura de mercado, esto aleja a Hyperliquid del modelo de exchange cripto totalmente integrado y lo acerca a la intermediación por capas de las acciones tradicionales. En un exchange centralizado como cierto exchange principal, una sola entidad controla toda la cadena: onboarding, enrutamiento, emparejamiento y custodia.

El diseño de Hyperliquid imita el mercado de acciones de EE. UU., donde los brokers minoristas (Robinhood, Schwab) poseen la relación con el cliente y monetizan la distribución, mientras enrutan órdenes a mayoristas (Citadel Securities, Virtu) que gestionan la ejecución y liquidación. En efecto, la estructura se convierte en dos niveles:

• Una capa de distribución tipo broker, donde los constructores compiten por el flujo de órdenes y se diferencian en producto y traspaso de comisiones.
• Un lugar central de ejecución, donde Hyperliquid concentra liquidez y gestiona emparejamientos y márgenes.

Aunque esto es nuevo para los perps cripto, este mecanismo de desvinculación ya se ha dado en Solana. Terminales de trading como Photon y Axiom controlaron el flujo de usuarios centrándose en la capa de consumidor. Photon creció primero por ser el sniper de memecoins de Solana más rápido, mientras que Axiom lo desafió finalmente con una gama de productos más amplia y diseños de puntos y reembolsos más agresivos. Estas terminales actuaban de facto como constructores: se situaban sobre los DEXs, añadían sus propios recargos de comisiones y mantenían la contabilidad manualmente. Los códigos de constructor de Hyperliquid convierten ese patrón en una primitiva nativa del protocolo.

Sin embargo, el ejemplo de Solana también pone de relieve el riesgo. Las terminales de trading capturaron el 77% de los ingresos de DEXs de Solana durante el último año, $633 millones frente a $188 millones para los DEXs, un múltiplo de 3,4x que resalta que poseer el frontend suele ser más valioso que poseer el backend. Específicamente, ¿es el frontend demasiado valioso para que Hyperliquid lo regale?

La relación entre frontends y backends rara vez es puramente simbiótica. Frontends como Jupiter agregan varios backends (Meteora, Raydium, Orca) y devuelven la mejor ruta dada la cantidad, comisiones y restricciones de slippage.

Esto obliga a los backends DEX a una severa compresión de márgenes. Sin foso competitivo, deben ser la ruta más barata para captar flujo. Al no poseer al usuario, los backends también corren el riesgo de ser reemplazados. Lo vemos cuando pump.fun sustituyó a Raydium como su backend de liquidez por su propio AMM interno, lo que afectó significativamente la cuota de volumen de Raydium.

Actualmente, Hyperliquid no enfrenta este problema. Al ser pionero en los códigos de constructor en perps, es efectivamente un entorno de código de constructor único. Sin embargo, si los constructores evolucionan de una simple UI sobre HL a verdaderos routers capaces de enviar flujo a backends competidores, empiezan a parecerse a un smart-order router en finanzas tradicionales. En este escenario, los constructores pueden:

• Optimizar el coste total: Calcular spread/slippage + comisiones taker/maker + recargo constructor − reembolsos + funding esperado.
• Negociar con los venues: Exigir mayor parte de comisiones o reembolsos con la amenaza de enrutar el flujo a otra parte.
• Capturar la relación con el usuario: Mientras los venues se ven obligados a competir únicamente por ser el proveedor de liquidez mayorista más barato y de mejor ejecución.

De forma similar, en finanzas tradicionales, los mayoristas compiten con los broker-dealers por el volumen. Robinhood enruta a Citadel Securities, Virtu y Jane Street en función de quién ofrece la mejor ejecución y pago por el flujo de órdenes.

Mientras que DEXs rivales como Drift y Ostium han integrado códigos de constructor, ninguno ha surgido como competidor genuino hasta la fecha. Sin embargo, persiste un riesgo estructural importante: Si un venue como Lighter combinara reembolsos de constructor con su modelo de cero comisiones, teóricamente podría permitir a wallets como Phantom y Rabby eludir la comisión de 4,5 bps de Hyperliquid. Esto permitiría a los frontends capturar toda la pila de comisiones, duplicando de facto sus ingresos por operación respecto al modelo actual de Hyperliquid.

Un indicador adelantado de este futuro es LiquidTrading. El terminal respaldado por Paradigm, que recaudó 7,6 millones de dólares en su ronda seed, ha facilitado 5.600 millones de dólares de volumen en Hyperliquid. Pero, crucialmente, también permite a los usuarios operar en Ostium y Lighter desde la misma interfaz. Si los grandes constructores siguen este camino y empiezan a enrutar activamente el flujo según los reembolsos de los venues en vez de por lealtad, los frontends de constructor de Hyperliquid podrían evolucionar hacia un agregador de perps comoditizado, amenazando directamente la capacidad del protocolo de capturar valor.

Aun así, existe una diferencia fundamental. Spot es fácil de agregar porque cada swap es atómico y el activo es fungible entre venues. Una transacción equivale a un fill, y un router puede dividir una operación entre varios pools sin problemas. Sin embargo, en perps, las posiciones son persistentes y específicas del venue. Una posición BTC-PERP en el Venue A no es fungible con una posición BTC-PERP en el Venue B debido a diferencias en la composición del índice, tasas de funding, motores de liquidación y límites de riesgo.

Para enrutar perps entre venues de forma significativa, el mercado necesita una de dos soluciones difíciles:

• Fragmentación de usuario: Los usuarios deben mantener colateral en varios venues, lo que es ineficiente en capital y produce una mala experiencia de usuario.
• Capas de prime brokerage: El router debe actuar como una capa de clearing, resolviendo los complejos problemas de extensión de crédito, margen cruzado y coordinación de liquidaciones.

Aunque la no fungibilidad ofrece una defensa a corto plazo, la dura realidad es que los frontends son actores económicos racionales; migrarán si un competidor ofrece mejores márgenes. Sin embargo, los datos sugieren que esta amenaza está contenida actualmente. A pesar del alto número de usuarios en interfaces de terceros, la gran mayoría del volumen, más del 90%, todavía se origina en el frontend nativo de Hyperliquid.

Además, el token HYPE añade una capa de retención. Los constructores pueden mantener HYPE para acceder a descuentos en comisiones, permitiéndoles apilar flujos de ingresos: referidos, comisiones de constructor y descuentos por volumen. Así, el coste de cambiar por comisiones ligeramente mejores puede no compensar a los frontends existentes. Finalmente, el flujo proveniente de los constructores parece ser aditivo más que canibalizador. Son nuevos usuarios que entran al ecosistema a través de wallets y terminales, no usuarios que cambian de interfaz.

Por tanto, aunque los códigos de constructor ofrecen un vector de expansión eficaz, esperar que Hyperliquid mantenga el dominio total sobre su capa de distribución no es realista. A medida que el sector madure, Hyperliquid tendrá que esforzarse más para defender su liderazgo frente a agregadores y competidores de bajas comisiones. Sin embargo, construir un libro de órdenes onchain de alto rendimiento sigue siendo un foso técnico inmenso, y mientras los márgenes de frontend sigan siendo saludables, los incentivos para que los constructores cambien son bajos. Aun así, en un mercado en rápida expansión, esta no es una batalla por retener volumen, sino una carrera más competitiva por el crecimiento donde Hyperliquid sigue siendo el peso pesado a batir.