Hyperliquid : La guerre des interfaces

Source : CryptoNewsNet
Titre original : Hyperliquid : La guerre des frontends
Lien original :
L’une des principales innovations de Hyperliquid est le système des « builder codes ». Ces codes fonctionnent comme un paramètre au niveau du protocole dans les charges utiles des transactions, permettant aux interfaces d’ajouter une adresse de builder pour une capture automatisée et onchain des frais. Les builders peuvent appliquer une majoration allant jusqu’à 100 points de base (1%) au comptant et 10 points de base (0.1%) sur les contrats perpétuels.

Cette séparation entre l’exécution et le règlement permet aux frontends de monétiser leur flux propriétaire sans les complexités techniques de la gestion d’un carnet d’ordres ou l’inefficacité en capital liée à la création de liquidité. Comme illustré ci-dessous, les frontends tiers intègrent les perps Hyperliquid et ajoutent leurs propres niveaux de frais variables, créant ainsi un paysage tarifaire différencié pour une même exécution sous-jacente.

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

D’un point de vue structure de marché, cela éloigne Hyperliquid du modèle d’échange crypto entièrement intégré et le rapproche de l’intermédiation en couches des marchés actions traditionnels. Sur un exchange centralisé comme une certaine bourse de tête, une seule entité contrôle toute la chaîne, de l’onboarding au routage, en passant par le matching et la conservation.

Le design de Hyperliquid imite le marché actions américain, où les courtiers grand public (Robinhood, Schwab) détiennent la relation client et monétisent la distribution, tout en routant les ordres vers des grossistes (Citadel Securities, Virtu) qui gèrent l’exécution et le règlement. En pratique, la chaîne devient à deux niveaux :

• Une couche de distribution type courtier, où les builders se disputent le flux d’ordres et se différencient par le produit et le passage des frais.
• Une plateforme d’exécution centrale, où Hyperliquid concentre la liquidité et gère le matching et le margining.

Bien que nouveau pour les perps crypto, ce mécanisme de découplage s’est déjà produit 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 grâce à sa rapidité sur les memecoins Solana, tandis qu’Axiom l’a ensuite concurrencé avec une offre produit plus large et des systèmes de points et de remises plus agressifs. Ces terminaux jouaient le rôle de builders : ils se posaient sur les DEXs, ajoutaient leur propre majoration de frais, et géraient la comptabilité manuellement. Les builder codes de Hyperliquid transforment essentiellement ce modèle en une primitive native du protocole.

Cependant, l’exemple Solana met aussi en avant un risque. Les terminaux de trading ont capté 77 % des revenus DEX de Solana sur l’année écoulée, $633 millions contre $188 millions pour les DEXs, soit un multiple de 3,4 qui illustre que posséder le frontend est souvent plus rentable que posséder le backend. Plus précisément, le frontend est-il trop précieux pour que Hyperliquid puisse s’en séparer ?

La relation entre frontends et backends est rarement strictement symbiotique. Les frontends comme Jupiter agrègent divers backends (Meteora, Raydium, Orca) et retournent le meilleur routage en fonction de la taille, des frais et des contraintes de slippage.

Cela force les backends DEX à une compression sévère des marges. Sans avantage compétitif, ils doivent être la route la moins chère pour capter le flux. N’étant pas propriétaires de l’utilisateur, les backends sont aussi à risque d’être remplacés. On le constate lorsque pump.fun a remplacé Raydium comme backend de liquidité par son propre AMM interne, impactant considérablement la part de volume de Raydium.

Pour l’instant, Hyperliquid n’a pas ce problème. En étant pionnier sur les builder codes pour les perps, il se trouve dans un environnement à builder code unique. Cependant, si les builders évoluent d’une simple UI reposant sur HL vers de véritables routeurs capables d’envoyer du flux vers des backends concurrents, ils commencent à ressembler à un smart-order router de la finance traditionnelle. Dans ce scénario, les builders peuvent :

• Optimiser le coût total : calculer spread/slippage + frais taker/maker + surcharge builder − remises + financement attendu.
• Négocier avec les plateformes : demander une part builder ou des remises plus élevées sous menace de router le flux ailleurs.
• Capturer la relation utilisateur : tandis que les venues sont contraintes de se battre uniquement sur le prix, en tant que fournisseurs de liquidité de gros à meilleure exécution.

De même, en finance traditionnelle, les grossistes rivalisent avec les broker-dealers pour le volume. Robinhood route vers Citadel Securities, Virtu et Jane Street selon qui offre la meilleure exécution et le meilleur paiement pour le flux d’ordres.

Bien que des DEX rivaux comme Drift et Ostium aient intégré les builder codes, aucun ne s’est imposé comme véritable concurrent à ce jour. Toutefois, un risque structurel majeur subsiste : si une plateforme comme Lighter associait des remises builder à son modèle zéro frais, elle pourrait théoriquement permettre à des wallets comme Phantom et Rabby de contourner les 4,5 bps de frais Hyperliquid. Cela permettrait aux frontends de capter toute la pile de frais, doublant effectivement leur revenu par trade comparé au modèle actuel d’Hyperliquid.

Un indicateur avancé de ce futur est LiquidTrading. Le terminal soutenu par Paradigm, qui a levé 7,6 millions de dollars en seed, a facilité 5,6 milliards de dollars de volume sur Hyperliquid. Mais surtout, il permet également aux utilisateurs de trader sur Ostium et Lighter via la même interface. Si les builders plus importants suivent cette voie et commencent à router activement le flux selon les remises et non la fidélité, les frontends builder Hyperliquid pourraient évoluer en agrégateurs de perps banalisés, menaçant directement la capacité du protocole à capter la valeur.

Cependant, une différence fondamentale subsiste. Le spot est facile à agréger car chaque swap est atomique et l’actif est fongible entre plateformes. Une transaction égale un fill, et un routeur peut facilement répartir un trade sur plusieurs pools. Mais pour 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, en raison des différences de composition d’indice, de taux de financement, de moteurs de liquidation et de limites de risque.

Pour router efficacement les perps entre plateformes, le marché doit résoudre l’un de ces deux défis majeurs :

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

Bien que 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 offre de meilleures marges. Pourtant, les données suggèrent que cette menace reste contenue à ce stade. Malgré un nombre élevé d’utilisateurs sur les interfaces tierces, la grande majorité du volume, plus de 90 %, provient toujours du frontend natif d’Hyperliquid.

De plus, le token HYPE ajoute une couche de rétention. Les builders peuvent détenir du HYPE pour obtenir des remises sur les frais, leur permettant de cumuler plusieurs sources de revenus : parrainages, frais builder et remises selon le volume. Ainsi, le coût du changement pour des frais légèrement meilleurs peut ne pas valoir le coup pour les frontends existants. Enfin, le flux provenant des builders semble être additif plutôt que cannibale. Ce sont de nouveaux utilisateurs qui rejoignent l’écosystème via des wallets et terminaux, et non des utilisateurs changeant simplement d’interface.

Par conséquent, bien que les builder codes offrent un vecteur d’expansion efficace, il serait irréaliste d’attendre de Hyperliquid qu’il conserve une domination totale sur sa couche de distribution. À mesure que le secteur murit, Hyperliquid devra redoubler d’efforts pour défendre sa position face aux agrégateurs et concurrents à faibles frais. Toutefois, la construction d’un carnet d’ordres onchain performant reste un avantage technique considérable, et avec des marges frontend encore saines, les incitations pour les builders à changer restent faibles. Mais sur un marché en forte expansion, il ne s’agit plus de conserver le volume, mais d’une course à la croissance où Hyperliquid reste le poids lourd à battre.