Hyperliquid : La guerre des interfaces

Source : Blockworks
Titre original : Hyperliquid : la guerre des frontends
Lien original : https://blockworks.co/news/hyperliquid-the-frontend-wars
L’une des principales innovations de Hyperliquid est le concept de codes builder. Ces codes fonctionnent comme un paramètre au niveau du protocole dans les charges utiles des transactions, permettant aux interfaces d’ajouter une adresse builder pour une capture automatisée des frais onchain. Les builders peuvent appliquer une surtaxe allant jusqu’à 100 points de base [image]1%( sur le spot et 10 points de base )0,1%( sur les perpétuels.

Cette dissociation de l’exécution et du règlement permet aux frontends de monétiser leur flux propriétaire sans la complexité technique d’un carnet d’ordres ni l’inefficacité en capital de la création de liquidité. Comme illustré ci-dessous, des frontends tiers intègrent les perpétuels Hyperliquid et ajoutent leurs propres paliers de frais variables, créant ainsi un paysage de tarification différencié pour une même exécution sous-jacente.

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

Ainsi, les codes builder ont déclenché une puissante dynamique de distribution. Près de 40 % des utilisateurs actifs quotidiens tradent désormais via des frontends tiers plutôt que via l’interface native, une part qui a brièvement dépassé 50 % fin octobre. Les trois principaux builders, Based, Phantom et pvp.trade, ont à eux seuls capturé plus de ) millions en frais.

D’un point de vue structurel, cela éloigne Hyperliquid du modèle d’échange crypto entièrement intégré, le rapprochant de l’intermédiation en couches des actions traditionnelles. Sur une plateforme centralisée majeure, une seule entité gère toute la chaîne, de l’intégration à la conservation en passant par le routage et le matching.

Le design d’Hyperliquid s’inspire du marché actions US, où les courtiers de détail possèdent la relation client et monétisent la distribution, tout en routant les ordres vers des grossistes qui gèrent exécution et règlement. Ainsi, l’architecture devient à deux niveaux :

• Une couche de distribution façon courtier, où les builders se disputent le flux d’ordres et se distinguent par leurs produits et la répercussion de frais.
• Une place centrale d’exécution, où Hyperliquid concentre la liquidité, le matching et la gestion des marges.

Si ce mécanisme est nouveau pour les perps crypto, il a déjà été expérimenté sur Solana. Des terminaux de trading comme Photon et Axiom contrôlaient le flux utilisateur en se concentrant sur la couche consommateur. Photon a d’abord grandi en tant que sniper memecoin Solana le plus rapide, puis Axiom l’a concurrencé avec une suite de produits plus large et des systèmes de points et de rebates plus agressifs. Ces terminaux jouaient effectivement le rôle de builders : superposés aux DEX, ajoutant leurs propres marges de frais, et gérant la comptabilité manuellement. Les codes builder de Hyperliquid transforment essentiellement ce schéma en un primitive native du protocole.

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

