Hyperliquid et l'attaque JELLY : Faille technique et solution de l'équipe

Rappel des faits

Cette semaine, Hyperliquid a été victime d’une attaque particulièrement bien exécutée, visant à mettre en péril la solvabilité du protocole en exploitant certaines limites dans le fonctionnement des mécanismes de liquidation. Dans un premier temps, il est important de faire un rappel des faits.

Le 26 mars 2025, plusieurs adresses récemment créées ont ouvert des positions sur le token JELLY, un memecoin lancé sur Pump fun et disponible au trading sur Hyperliquid. Au moment des faits, la capitalisation du token était de l’ordre de 10 millions de dollars. Les 3 positions sont les suivantes : un short de 4,5 millions de dollars et deux long d’environ 2,5 millions de dollars (avec effets de levier).

Quelques instants plus tard, la position du trader en short se retrouve en profit et il décide de retirer graduellement sa marge, forçant ainsi sa propre liquidation. À cet instant, le mécanisme de liquidation d’Hyperliquid se déclenche, mais ne parvient pas à réaliser l’opération : il n’y avait pas assez de liquidité dans le carnet d’ordres pour permettre la clôture de la position.

Ainsi, la position est récupérée par le vault spécialisé dans la liquidation (un module dépendant directement du HLP, dont nous parlerons par la suite) avec pour objectif de la déboucler le plus rapidement possible, sans impacter le cours de manière significative.

Toutefois, en parallèle de la liquidation de la position short, une adresse sur Solana achète une énorme quantité de JELLY en spot, faisant grimper le cours du token d’environ 250 %. En quelques minutes seulement, la position désormais détenue par le HLP est en perte latente d’environ 12 millions de dollars.

Pour préserver l’intégrité de la plateforme et des fonds des utilisateurs contenus dans le vault HLP, Hyperliquid a dû réagir rapidement : les validateurs ont voté à l’unanimité pour clôturer la position en ignorant le prix du JELLY donné par l’oracle (oracle override) et en le modifiant artificiellement pour annuler toutes les dettes du HLP.

La fondation a annoncé que tous les traders sur une position long seront remboursés (sauf les portefeuilles qui ont participé à l’attaque et qui ont été ‘flag’ par l’équipe) comme si leur position avait été soldée au prix réel du JELLY au moment des faits.

---

Fonctionnement d'une liquidation sur Hyperliquid

Maintenant que le décor est correctement placé, il est temps de comprendre plusieurs éléments : comment fonctionne une liquidation sur Hyperliquid, quels sont les mécanismes de sécurité en place pour éviter ce genre de situation et pourquoi ne se sont-ils pas déclenchés ?

Liquidator Vault (et HLP)

Comme sur n’importe quelle plateforme permettant d’effectuer du levier, lorsqu’une position passe en dessous de son niveau de marge de maintien sur Hyperliquid, elle est éligible à la liquidation. Le protocole s’appuie alors sur un système interne, le Liquidator Vault, pour prendre en charge la position et la déboucler sur le carnet d’ordre.

Le Liquidator Vault est l’une des composantes du Hyperliquidity Provider (HLP), un vault communautaire d’Hyperliquid dont le but est d’exécuter automatiquement des stratégies de market making. Les utilisateurs peuvent y déposer des USDC afin de partager les pertes et profits éventuels, au prorata de leur contribution.

La stratégie du Liquidator Vault consiste à cibler les positions étant en-dessous de 2/3 de leur marge de maintien afin de les liquider. Concrètement, le module va placer des ordres (achat ou vente, selon le cas) sur le carnet d’ordres pour exécuter la clôture (partielle ou complète) de la position.

Dans des conditions normales de marché, cette opération se fait sans difficulté. Mais lorsqu’il s’agit d’un actif à faible profondeur de liquidité, le risque devient critique et un dernier système de sécurité est alors déclenché.

Auto-deleveraging (ou ADL)

Pour renforcer ce système, Hyperliquid a également mis en place un mécanisme baptisé auto-deleveraging (ADL), qui constitue le dernier filet de sécurité en cas de problème pour gérer une liquidation.

Le fonctionnement de l’ADL est simple, mais particulièrement étonnant. Dans un cas d’extrême urgence, où une liquidation menace des pertes trop importantes pour le protocole, l’ADL peut être déclenché. Ce dernier prend l’ensemble des positions des autres traders sur l’actif en question et utilise leurs bénéfices latents pour compenser les pertes de la position en liquidation.

