Hyperliquid cobra cero comisiones de protocolo en HIP-4 mientras dura la fase de pruebas. Es una gran noticia para el que opera y un problema real para el que quiera construir encima: si el protocolo no cobra, ¿de dónde sale el dinero para mantener lo que construyes? La respuesta se llama builder code.
La idea
Un builder code es un identificador que se adjunta a las órdenes que pasan por tu aplicación. Cuando un usuario opera a través de tu interfaz —tu web, tu bot, tu terminal—, la orden lleva tu código pegado y tú te llevas un porcentaje.
No hace falta ningún acuerdo especial con nadie: es un mecanismo abierto, pensado explícitamente para que terceros puedan monetizar sin depender de que el protocolo cobre. Es, en la práctica, el modelo de negocio por defecto de cualquiera que construya sobre Hyperliquid.
Cuánto se puede cobrar
| Mercado | Comisión máxima del builder |
|---|---|
| Perpetuos | hasta 0,1% |
| Spot | hasta 1% |
Son topes, no cifras fijas: tú decides cuánto cobras dentro de ese margen. Y hay una salvaguarda importante para el usuario: tiene que aprobarlo explícitamente (firmando una autorización con un tope máximo) antes de que se le pueda aplicar nada. No es una comisión que se cuela sin avisar.
El requisito que casi nadie menciona
Para que un builder code funcione, la cuenta del builder necesita tener al menos 100 USDC en su cuenta de perpetuos. No en la wallet, no en spot: en la cuenta de perps de Hyperliquid.
Es una barrera baja en términos absolutos, pero es fácil descubrirla tarde. Antes de lanzar, verifica el saldo de la cuenta que vas a usar como builder, no solo la lógica de tu código.
Cómo se aplica en HIP-4 (y por qué es distinto)
Aquí los mercados de predicción se separan de los perpetuos: en los outcome markets, el builder fee se cobra en las órdenes de VENTA, no en las de compra.
Esto tiene una consecuencia que solo se descubre construyendo. Como los libros de Sí y No están fusionados ("comprar Sí a 0,31" es la misma orden que "vender No a 0,69"), importa por qué lado técnico entra la orden, no solo la intención del usuario. Dos personas que acaban con la misma posición económica pueden generar comisión o no según cómo se ejecutara su orden.
Si diseñas un frontend donde el usuario siempre "compra" el lado que quiere (Sí o No, indistintamente), tu ingreso por builder fee no será constante entre operaciones equivalentes. No está resaltado en ninguna documentación: se descubre en el código.
Lo que NO está documentado
Seamos honestos: no hemos encontrado en ningún sitio oficial el tope exacto de builder fee para outcome markets. Los topes de 0,1% (perps) y 1% (spot) están confirmados; si HIP-4 hereda uno de ellos, tiene el suyo propio o directamente no hay tope publicado, no está claro.
Si vas a construir con expectativas de ingreso, no des por sentado un porcentaje sin comprobarlo contra tu cuenta real. Un límite mal asumido te deja cobrando de menos, o directamente sin poder cobrar lo que habías calculado.
El paralelismo con Polymarket
Polymarket recorrió el mismo camino: con las comisiones a cero durante años, acabó montando un programa para que terceros construyeran encima y se llevaran parte del volumen que generaban. La lógica de fondo es idéntica: si el protocolo no cobra al usuario final, el ingreso tiene que salir de los frontends e integraciones.
La diferencia es que Polymarket dejó de ser gratis el 30 de marzo de 2026 (ahora cobra al taker entre 0,04% y 0,07%), mientras Hyperliquid sigue a cero. Eso significa que hoy, en Hyperliquid, el builder code es literalmente la única vía de ingreso para un tercero.
La conclusión honesta
Construir sobre HIP-4 hoy es una apuesta a que el volumen va a crecer, no un negocio ya rentable. Con ~23 outcomes y libros finos fuera de los mercados estrella, el volumen que pasa por cualquier frontend de terceros es todavía pequeño.
El mecanismo está bien diseñado y es transparente. Lo que falta es que haya suficiente gente operando como para que ese porcentaje sea un ingreso de verdad y no una anécdota.