L’exemple Solana met cependant en lumière le risque. Les terminaux de trading ont capté 77 % des revenus DEX de Solana l’an passé, ) millions contre ( millions pour les DEX, soit un multiple de 3,4x — preuve que posséder le frontend est souvent plus précieux que posséder le backend. Plus précisément, le frontend n’est-il pas trop précieux pour qu’Hyperliquid le cède ?

La relation entre frontends et backends est rarement purement symbiotique. Des frontends comme Jupiter agrègent différents backends et renvoient la meilleure route selon la taille, les frais et les contraintes de slippage.

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

Cela force les backends DEX à supporter une compression sévère de leurs marges. Sans barrière à l’entrée, ils doivent être la route la moins chère pour capter le flux. Ne possédant pas l’utilisateur, les backends risquent aussi d’être remplacés. C’est le cas lorsque pump.fun a remplacé Raydium comme backend de liquidité par son propre AMM interne, impactant fortement la part de volume de Raydium.

À l’heure actuelle, Hyperliquid n’a pas ce problème. En pionnier des codes builder sur les perps, il évolue dans un environnement à code builder unique. Cependant, si les builders passent d’une simple UI sur Hyperliquid à de véritables routeurs capables d’envoyer le flux vers des backends concurrents, ils s’apparenteraient alors à un smart-order router de la finance traditionnelle. Dans ce scénario, les builders pourraient :

• Optimiser le coût total : calculer spread/slippage + frais taker/maker + surcharge builder − rebates + funding attendu.
• Négocier avec les plateformes : exiger une part builder ou des rebates plus élevés, en menaçant de router le flux ailleurs.
• Capturer la relation utilisateur : alors que les plateformes doivent uniquement rivaliser sur le prix pour être le fournisseur de liquidité de gros à la meilleure exécution.

De même, dans la finance traditionnelle, les grossistes rivalisent avec les courtiers pour le volume.

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

Bien que des DEX concurrents comme Drift et Ostium aient intégré les codes builder, aucun n’a émergé comme véritable concurrent à ce jour. Un risque structurel demeure néanmoins : si une plateforme comme Lighter associait des rebates builder à son modèle zéro frais, elle permettrait théoriquement à des wallets comme Phantom et Rabby de contourner les 4,5 bps de frais d’Hyperliquid. Les frontends pourraient ainsi capturer toute la structure de frais, doublant pratiquement leur revenu par trade par rapport au modèle actuel Hyperliquid.

LiquidTrading en est un indicateur avancé. Ce terminal, soutenu par Paradigm, a facilité 5,6 milliards de dollars de volume sur Hyperliquid. Mais surtout, il permet aussi de trader sur Ostium et Lighter via la même interface. Si les builders de plus grande taille suivent cette voie et commencent à router activement le flux en fonction des rebates de chaque plateforme plutôt que par loyauté, les frontends Hyperliquid pourraient devenir de simples agrégateurs de perps, menaçant directement la capacité du protocole à capter la valeur.

Il subsiste toutefois une différence fondamentale. Le spot est facile à agréger car chaque swap est atomique et l’actif fongible entre plateformes. Une transaction égale un remplissage, et un routeur peut aisément diviser une opération entre plusieurs pools. Mais avec les perps, les positions sont persistantes et propres à chaque plateforme. Une position BTC-PERP sur la plateforme A n’est pas fongible avec une position BTC-PERP sur la plateforme B à cause de différences dans la composition des indices, les taux de funding, les moteurs de liquidation et les limites de risque.

Pour router efficacement les perps entre plateformes, le marché a besoin d’une des deux solutions complexes suivantes :

• Fragmentation utilisateur : Les utilisateurs doivent déposer du collatéral sur plusieurs plateformes, ce qui est inefficace en capital et dégrade l’expérience.
• Couches de prime brokerage : Le routeur doit agir comme une couche de compensation, résolvant les problèmes complexes d’octroi de crédit, de cross-margining et de coordination des liquidations.

Si la non-fongibilité offre une défense à court terme, la réalité est que les frontends sont des acteurs économiques rationnels ; ils migreront si un concurrent propose de meilleures marges. Pourtant, les données suggèrent que cette menace reste contenue. Malgré l’afflux d’utilisateurs sur les interfaces tierces, la grande majorité du volume, plus de 90 %, provient toujours du frontend natif Hyperliquid.

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

De plus, le token HYPE ajoute une couche de rétention. Les builders peuvent détenir du HYPE pour accéder à des réductions de frais, leur permettant d’empiler plusieurs sources de revenus : parrainages, frais builder et remises selon le volume. Ainsi, le coût de migration pour quelques points de frais supplémentaires pourrait ne pas valoir le coup pour les frontends existants. Enfin, le flux issu des builders semble être additif plutôt que cannibale : il s’agit de nouveaux utilisateurs qui entrent dans l’écosystème via des wallets et terminaux, pas de simples switchs d’interface.

Par conséquent, si les codes builder offrent un excellent vecteur d’expansion, il serait irréaliste d’attendre d’Hyperliquid qu’il conserve un contrôle total sur sa couche de distribution. À mesure que le secteur mûrit, Hyperliquid devra redoubler d’efforts pour défendre son avance face aux agrégateurs et aux concurrents à bas frais. Toutefois, la construction d’un carnet d’ordres onchain performant demeure une barrière technique majeure, et tant que les marges sur les frontends restent confortables, les incitations au changement pour les builders sont faibles. Mais dans un marché en forte expansion, il ne s’agit plus tant de retenir le volume que de mener une course à la croissance où Hyperliquid reste le poids lourd à battre.