Hyperliquid: Las guerras del frontend

Fuente: Blockworks
Título original: Hyperliquid: Las guerras del frontend
Enlace original: https://blockworks.co/news/hyperliquid-the-frontend-wars
Una de las principales innovaciones de Hyperliquid son los builder codes. Estos códigos funcionan como un parámetro a nivel de protocolo en las cargas útiles de las transacciones, permitiendo que las interfaces añadan una dirección de builder para la captura automática de comisiones en cadena. Los builders pueden añadir un recargo de hasta 100 puntos básicos ([image]1%() en spot y 10 puntos básicos ()0.1%() en perps.

Esta desvinculación entre la ejecución y la liquidación permite que los frontends moneticen el flujo propietario sin las complejidades técnicas de mantener un libro de órdenes o la ineficiencia de capital de crear liquidez desde cero. Como se muestra a continuación, los frontends de terceros integran los perps de Hyperliquid y añaden sus propios niveles de comisión variables, creando así un panorama de precios diferenciado para la misma ejecución subyacente.

![])https://img-cdn.gateio.im/webp-social/moments-8ed3514c9c-d9fbd76b35-153d09-6d5686.webp(

De esta forma, los builder codes han desbloqueado un potente círculo virtuoso de distribución. Actualmente, casi el 40% de los usuarios activos diarios operan a través de frontends de terceros en lugar de la interfaz nativa, una cuota que superó brevemente el 50% a finales de octubre. Solo los tres principales builders, Based, Phantom y pvp.trade, han capturado en conjunto más de ) millones en comisiones.

Desde la perspectiva de estructura de mercado, esto aleja a Hyperliquid del modelo de exchange de criptomonedas totalmente integrado y lo acerca más a la intermediación en capas de las acciones tradicionales. En un exchange centralizado como una gran plataforma de trading, una sola entidad controla toda la cadena, desde el onboarding, enrutamiento, casamiento y custodia.

El diseño de Hyperliquid imita al mercado de acciones estadounidense, donde los brokers minoristas poseen la relación con el cliente y monetizan la distribución, mientras enrutan órdenes a mayoristas que se encargan de la ejecución y liquidación. En efecto, la cadena se convierte en un sistema de dos capas:

• Una capa de distribución similar a un bróker, donde los builders compiten por el flujo de órdenes y se diferencian en producto y traspaso de comisiones.
• Un lugar central de ejecución, donde Hyperliquid concentra la liquidez y gestiona el casamiento y el margen.

Aunque esta desvinculación es nueva en perps cripto, ya se ha experimentado en Solana. Terminales de trading como Photon y Axiom controlaron el flujo de usuarios al centrarse en la capa de consumidor. Photon creció primero siendo el sniper de memecoins más rápido de Solana, mientras que Axiom finalmente le desafió con una suite de productos más amplia y diseños de puntos y reembolsos más agresivos. Estas terminales funcionaban efectivamente como builders: se situaban sobre los DEXs, añadían sus propios recargos y llevaban la contabilidad manualmente. Los builder codes de Hyperliquid convierten ese patrón en una primitiva nativa del protocolo.

![]$31 https://img-cdn.gateio.im/webp-social/moments-33462144f7-c276652003-153d09-6d5686.webp(

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 en Solana durante el último año, ) millones frente a ( millones de los DEXs, un múltiplo de 3,4x que demuestra que poseer el frontend suele ser más valioso que poseer el backend. Concretamente, ¿es el frontend demasiado valioso como para que Hyperliquid lo ceda?

La relación entre frontends y backends rara vez es puramente simbiótica. Frontends como Jupiter agregan varios backends y devuelven la mejor ruta según el tamaño, comisiones y restricciones de slippage.

![])https://img-cdn.gateio.im/webp-social/moments-92f9058507-55bd5bb80a-153d09-6d5686.webp$633

Esto obliga a los backends DEX a una severa compresión de márgenes. Sin barreras de entrada, deben ser la ruta más barata para ganar flujo. Como no poseen al usuario, los backends también corren el riesgo de ser sustituidos. Esto se observa cuando pump.fun reemplazó a Raydium como 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 con los builder codes en perps, es efectivamente un entorno de código de builder único. Sin embargo, si los builders evolucionan de una simple UI sobre Hyperliquid 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 builders pueden:

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

De forma similar, en finanzas tradicionales, los mayoristas compiten con los brokers-dealers por el volumen.

![]$188 https://img-cdn.gateio.im/webp-social/moments-6710c038d4-5e31c267f1-153d09-6d5686.webp(

Aunque DEXs rivales como Drift y Ostium han integrado builder codes, ninguno se ha consolidado como un competidor genuino hasta la fecha. Sin embargo, persiste un riesgo estructural importante: si un venue como Lighter emparejara los reembolsos a builders con su modelo de cero comisiones, teóricamente permitiría a wallets como Phantom y Rabby evitar la comisión de 4,5 bps de Hyperliquid. Esto permitiría a los frontends capturar toda la pila de comisiones, duplicando efectivamente sus ingresos por operación frente al modelo actual de Hyperliquid.

LiquidTrading sirve como un indicador adelantado de este futuro. La terminal respaldada por Paradigm ha facilitado $5.600 millones en volumen en Hyperliquid. Pero, crucialmente, también permite a los usuarios operar en Ostium y Lighter mediante la misma interfaz. Si los builders más grandes siguen este camino y empiezan a enrutar activamente el flujo en función de los reembolsos y no de la lealtad, los frontends builders de Hyperliquid podrían evolucionar hacia un agregador de perps comoditizado, amenazando directamente la capacidad del protocolo para capturar valor.

No obstante, existe una diferencia fundamental. El 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 sin problemas una operación entre varios pools. Sin embargo, con los perps, las posiciones son persistentes y específicas de cada 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 complejas:

• Fragmentación del usuario: Los usuarios deben mantener colateral en varios venues, lo que es ineficiente en capital y da lugar a una mala experiencia de usuario.
• Capas de prime brokerage: El router debe actuar como capa de compensación, resolviendo los difíciles problemas de extensión de crédito, cross-margining y coordinación de liquidaciones.

Mientras 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 por ahora está contenida. 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.

![])https://img-cdn.gateio.im/webp-social/moments-30450f47fa-38f120c2ad-153d09-6d5686.webp(

Además, el token HYPE añade una capa de retención. Los builders pueden mantener HYPE para acceder a descuentos en comisiones, lo que les permite acumular varias fuentes de ingresos: referidos, comisiones de builder y descuentos por volumen. Con esto, el coste de cambiar a comisiones un poco mejores puede no merecer la pena para los frontends existentes. Por último, el flujo procedente de los builders parece ser aditivo más que canibalizador. Se trata de nuevos usuarios que entran en el ecosistema a través de wallets y terminales, no de usuarios que cambian de interfaz.

Por lo tanto, si bien los builder codes ofrecen un vector de expansión eficaz, esperar que Hyperliquid mantenga un dominio total sobre su capa de distribución es poco 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 eficiente sigue siendo un foso técnico inmenso, y mientras los márgenes de los frontends sigan siendo saludables, los incentivos para que los builders cambien son bajos. Aun así, en un mercado que se expande rápidamente, no se trata de una batalla por retener volumen, sino de una carrera más competitiva por el crecimiento donde Hyperliquid sigue siendo el peso pesado a batir.