Par exemple, imaginons la liquidation à risque d’une position en short sur le token AAA. Si l’ADL se déclenche, le module recense l’ensemble des positions long sur le token AAA et les classe selon leur bénéfice latent. Puis, il clôture le nombre nécessaire de ces positions (en démarrant par la plus importante) afin de prendre leurs bénéfices et de compenser la perte occasionnée par la liquidation à risque.

En bref, l’ADL est une mutualisation des pertes afin de préserver le protocole. Évidemment, c’est une mesure extrêmement intrusive : elle part du principe qu’en cas d’extrême urgence, il est préférable de faire payer les utilisateurs en bénéfices plutôt que le HLP, qui est alimenté par des utilisateurs qui n’ont pas voulu être exposé à ce genre de positions à risque.

Il est important de préciser que l’ADL s’active uniquement dans des cas extrêmes (il ne s’est jamais déclenché dans l’histoire d’Hyperliquid), lorsque les marges ne permettent plus d’assurer la couverture des positions, que le liquidateur est incapable de prendre en charge le risque sans perte irrécupérable et que l’intégrité du protocole est menacée.

---

La situation du JELLY

L’attaque ciblée autour du token JELLY a mis en lumière des faiblesses structurelles au sein du système de liquidation d’Hyperliquid. En théorie, deux mécanismes sont censés empêcher un tel scénario : le Liquidator Vault (géré par le HLP) et l’auto-deleveraging (ADL). Pourtant, malgré l’ampleur de la perte latente, l’ADL ne s’est jamais déclenché. Mais alors, pour quelles raisons ?

Concernant le Liquidator Vault, nous l’avons expliqué un peu plus haut : il n’a pas été en capacité d’exécuter correctement la liquidation de la position. En effet, celle-ci représentait un montant beaucoup trop important par rapport à la capitalisation du JELLY et donc aux liquidités disponibles dans le carnet d’ordre.

Maintenant, pourquoi l’ADL ne s’est-il pas déclenché ? Pour comprendre cela, il faut d’abord rappeler que le Liquidator Vault est une entité semi-indépendante. Certes, c’est un composant intégré au HLP, mais il n’est pas le seul vault et chacun d’entre eux dispose d’un compte de trading compartimenté.

Ensuite, il faut rappeler que la logique de déclenchement de l’ADL repose sur un calcul du ratio entre les pertes encourues par la liquidation à risque et le montant total disponible sur le compte en collatéral. En bref, si le ratio est trop important, l’ADL se déclenche.

Et c’est là que se trouve le problème : dans le cas du JELLY, puisque la position a été confiée au HLP, le ratio de déclenchement de l’ADL n’était plus calculé par rapport au montant détenu par le Liquidator Vault mais par l’ensemble du HLP. Ainsi, la perte latente générée par la position, bien que massive, n’a pas déclenché le mécanisme.

Autrement dit, la mutualisation des fonds dans le HLP a empêché l’ADL de détecter une perte "critique" sur la seule stratégie de liquidation, alors même que cette position représentait un risque systémique pour le protocole. Ce design, bien qu’efficace dans des contextes de faible volatilité, a permis à une position risquée de rester ouverte trop longtemps sans déclencher le mécanisme de sécurité censé protéger les utilisateurs.

Finalement, c’est pour cette raison que l’équipe d’Hyperliquid a été dans l’obligation de convoquer un vote des validateurs afin d’exécuter la liquidation à un prix préférentiel du JELLY (celui d’avant la manipulation). L’obtention du quorum des validateurs s’est fait en quelques minutes seulement, sans aucun vote “non”, menant à la situation que nous connaissons aujourd’hui.

---

Les mesures mises en place

Suite à cet événement, l’équipe d’Hyperliquid a rapidement reconnu la gravité de la situation et annoncé plusieurs mesures correctives pour éviter qu’un scénario similaire ne puisse se reproduire. Ces actions visent principalement à renforcer les mécanismes de liquidation, limiter l’exposition du HLP, et clarifier les seuils de sécurité comme l’ADL.

Cloisonnement du Liquidator Vault et seuil de perte

