Hyperliquid: As Guerras do Frontend

Fonte: CryptoNewsNet Título Original: Hyperliquid: As guerras do frontend Link Original: 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 adicionem um endereço de builder para captura automática de taxas onchain. Os builders podem aplicar uma sobretaxa até 100 pontos base ([image]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. Como mostrado abaixo, frontends de terceiros integram perps da Hyperliquid e adicionam as suas próprias camadas de taxas variáveis, criando assim um panorama de preços diferenciado para a mesma execução subjacente.

![])https://img-cdn.gateio.im/social/moments-53ad77fb91-90fba92826-153d09-6d5686(

Assim, os builder codes desbloquearam um poderoso ciclo de distribuição. Quase 40% dos utilizadores ativos diários negociam agora 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 maiores builders – Based, Phantom e pvp.trade – capturaram coletivamente mais de )milhões em taxas.

De uma perspetiva de 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 determinada exchange de referência, uma entidade controla toda a stack: onboarding, routing, matching e custódia.

O design da Hyperliquid imita o mercado acionista dos EUA, onde brokers de retalho ($31 Robinhood, Schwab() detêm a relação com o cliente e monetizam a distribuição, enquanto encaminham ordens para wholesalers ()Citadel Securities, Virtu() que tratam da execução e liquidação. Na prática, a stack torna-se bi-nível:

• Uma camada de distribuição tipo broker, onde builders competem por fluxo de ordens e se diferenciam pelo produto e transmissão de taxas.
• Um centro de execução central, onde a Hyperliquid concentra liquidez e trata do matching e margining.

Embora novo em perps cripto, este mecanismo de separação já se verificou na Solana. Terminais de trading como Photon e Axiom controlaram o fluxo do utilizador ao focarem-se na camada de consumidor. A Photon cresceu primeiro ao ser o sniper de memecoins mais rápido em Solana, enquanto a Axiom desafiou mais tarde com uma gama de produtos mais ampla e sistemas de pontos e rebates mais agressivos. Estes terminais funcionavam efetivamente como builders: sentavam-se por cima dos DEXs, adicionavam a sua própria margem de taxas e geriam a contabilidade manualmente. Os builder codes da Hyperliquid transformam esse padrão num primitivo nativo do protocolo.

![])https://img-cdn.gateio.im/webp-social/moments-7ad2c0abe7-829e81ae28-153d09-6d5686.webp(

No entanto, o exemplo da Solana também evidencia o risco. Terminais de trading capturaram 77% da receita dos DEXs da Solana no último ano, )milhões contra (milhões para os DEXs, um múltiplo de 3,4x que mostra que deter o frontend é frequentemente mais valioso do que deter o backend. Especificamente, será o frontend demasiado valioso para a Hyperliquid o conceder?

A relação entre frontends e backends raramente é puramente simbiótica. Frontends como o Jupiter agregam vários backends ()Meteora, Raydium, Orca$633 ) e devolvem a melhor rota consoante o tamanho, taxas e slippage.

![]$188 https://img-cdn.gateio.im/social/moments-e9dcd661c3-974de4b55f-153d09-6d5686(

Isto força os backends DEX a uma compressão severa de margens. Sem fosso competitivo, têm de ser a rota mais barata para ganhar fluxo. Como não detêm o utilizador, os backends correm também o risco de serem substituídos. Vê-se isto quando a pump.fun substituiu a Raydium como backend de liquidez por um AMM próprio, afetando significativamente a quota de volume da Raydium.

Neste momento, a Hyperliquid não enfrenta este problema. Ao inovar com builder codes em perps, está, na prática, num ambiente de código de builder singular. Contudo, se os builders evoluírem de um UI sobre a HL para verdadeiros routers capazes de enviar fluxo para backends concorrentes, começam a assemelhar-se a um smart-order router 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 maiores shares ou rebates para builders com a ameaça de encaminhar o fluxo para outro local.
• Capturar a relação com o utilizador: Enquanto os venues são forçados a competir apenas para serem o fornecedor de liquidez wholesale mais barato e eficiente.

De forma semelhante, nas finanças tradicionais, os wholesalers competem com broker-dealers por volume. A Robinhood encaminha para Citadel Securities, Virtu e Jane Street consoante quem oferece melhor execução e pagamento por fluxo de ordens.

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

Embora DEXs rivais como Drift e Ostium tenham integrado builder codes, nenhum surgiu até agora como verdadeiro concorrente. Contudo, permanece um risco estrutural significativo: se um venue como o Lighter combinasse rebates para builders com o seu modelo sem taxas, poderia teoricamente permitir que carteiras como Phantom e Rabby evitassem a taxa de 4,5 bps da Hyperliquid. Isto permitiria aos frontends capturar toda a stack de taxas, duplicando na prática a sua receita por trade face ao modelo atual da Hyperliquid.

Um indicador principal deste futuro é o LiquidTrading. O terminal apoiado pela Paradigm, que angariou $7,6 milhões numa ronda seed, facilitou $5,6 mil milhões de volume na Hyperliquid. Mas, crucialmente, também permite aos utilizadores negociar na Ostium e Lighter pela mesma interface. Se builders maiores seguirem este caminho e começarem a encaminhar ativamente o fluxo com base em rebates dos venues em vez de lealdade, os frontends de builder da Hyperliquid podem evoluir para um agregador perpético comoditizado, 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 facilmente um trade por múltiplos pools. Contudo, em perps, as posições são persistentes e específicas a cada venue. Uma posição BTC-PERP no Venue A não é fungível com uma BTC-PERP no Venue B devido a diferenças na composição do índice, taxas de funding, motores 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 devem manter colateral em múltiplos venues, o que é ineficiente em capital e resulta numa má experiência de utilizador.
• Camadas de prime brokerage: O router tem de atuar como camada de clearing, resolvendo os problemas complexos de extensão de crédito, cross-margining e coordenação de liquidações.

Embora a não-fungibilidade ofereça uma defesa a curto prazo, a dura realidade é que os frontends são agentes económicos racionais; vão migrar se um concorrente oferecer margens superiores. No entanto, os dados sugerem que esta ameaça está atualmente contida. Apesar do elevado número de utilizadores em interfaces de terceiros, a grande maioria do volume, mais de 90%, ainda provém do frontend nativo da Hyperliquid.

![])https://img-cdn.gateio.im/webp-social/moments-3945f638a3-68bda19ac7-153d09-6d5686.webp(

Além disso, o token HYPE adiciona uma camada de retenção. Os builders podem deter HYPE para aceder a descontos em taxas, permitindo-lhes acumular várias fontes de receita: referências, taxas de builder e descontos baseados em volume. Com isto, o custo de mudar por taxas marginalmente melhores pode não compensar para frontends já estabelecidos. Finalmente, o fluxo proveniente dos builders parece ser aditivo e não canibalístico. São novos utilizadores a entrar no ecossistema via carteiras e terminais, não utilizadores a trocar de interface.

Assim, embora os builder codes ofereçam um vetor eficaz de expansão, esperar que a Hyperliquid mantenha domínio total sobre a sua camada de distribuição é irrealista. À medida que o setor amadurece, a Hyperliquid terá de lutar mais para defender a sua liderança perante agregadores e concorrentes de baixas taxas. No entanto, construir um orderbook onchain de alto desempenho continua a ser um fosso técnico imenso e, com margens de frontend ainda saudáveis, os incentivos para os builders mudarem são baixos. Ainda assim, num mercado em rápida expansão, esta não é uma batalha para reter volume, mas sim uma corrida mais competitiva pelo crescimento onde a Hyperliquid permanece o peso-pesado a vencer.