Hyperliquid: As Guerras do Frontend

Fonte: Blockworks Título Original: Hyperliquid: As guerras do frontend Link Original: https://blockworks.co/news/hyperliquid-the-frontend-wars Uma das principais inovações da Hyperliquid são os builder codes. Estes códigos funcionam como um parâmetro ao nível do protocolo nos payloads das transações, permitindo que as interfaces acrescentem um endereço de builder para captação automatizada de taxas onchain. Os builders podem adicionar uma sobretaxa até 100 pontos base (1%) em spot e 10 pontos base (0,1%) em perps.

Esta separação entre execução e liquidação permite que os frontends monetizem o fluxo proprietário sem as complexidades técnicas de manter um orderbook ou a ineficiência de capital de criar liquidez de raiz. Como ilustrado abaixo, frontends de terceiros integram os perps da Hyperliquid e adicionam as suas próprias camadas variáveis de taxas, criando efetivamente um panorama de preços diferenciado para a mesma execução subjacente.

Assim, os builder codes desbloquearam um poderoso flywheel de distribuição. Quase 40% dos utilizadores ativos diários já negoceiam através de frontends de terceiros em vez do UI nativo, uma quota que ultrapassou brevemente os 50% no final de outubro. Só os três principais builders, Based, Phantom e pvp.trade, capturaram em conjunto mais de $31 milhões em taxas.

Do ponto de vista da estrutura de mercado, isto afasta a Hyperliquid do modelo de exchange cripto totalmente integrada e aproxima-a da intermediação em camadas das ações tradicionais. Numa exchange centralizada como uma grande plataforma de trading, uma entidade controla toda a stack desde o onboarding, routing, matching e custódia.

O design da Hyperliquid imita o mercado acionista norte-americano, onde brokers de retalho detêm a relação com o cliente e monetizam a distribuição, enquanto encaminham ordens para wholesalers que tratam da execução e liquidação. Na prática, a stack passa a ser de dois níveis:

• Uma camada de distribuição tipo broker, onde os builders competem pelo fluxo de ordens e diferenciam-se pelo produto e repasse de taxas.
• Um local central de execução, onde a Hyperliquid concentra liquidez e gere matching e margining.

Embora seja novo nos perps cripto, este mecanismo de separação já aconteceu na Solana. Terminais de trading como Photon e Axiom controlaram o fluxo de utilizadores ao focarem-se na camada do consumidor. O Photon cresceu primeiro por ser o sniper de memecoins Solana mais rápido, enquanto o Axiom acabou por desafiar com uma oferta de produtos mais ampla e designs de pontos e rebates mais agressivos. Estes terminais funcionaram efetivamente como builders: assentavam sobre DEXs, adicionavam as suas próprias margens de taxas e faziam a contabilidade manualmente. Os builder codes da Hyperliquid transformam esse padrão num primitive nativo do protocolo.

No entanto, o exemplo da Solana também evidencia o risco. Os terminais de trading capturaram 77% da receita das DEXs Solana no último ano, $633 milhões contra $188 milhões das DEXs, um múltiplo de 3,4x que mostra que possuir o frontend é frequentemente mais valioso do que possuir o backend. Especificamente, será o frontend demasiado valioso para a Hyperliquid abdicar dele?

A relação entre frontends e backends raramente é puramente simbiótica. Frontends como o Jupiter agregam vários backends e devolvem a melhor rota consoante tamanho, taxas e limites de slippage.

Isto força os backends das DEXs a uma compressão severa de margens. Sem qualquer fosso competitivo, têm de ser a rota mais barata para captar o fluxo. Como não detêm o utilizador, os backends correm também o risco de serem substituídos. Vemos isto quando a pump.fun substituiu a Raydium como backend de liquidez pelo seu próprio AMM interno, afetando significativamente a quota volumétrica da Raydium.

Neste momento, a Hyperliquid não enfrenta este problema. Ao inovar com builder codes em perps, é efetivamente um ambiente de builder code único. No entanto, se os builders evoluírem de um UI sobre a Hyperliquid para verdadeiros routers capazes de encaminhar fluxo para backends concorrentes, começam a assemelhar-se a smart-order routers das finanças tradicionais. Neste cenário, os builders podem:

• Otimizar o custo total: Calcular spread/slippage + taxas taker/maker + sobretaxa do builder − rebates + funding esperado.
• Negociar com venues: Exigir maior quota de taxas para builders ou rebates sob ameaça de encaminhar o fluxo para outro lado.
• Capturar a relação com o utilizador: Enquanto as venues são forçadas a competir apenas para serem o fornecedor de liquidez grossista mais barato e com melhor execução.

De forma semelhante, nas finanças tradicionais, os wholesalers competem com broker-dealers pelo volume.

Embora DEXs rivais como Drift e Ostium tenham integrado builder codes, nenhuma emergiu até agora como competidora genuína. No entanto, mantém-se um risco estrutural relevante: Se uma venue como a Lighter combinar rebates para builders com o seu modelo de zero taxas, poderia teoricamente permitir que wallets como Phantom e Rabby evitassem a taxa de 4,5 bps da Hyperliquid. Isto permitiria aos frontends capturar toda a stack de taxas, duplicando efetivamente a receita por trade em comparação com o modelo atual da Hyperliquid.

A LiquidTrading serve como indicador deste futuro. O terminal apoiado pela Paradigm facilitou $5,6 mil milhões em volume na Hyperliquid. Mas, crucialmente, também permite aos utilizadores negociar em Ostium e Lighter através da mesma interface. Se builders maiores seguirem este caminho e começarem a encaminhar o fluxo de forma ativa com base em rebates das venues em vez de lealdade, os frontends builders da Hyperliquid podem evoluir para agregadores de perps comoditizados, ameaçando diretamente a capacidade do protocolo de capturar valor.

Ainda assim, há uma diferença fundamental. O spot é fácil de agregar porque cada swap é atómico e o ativo é fungível entre venues. Uma transação equivale a um fill, e um router pode dividir uma trade por múltiplos pools sem problemas. No entanto, nos perps, as posições são persistentes e específicas da venue. Uma posição BTC-PERP na Venue A não é fungível com uma posição BTC-PERP na Venue B devido a diferenças na composição do índice, taxas de funding, mecanismos de liquidação e limites de risco.

Para encaminhar perps entre venues de forma significativa, o mercado precisa de uma de duas soluções difíceis:

• Fragmentação do utilizador: Os utilizadores têm de manter colateral em várias venues, o que é ineficiente em termos de capital e resulta numa má experiência de utilização.
• Camadas de prime brokerage: O router tem de atuar como uma camada de compensação, resolvendo os difíceis problemas de extensão de crédito, cross-margining e coordenação de liquidações.

Embora a não-fungibilidade ofereça uma defesa de curto prazo, a realidade é que os frontends são agentes económicos racionais; migrarão se um concorrente oferecer margens superiores. Ainda assim, os dados sugerem que esta ameaça está contida neste momento. Apesar do elevado número de utilizadores em interfaces de terceiros, a esmagadora maioria do volume, mais de 90%, ainda tem origem no frontend nativo da Hyperliquid.

Além disso, o token HYPE acrescenta uma camada de retenção. Os builders podem deter HYPE para aceder a descontos nas taxas, permitindo-lhes empilhar fontes de receita: referências, taxas de builder e descontos por volume. Com isto, o custo de trocar para taxas marginalmente melhores pode não compensar para os frontends já existentes. Finalmente, o fluxo proveniente dos builders parece ser aditivo e não canibalizador. São novos utilizadores a entrar no ecossistema via wallets e terminais, não utilizadores a mudarem de interface.

Assim, embora os builder codes ofereçam um vetor de expansão eficaz, esperar que a Hyperliquid mantenha domínio total sobre a sua camada de distribuição é irrealista. À medida que o setor amadurece, a Hyperliquid enfrentará uma luta mais exigente para defender a liderança perante agregadores e concorrentes de baixas taxas. No entanto, construir um orderbook onchain de alta performance continua a ser um fosso técnico significativo, e com margens saudáveis no frontend, os incentivos para os builders mudarem mantêm-se baixos. Ainda assim, num mercado em rápida expansão, isto não é uma batalha para reter volume, mas sim uma corrida mais competitiva pelo crescimento, onde a Hyperliquid continua a ser o peso-pesado a bater.