La première décision clé concerne le Liquidator Vault. Désormais, sa part dans la stratégie globale du HLP sera strictement limitée à un petit pourcentage de la valeur totale du vault. Par ailleurs, elle sera réévaluée moins fréquemment pour éviter qu’elle représente rapidement une énorme part du total, comme dans le cadre de cette attaque sur le JELLY.

Cette mesure a pour but de limiter son exposition maximale en cas de liquidation complexe ou mal exécutée.

En parallèle, un seuil de déclenchement spécifique a été introduit pour l’ADL : si les pertes du Liquidator Vault dépassent un certain niveau, l’auto-deleveraging sera désormais activé, indépendamment des autres stratégies au sein du HLP. Autrement dit, le déclenchement de l’ADL ne dépendra plus du solde global mutualisé, mais bien du compte spécifique du liquidateur.

Cette mesure est un correctif logique. L’expérience fortuite du JELLY a prouvé que dans un certain cas de figure, le déclenchement de l’ADL pouvait être évité, ce qui ne sera désormais (théoriquement) plus le cas.

Ajustement dynamique de l’Open Interest maximum

L’une des problématiques de la situation du JELLY a été l’ouverture d’une position démesurée (4,5 millions de dollars) sur un token à très faible capitalisation (9 millions de dollars). Pourtant, la formule d’Open Interest Cap (OI cap), dont le but est de limiter l’Open Interest sur un actif (autrement dit, le montant total des positions), a jugé que la taille de la position du trader était admissible.

L’équipe d’Hyperliquid a reconnu une faiblesse dans sa dynamique d’évaluation. Ainsi, la formule de calcul de l’OI cap sera désormais améliorée pour intégrer directement la capitalisation réelle de l’actif et la profondeur du marché.

Cette mesure vise à empêcher l’ouverture de positions massives sur des actifs illiquides ou à faible capitalisation, réduisant ainsi les vecteurs d’attaques similaires.

Gouvernance et mécanisme de delist

Pour renforcer la résilience du protocole à long terme, les validateurs auront désormais la capacité de voter on-chain pour dé-lister un actif qui tomberait en dessous de certains seuils critiques (volatilité, manipulation suspectée, absence de volume ou de market making).

Cette mesure vise à offrir un levier de réaction supplémentaire en cas de comportements anormaux autour d’un actif, mais surtout à éviter que des actifs dangereux continuent d’exister sur la plateforme.

---

Conclusion et avis

L’histoire du JELLY a mis en lumière des failles techniques importantes dans la conception d’Hyperliquid, qui auraient pu mener à la faillite du protocole. Cet évènement a révélé à quel point il était possible de détourner le design structurel d’Hyperliquid et a placé le doute chez les utilisateurs, qui craignent que cela puisse se reproduire.

Pour autant, il serait injuste de conclure que cet épisode discrédite totalement Hyperliquid. D’abord, il faut rappeler que l’attaque était volontaire, préméditée et parfaitement orchestrée, probablement par un groupe de traders expérimentés. La réactivité de l’équipe (bien permise par un nombre restreint de validateurs) a permis d’éviter une situation catastrophique.

Ensuite, il faut saluer la réponse de l’équipe. Non seulement les failles ont été reconnues publiquement, mais des mesures concrètes ont été déployées en un temps record pour corriger les problèmes identifiés.

Contrairement à une idée reçue, cette décision (de forcer le prix du JELLY pour clôturer à un montant préférentiel) a bénéficié aux utilisateurs : tous les traders en long sur JELLY ont été remboursés comme si leur position avait été clôturée au prix réel, et seuls quelques portefeuilles soupçonnés d’avoir participé à l’attaque ont été exclus.

Ce choix assumé illustre aussi un point important que certains feignent de découvrir aujourd’hui : oui, Hyperliquid est encore partiellement centralisé. Oui, des décisions d’urgence peuvent être prises par un cercle restreint de validateurs. Mais cela n’a jamais été caché. Depuis son lancement, l’équipe a toujours présenté cette approche comme une phase transitoire permettant d’itérer rapidement sur un produit complexe, avant de tendre vers une architecture plus ouverte.

Hyperliquid est un protocole encore jeune et en construction, qui a été rapidement propulsé sur le devant de la scène. Les problèmes sont quelque chose de courant pour ce genre de projets, victimes de leur succès. Cet épisode servira évidemment de leçon, puisqu’il a permis à l’équipe de pointer du doigt les limites d’un modèle et d’exposer ses fragilités, tout en ne causant heureusement aucun tort.