Hack de KelpDAO : Tout ce qu’il faut savoir sur ce désastre à 292 millions de dollars

Contexte autour du hack d'Aave

Qu'est-ce que KelpDAO (rsETH) ?

Lancé fin 2023, KelpDAO s'est rapidement imposé comme l'un des protocoles de liquid restaking les plus structurants de l'écosystème Ethereum. Sa proposition de valeur est simple : les utilisateurs déposent des Liquid Staking Tokens (LSTs) tels que du stETH, du cbETH ou de l'ETH natif, et reçoivent en échange du rsETH, le liquid restaking token natif du protocole.

En pratique, l'attrait de KelpDAO réside dans sa capacité à superposer les couches de rendements. En détenant du rsETH, les utilisateurs capturent simultanément des revenus issus de deux sources distinctes : les récompenses de staking d’Ether, où les validateurs sécurisent le réseau Ethereum, et la couche de restaking associée à EigenLayer, dans laquelle ce même capital est redéployé pour sécuriser des protocoles supplémentaires.

Contrairement à la plupart des options de staking traditionnelles, le rsETH conserve un haut degré de composabilité dans la DeFi : il peut être utilisé comme collatéral sur des protocoles de lending, intégré dans des pools de liquidité, ou bridgé vers d'autres blockchains via l'infrastructure OFT (Omnichain Fungible Token) de LayerZero, et ce pendant que le capital sous-jacent continue de générer du rendement sur les deux couches.

En s’appuyant sur le standard OFT de LayerZero, KelpDAO a étendu la disponibilité du rsETH sur plus de 16 blockchains. À son pic mi-2025, le protocole avait attiré plus de 2 milliards de dollars de TVL, ce qui en faisait l'un des acteurs les plus significatifs dans la verticale du liquid restaking avant le hack.

Cette architecture n’est toutefois pas sans contrepartie. Chaque couche de rendement additionnelle introduit un vecteur de risque supplémentaire : risque de staking, risque de slashing, risque lié aux smart contracts, dépendance aux oracles, mais également, et surtout, risque inhérent à l’infrastructure de bridge cross-chain. Autant de paramètres que les détenteurs de rsETH acceptent implicitement en s’exposant à ce type de produit.

La relation LayerZero-KelpDAO

Afin de rendre le rsETH pleinement fonctionnel dans un environnement multichain, KelpDAO s’est appuyé sur l’infrastructure de LayerZero, un protocole d’interopérabilité spécialisé dans la transmission de messages cross-chain.

Plus précisément, KelpDAO a adopté le standard OFT (Omnichain Fungible Token), qui permet à un token natif d’une blockchain d’être représenté sur d’autres réseaux via un mécanisme de lock-and-mint. Le mécanisme est assez intuitif et suit le même schéma que les autres tokens OFT émis par LayerZero.

Dans les faits, le rsETH est natif d’Ethereum, c’est-à-dire du Layer 1. Lorsqu’un utilisateur souhaite le transférer vers un Layer 2 comme Arbitrum ou Base, ses tokens sont d’abord verrouillés sur Ethereum au sein d’un smart contract spécifique appelé OFT Adapter, qui agit comme dépositaire des rsETH “réels”.

En parallèle, une quantité équivalente de rsETH est mintée sur la blockchain de destination. Lorsque l’utilisateur souhaite revenir sur Ethereum, le processus suit la mécanique inverse : les tokens sont brûlés sur le Layer 2, puis libérés depuis l’OFT Adapter du Layer 1.

La vérification de ces messages cross-chain repose sur des ensembles appelés DVN (Decentralized Verifier Networks), ainsi que sur des executors. La robustesse du système dépend directement du nombre de vérificateurs, de leur indépendance, et des méthodes de validation employées. Certaines reposent sur des garanties cryptographiques, d’autres sur des alternatives moins fiables, comme cela était le cas de Kelp.

Dans le modèle de LayerZero, chaque protocole configure lui-même sa propre stack de sécurité en sélectionnant les DVN chargés de valider les messages entrants. En théorie, plusieurs vérificateurs indépendants doivent confirmer un événement (comme un burn) avant qu’il ne soit exécuté sur la blockchain de destination.

Dans le cas de KelpDAO, cette architecture présentait une faiblesse majeure : un seul DVN était utilisé pour le rsETH cross-chain, et celui-ci était d’ailleurs opéré directement par LayerZero Labs.

Concrètement, cela signifie que l’ensemble du système reposait sur un unique point de validation. Une fois ce DVN compromis, plus aucune barrière ne permettait d’empêcher la validation de messages frauduleux.

Cette configuration entre en contradiction avec les recommandations explicites de LayerZero, qui préconisent l’utilisation de plusieurs DVN afin d’éliminer les points de défaillance uniques. Pourtant, KelpDAO a conservé cette architecture, un choix qui s’avérera déterminant dans le déroulement de l’attaque.

Plus fondamentalement, cette conception repose sur un principe clé appelé “bridge invariant” : l’hypothèse selon laquelle la quantité de rsETH verrouillée sur Ethereum reste en permanence supérieure ou égale à celle en circulation sur les autres blockchains.

Le déroulé de l’attaque

Pour bien comprendre comment 292 millions de dollars ont pu être volés sans qu’aucune vulnérabilité de smart contract ne soit exploitée, il est essentiel de se pencher sur le fonctionnement de l’infrastructure de vérification de LayerZero, et surtout sur le point précis où elle a failli.

En réalité, l’attaque du 18 avril 2026 est à la fois méthodique et extrêmement sophistiquée. Elle résulte très probablement de plusieurs semaines de préparation et a d’ailleurs depuis été attribuée à la Corée du Nord, plus précisément à la branche TraderTraitor du groupe Lazarus.

La première trace on-chain de l’attaque remonte au 18 avril, lorsque le wallet de l’attaquant a reçu environ 230 dollars d’ETH en provenance de Tornado Cash.

Pour une analyse technique plus approfondie de l’attaque, nous vous invitons à lire le papier de recherche très détaillé de Banteg.

• Les aspects techniques de l'attaque

L’attaque débute dans l’après-midi. À 17h35 UTC, l’attaquant appelle lzReceive, l’endpoint de LayerZero chargé de traiter les messages cross-chain entrants.

En amont, les attaquants ont réussi à obtenir la liste des RPC utilisés par le DVN de LayerZero Labs. Deux nœuds distincts ont été compromis, leur binaire op-geth remplacé, tandis qu’une attaque DDoS était simultanément lancée contre un troisième nœud non infecté, vraisemblablement opéré par QuickNode. Ce dispositif a déclenché un failover, permettant au DVN de valider des transactions qui n’avaient en réalité jamais eu lieu.

Pour comprendre ce point, il faut rappeler que les DVN s’appuient sur des nœuds RPC pour lire l’état de la blockchain, et ces derniers servent de source de vérité pour les systèmes off-chain.

Ainsi, dans une configuration robuste, plusieurs DVN indépendants et reposant sur des infrastructures devraient confirmer indépendamment un burn avant que l’OFT Adapter ne libère des tokens. Dans ce cas de figure, si un DVN avait été compromis, les autres auraient tout de même rejeté le message frauduleux.

Mais dans le cas de KelpDAO, un seul DVN était opérationnel pour le rsETH bridgé. En clair, une fois ce DVN compromis, aucun mécanisme ne permettait de filtrer ou de rejeter un message falsifié.

Le DVN compromis a ensuite validé un paquet entrant frauduleux affirmant que 116 500 rsETH avaient été brûlés sur Unichain, un burn qui n’avait en réalité jamais eu lieu. Comme le confirme le rapport d’incident d’Aave, “le nonce sortant d’Unichain est resté à 307 tandis qu’Ethereum acceptait le nonce 308”, un écart révélant la nature fabriquée du message.

Se fiant à cette validation, l’OFT Adapter sur Ethereum a libéré 116 500 rsETH de ses réserves avant de les transférer à l’adresse de l’attaquant. Ainsi, en une seule transaction, le solde de l’Adapter est passé de 116 723 rsETH à seulement 223, ce qui a mécaniquement provoqué la sous-collatéralisation de toutes les positions en rsETH sur les Layer 2.

Le malware utilisé dans l’attaque s’est ensuite auto-détruit, effaçant ses traces.

Pour résumer concrètement ce qui s’est produit : le logiciel malveillant a compromis deux des trois points d’accès à l’information, ce qui a permis de forger un message transmis au DVN et de drainer l’intégralité du collateral auquel le rsETH est adossé, sans aucune autorisation légitime.

• La réponse d'urgence de Kelp

L'équipe de réponse d'urgence de KelpDAO a détecté l'activité suspecte et s'est rapidement mobilisée pour mettre en pause l'ensemble des contrats rsETH 46 minutes après le transfert du hacker. Cette fenêtre, bien que relativement courte, a malheureusement été suffisante pour que l’attaquant sécurise les fonds.

L’attaquant a ensuite tenté deux transactions supplémentaires afin de transférer cette fois 40 000 rsETH, soit près de 100 millions de dollars. Un second paquet avait déjà été vérifié par le même DVN compromis, mais a heureusement été rejeté au niveau de l’OFT Adapter après que KelpDAO a gelé l’adresse destinataire.

Cette intervention a empêché les pertes d’atteindre 391 millions de dollars.

• La stratégie de vente des fonds volés

Liquider directement une telle quantité de rsETH sur le marché aurait eu des conséquences immédiates, à la fois en termes d’impact sur le prix et de traçabilité des fonds. L’attaquant a donc opté pour une approche bien plus structurée.

Les tokens volés ont été distribués depuis le wallet initial vers sept adresses distinctes, qui ont ensuite déposé les rsETH comme collatéral sur des protocoles de lending, principalement Aave V3 via ses marchés Ethereum et Arbitrum, afin d’emprunter du WETH liquide et du wstETH en échange.

Selon le rapport d’incident de LlamaRisk, 89 567 rsETH ont été déposés sur Aave en collatéral, l’attaquant empruntant un total de 82 650 WETH et 821 wstETH répartis sur les sept adresses. Des montants plus faibles ont également été déposés sur Euler Finance et Compound, générant respectivement environ 840 000 dollars et 39,4 millions de dollars d’emprunts supplémentaires.

En réalité, si l’attaquant a pu emprunter une telle quantité d’ETH contre son collatéral, c’est parce que le rsETH était intégré dans l’e-mode d’Aave, la partie High Efficiency du protocole qui sélectionne des actifs optimisés pour le lending et le borrowing. À titre informatif, l'inclusion dans l’e-mode requiert des valeurs d'actifs fortement corrélées (stablecoin-to-stablecoin, ou dans ce cas, actif corrélé à l'ETH contre ETH).

En parallèle, Aave offrait également la liquidité la plus profonde de tous les protocoles disponibles, ce qui a poussé l'attaquant à privilégier le protocole plutôt que des swaps directs.

Dans le même temps, l'OFT Adapter sur Ethereum étant désormais quasi-vide, chaque token rsETH sur chaque L2 était mécaniquement sous-collatéralisé, adossé à au plus 40 373 rsETH dans les réserves de l'adapter contre des positions L2 totales de 152 577 rsETH. En clair, le peg 1:1 entre rsETH sur L2 et son équivalent natif sur Ethereum a été rompu.

Une question reste cependant sans réponse à ce stade : comment l’attaquant a-t-il obtenu la liste des nœuds RPC et acquis un accès à l’infrastructure de production ? Cela suggère soit une compromission antérieure non signalée de LayerZero, soit un pipeline de déploiement compromis, soit un accès à l’infrastructure interne, plutôt qu’une simple erreur de configuration du côté de KelpDAO.

Aucune des communications post-incident des deux parties n’a, pour l’instant, apporté d’éclaircissement sur ce point.

Contagion à travers la DeFi

Les retombées du hack de KelpDAO ne sont pas restées confinées au protocole. En quelques heures, la panique s'est propagée à travers l'écosystème LayerZero, les protocoles se précipitant pour évaluer leur exposition et geler préventivement tout bridge reposant sur l'infrastructure OFT de LayerZero, y compris ceux n’ayant aucun lien avec rsETH.

Aave a rapidement gelé les marchés rsETH sur sa V3 et sa V4 afin de bloquer toute nouvelle activité. Dans le même temps, le token AAVE a chuté d’environ 11 % à l’annonce de l’incident. Compound a pris des mesures similaires, tandis que Euler Finance, Fluid, Spark et Morpho ont tous mis en œuvre des pauses ou des mécanismes d’isolement du risque sur les positions concernées. De son côté, Lido Finance a suspendu les nouveaux dépôts dans son produit EarnETH en raison de son exposition à rsETH.

Au cours des 24 heures suivantes, plus de 25 protocoles ont mis en pause leurs bridges LayerZero à titre de précaution. Parmi eux : Ethena (qui a mis en pause ses bridges OFT depuis Ethereum mainnet tout en soulignant n'avoir "aucune exposition à rsETH"), EtherFi (qui a mis en pause le bridging LayerZero pour weETH et eETH), Curve (qui a mis en pause le bridging de CRV), WBTC via BitGo et Wrapped Bitcoin, Morpho, Pudgy Penguins (PENGU), USDT0, Kamino, Swell, et des dizaines d'autres. Certains protocoles, comme Orderly Network ou f(x) protocol, ont profité de la crise pour mettre à niveau leurs propres configurations DVN et paramètres de timelock respectivement.

L'exposition indirecte via le produit EarnETH de Lido Finance a ajouté une couche supplémentaire de complexité à la contagion de l’événement. Effectivement, le protocole a révélé qu'"EarnETH a une exposition directe à rsETH via une position rsETH/ETH levier sur Aave représentant environ 9% du vault (~21,6M$)".

Les dépôts et retraits ont été immédiatement suspendus, et Lido a confirmé que son mécanisme de protection first-loss de 3 millions de dollars, financé par la trésorerie de la DAO, serait activé si nécessaire. Dans le même temps, le protocole a tenu à préciser que stETH, wstETH et l’infrastructure de staking principale n’étaient pas affectés, l’exposition étant isolée à ce seul vault.

À l’échelle du marché, la TVL DeFi a chuté de 7 % en 24 heures pour s’établir à environ 86 milliards de dollars. Aave a enregistré à lui seul près de 10,1 milliards de dollars de sorties nettes, faisant passer sa TVL d’environ 45,8 milliards à 35,7 milliards de dollars.

À ce moment-là, environ 16,5 % du marché autour de l’ETH était alors indirectement exposé au rsETH, un chiffre qui illustre à quel point le collatéral lié au restaking et l’infrastructure cross-chain s’étaient pleinement ancrés dans la structure de liquidité de la DeFi.

Dans l'ensemble, l'un des points notables ici est le "problème" de la composabilité dans la DeFi. KelpDAO était intégré dans Lido (le plus grand protocole de liquid staking, qui gérait un earn vault avec exposition au rsETH), dans Aave (dans le mode le plus capital-efficient, permettant des boucles de levier très poussées), ainsi que dans de nombreux autres protocoles.

Une fois la panique installée, les stablecoins ont également été entraînés dans la contagion, les investisseurs les plus prudents déclenchant un bank run plus large sur les protocoles DeFi. Comme toujours, les positions à levier ont subi le plus gros des dommages.

Le stETH et le sUSDe ont tous deux dépeg, tandis que les utilisateurs DeFi se précipitaient pour déboucler leurs positions sur les protocoles de lending. Par conséquent, cela a créé une vague d'opportunités d'arbitrage, mais a aussi et surtout poussé un nombre significatif de positions de lending vers la liquidation.

Responsabilités de chaque acteur

La question de savoir qui porte la responsabilité des 292 millions de dollars de pertes est rapidement devenue l'un des débats les plus houleux dans l’écosystème. En moins de 48 heures, trois parties principales ont multiplié les prises de parole publiques, chacune renvoyant la faute vers les autres. À ce stade, aucune résolution concrète n’a été annoncée, et la question de savoir qui absorbera in fine les pertes reste entière.

Dans cette partie du rapport, nous passerons en revue les déclarations publiées par les protocoles concernés.

La position de KelpDAO

La position officielle de KelpDAO, publiée via leur compte X, est que la configuration 1-of-1 DVN n'était pas un choix délibéré mais bien celle présentée comme “par défaut“ par LayerZero eux-mêmes :

"Le DVN compromis utilisait l'infrastructure propre de LayerZero. Les noeuds hébergés par LayerZero ont été compromis, et un troisième a subi un DDoS. Il s'agit d'une attaque contre l'infrastructure de LayerZero. Les systèmes propres à Kelp n'ont joué aucun rôle dans la construction ou l'opération de cette infrastructure. La configuration 1/1 DVN est inscrite dans la documentation de LayerZero et constitue le paramètre par défaut pour tous les nouveaux déploiements via l’OFT. Lors de l'expansion vers les L2 de Kelp, la configuration DVN a été discutée, et la configuration par défaut a été explicitement confirmée comme appropriée à l'époque."

En substance, Kelp conteste la caractérisation par LayerZero de la configuration "1/1" comme un choix atypique, considérant que le quickstart guide de LayerZero et la configuration GitHub par défaut pointent vers une configuration DVN 1/1. Le pire étant que, selon les données compilées, environ 32% des protocoles utilisant LayerZero emploient actuellement la même configuration.

Dans le V2 OApp Quickstart de LayerZero, le fichier sample layerzero.config.ts configure chaque canal avec un seul DVN requis et aucun DVN optionnel. Selon Kelp, le protocole s'est tout simplement appuyé sur la documentation et les configurations par défaut de LayerZero lors de ses décisions. De surcroît, malgré une communication ouverte avec LayerZero depuis juillet 2024, aucune recommandation explicite de modifier la configuration DVN de rsETH n’aurait été formulée.

Cette position a reçu un soutien notable de la part d’un certain nombre de chercheurs en sécurité on-chain. Banteg a notamment publié une analyse technique du code de déploiement public de LayerZero, notant que le setup de référence est livré avec une configuration 1/1, et signalant que LayerZero demande régulièrement aux nouveaux opérateurs d'utiliser son setup par défaut.

La position de LayerZero

De son côté, à travers un communiqué publié sur X, LayerZero a adopté la posture totalement inverse :

"LayerZero et d'autres parties extérieures ont précédemment communiqué les bonnes pratiques en matière de diversification des DVN à KelpDAO. Malgré ces recommandations, KelpDAO a choisi d'utiliser une configuration DVN 1/1", a déclaré la société.

LayerZero insiste également sur un point central : aucun de ses smart contracts n’a été compromis, aucune clé privée n’a été exposée, et le protocole core n’a pas été exploité. Selon cette lecture, la défaillance est purement architecturale et spécifique à l’application, ce qui constitue un point de défaillance unique contre lequel la documentation de LayerZero met elle-même explicitement en garde.

Effectivement, sa checklist d'intégration stipule les recommandations suivantes : "À faire : utiliser plus d'un DVN pour chaque pathway en production plutôt que de se reposer sur un seul DVN" et "À ne pas faire : configurer un seul DVN pour un pathway et le traiter comme production-ready."

Suite à l’incident, LayerZero a annoncé un changement de politique sur la gestion de son architecture DVN : le protocole cessera de signer ou d'attester des messages pour toute application maintenant des configurations single-DVN. Autrement dit, tous les projets utilisant actuellement des configurations 1/1 devront migrer vers des architectures multi-DVN.

LayerZero opère sur plus de 80 blockchains avec 35 DVN actifs, notamment via des fournisseurs comme Google Cloud. Selon eux, la bonne pratique consiste à avoir plusieurs vérificateurs indépendants contrôlant chaque message cross-chain, soit exactement ce que Kelp n'a pas mis en oeuvre.

En réalité, la vérité se situe probablement quelque part entre les deux versions. Les mises en garde existent bien dans la documentation, mais elles sont reléguées dans des sections que de nombreux développeurs ne consultent pas nécessairement en priorité, tandis que les configurations par défaut restent plus permissives.

De notre point de vue, les deux parties portent une responsabilité significative : KelpDAO pour n'avoir pas conduit un audit de sécurité plus rigoureux de sa configuration de bridge, et LayerZero pour avoir enfoui les dangers de sa configuration par défaut là où la majorité des développeurs ne les trouveront probablement jamais. Plus fondamentalement, une configuration DVN 1/1 n'aurait tout simplement jamais dû être possible.

Le résultat, pour l'heure, est que ce sont les utilisateurs DeFi qui semblent absorber la perte. Les différents scénarios possibles ont été détaillés dans la publication postée sur le forum de gouvernance d'Aave par LlamaRisk.

Le rôle d'Aave

Aave occupe une position différente dans cette affaire. Le protocole n’était ni la cible de l’attaque, ni impliqué dans les choix de configuration du bridge. Il est une victime indirecte de la composabilité.

Les contrats d'Aave, son système d'oracle et ses mécanismes de liquidation ont tous fonctionné exactement comme prévu tout au long de l'incident. En clair, la faille ne provenait pas de ses propres smart contracts.

Le problème n'est pas qu'Aave ait dysfonctionné, mais plutôt que son cadre de gestion du risque ait accepté le rsETH comme collatéral avec un ratio loan-to-value allant jusqu'à 95% sans intégrer dans son analyse les propriétés de sécurité du bridge sous-jacent, notamment la configuration DVN.

Pourtant, le point de défaillance avait été soulevé lors de discussions portant autour de l’onboarding du rsETH sur Base et Arbitrum en février 2025. Effectivement, les équipes de BGD Labs avaient explicitement mis en avant les risques liés à une configuration DVN unique et recommandé une approche multi-DVN. Malgré ces avertissements, les recommandations ont finalement été ignorées.

Lorsque l’attaquant a utilisé des rsETH sans collatéralisation sous-jacente pour emprunter du WETH réel, Aave n’avait aucun moyen de détecter l’anomalie. Du point de vue du protocole, le collatéral était valide puisqu’il avait été reconnu sur Ethereum. Au moment du gel des marchés, 89 567 rsETH, soit environ 221 millions de dollars, avaient déjà été déposés sur Aave, avec 193 millions de dollars empruntés en face.

Ces positions sont désormais bloquées avec des health factors d’environ 1,01 à 1,03, c’est-à-dire des marges extrêmement étroites qui ne laissent à Aave pratiquement aucune marge avant que des bad debts ne se matérialisent.

C'est l'essence même du risque de composabilité dans la DeFi : Aave détient désormais des positions qu'il ne peut pas liquider sans danger (les pools WETH sont à 100% d'utilisation, rendant la liquidation techniquement complexe), contre un collatéral de valeur incertaine, et ce en tant que simple spectateur d'une défaillance survenue quatre couches protocolaires au-dessus dans l’architecture du rsETH.

Quoi qu'il en soit, comme l'a expliqué Emilio, VP Engineering chez Aave, le protocole se trouve actuellement dans une position d'attente, dépendant directement des réponses de LayerZero et de KelpDAO pour pouvoir décider quoi que ce soit.

"Nous faisons de notre mieux, mais nos actions dépendent des autres en premier lieu ; sans cela, nos mains sont liées de ce point de vue. Nous développons d'autres possibilités qui ne dépendent pas des autres, mais celles-ci prennent du temps à mettre en place", a-t-il déclaré.

Selon la modélisation de LlamaRisk, la bad debt potentielle oscille entre 123,7 millions de dollars (socialisation uniforme) et 230,1 millions de dollars (pertes isolées au rsETH sur les L2). Mais là encore, à ce stade, ces chiffres restent purement hypothétiques. Le résultat final dépendra très largement des décisions prises par KelpDAO et LayerZero.

La situation chez Aave

Sur les 116 500 rsETH volés, le rapport d'incident d'Aave confirme que 89 567 rsETH (soit 76,9% du montant total dérobé) ont été déposés comme collatéral sur Aave V3. Les positions sont réparties entre Ethereum et Arbitrum via sept adresses, comme suit :

La procédure défensive d'Aave a été rapidement mise en place : le Protocol Guardian a commencé à geler toutes les réserves rsETH et wrsETH sur l'ensemble des marchés Aave V3 concernés à environ 19h00 UTC le 18 avril. Concrètement, la LTV a été fixée à zéro et les dépôts et emprunts ont été provisoirement mis à l’arrêt, et ce tout en laissant les positions existantes éligibles au remboursement et à la liquidation.

Onze marchés sur Ethereum, Arbitrum, Avalanche, Base, Ink, Linea, Mantle, MegaETH, Plasma et ZkSync ont été affectés par l’opération. Le Risk Steward a ensuite ajusté les modèles de taux d'intérêt sur le WETH le 19 avril, réduisant les taux d'emprunt de 8,5-10,5% à 3,0% APR à 100% d'utilisation afin d'empêcher les intérêts cumulés d'accélérer la bad debt. Le 20 avril, le WETH lui-même a été gelé sur Core, Prime, Arbitrum, Base, Mantle et Linea pour prévenir de nouveaux emprunts de WETH susceptibles d'aggraver l'exposition.

Encore une fois, les smart contracts d'Aave n'ont à aucun moment été compromis au cours de ces événements. Toute la logique du protocole, qu’il s’agisse des mécanismes de dépôt, de remboursement ou de liquidation, a continué de fonctionner comme prévu. L'incident est survenu entièrement en dehors d'Aave.

Cependant, un autre problème est apparu suite aux mesures prises par Aave : les réserves de WETH sur Ethereum, Arbitrum, Base, Linea et Mantle ont très vite atteint 100% d'utilisation. En pratique, chaque WETH déposé dans ces marchés est déjà en circulation sous forme de prêt, laissant des soldes de liquidités disponibles de moins de 20 dollars par blockchain.

Cela crée un obstacle pratique aux liquidations : lorsqu'un liquidateur tente de saisir du collatéral en WETH, la pool ne peut pas payer directement en WETH et émet à la place des tokens aWETH, ce qui a pour conséquence d’immobiliser le capital du liquidateur dans la réserve.

Llamarisk a identifié Base et Arbitrum comme les marchés les moins couverts, les premières liquidations étant déclenchées par des baisses du prix du WETH de seulement 0,77% et 1,77% respectivement, étant donné que les positions affichent des health factors autour de 1,03.

Au 20 avril 2026, la trésorerie de la DAO Aave détient 181 millions de dollars d'actifs, dont 62 millions sont corrélés à l’Ether, 54 millions en tokens AAVE et 52 millions en stablecoins. Parallèlement, la DAO a généré 145 millions de dollars de revenus totaux en 2025 et 38 millions depuis le début de l'année 2026. Llamarisk a confirmé que différentes parties impliquées dans l’écosystème s’étaient montrées prêtes à mettre leur trésorerie à contribution dans un scénario de bad debt trop lourde.

Dans le cadre du Scénario 1 (socialisation uniforme des pertes), l'Umbrella WETH Safety Module, qui détient environ 23 507 aWETH d'une valeur de 54 millions de dollars, pourrait partiellement compenser la bad debt d'Ethereum Core. Cependant, 18 922 aWETH (80% du module) sont déjà rentrées dan la file d’unstaking, ce qui signifie que les stakers tentent de sortir avant même que le module ne puisse être déployé comme filet de sécurité.

Face à cette situation, les service providers d'Aave ont recommandé de mettre immédiatement en pause le module Umbrella pour prévenir toute nouvelle fuite de capital et préserver sa capacité de couverture.

Le 21 avril, les dépôts en WETH ont été rouverts, permettant aux utilisateurs de fournir du WETH à l'instance Ethereum du protocole.

Suite à ces événements, la TVL d'Aave a subi des pertes significatives, avec plus de 10 milliards de dollars quittant le protocole. Malgré le déclin de cette métrique, Morpho n'a pas enregistré de gain mécanique significatif, et a même enregistré environ 1,2 milliard de dollars d’outflows depuis le hack.

D'autres protocoles, comme Sky, ont saisi l'occasion pour attaquer publiquement Aave et lui attribuer la responsabilité de la situation. Pendant ce temps, la TVL de Spark a progressé d'environ 825 millions de dollars, soit une hausse de 22%, depuis que le hack a eu lieu.

La contagion est-elle contenue ?

La réponse en surface est oui : aucun protocole supplémentaire au-delà de KelpDAO lui-même n'a été directement exploité. Chaque protocole ayant mis en pause ses bridges LayerZero l'a fait à titre de précaution, et la plupart ont confirmé n'avoir aucune exposition directe à rsETH. Et, comme mentionné précédemment dans ce rapport, LayerZero exigera de tous les opérateurs de tokens OFT sur son infrastructure d'intégrer au minimum deux DVN à l'avenir.

Blockdaemon, l'un des fournisseurs d'infrastructure DVN de LayerZero, a joué un rôle constructif dans la maîtrise de la situation. Leur équipe a travaillé avec celles de LayerZero pour auditer et mettre à niveau les configurations DVN des protocoles à risque, et leurs outils d'infrastructure ont parallèlement été utilisés par plusieurs protocoles pour vérifier leurs propres configurations DVN.

Cependant, si l’on approfondit un peu, la véritable réponse est plus complexe. Les véritables dommages se sont concentrés en deux endroits : dans les marchés d'Aave, où jusqu'à 230 millions de dollars de bad debt pourraient se matérialiser selon la manière dont Kelp alloue les pertes ; et sur les Layer 2, puisque le quasi-vidage de l'OFT Adapter sur Ethereum signifie que chaque token rsETH sur les L2 est adossé, au maximum, à 26 centimes contre un dollar.

Au-delà d'Aave, de nombreux protocoles ont intégré le rsETH pour des stratégies de looping ou pour simplement générer du yield. Le problème se trouve désormais au niveau du niveau d'utilisation des pools, avec peu ou pas de liquidité restante dans les réserves affectées. Parmi les protocoles n'ayant pas encore divulgué l'impact complet de ces événements, nous retrouvons entre autres Upshift, Kiln, World Liberty Financial, TempleDAO, Midas, Resolve Labs, Mellow Finance, et bien d'autres.

De surcroît, il n'est pas non plus clair dans quelle mesure les asset managers et les fonds sont affectés par le scénario actuel. Hyperithm, par exemple, détenait plusieurs positions de looping sur Aave avec du rsETH comme collatéral servant à emprunter du WETH. Leur situation reste tout aussi incertaine que celle des protocoles susmentionnés, lesquels restent finalement tous dans l'attente de communications de la part de KelpDAO et LayerZero.

Du côté de l'infrastructure pure, LayerZero Labs a confirmé que tous les noeuds RPC affectés ont été dépréciés et remplacés, et que le DVN concerné a repris une activité normale.

Le 21 avril, l'Arbitrum Security Council a gelé les 30 766 ETH détenus sur sa blockchain. À titre informatif, cette possibilité a toujours existé sur Arbitrum compte tenu des pouvoirs de ce conseil, explicitement visibles sur L2Beat. En pratique, cela signifie que les quelque 71,5 millions de dollars d'exposition côté Arbitrum ont déjà été contenus. Ces fonds sont actuellement gelés et attendent, eux aussi, une résolution de la part de LayerZero et KelpDAO.

Ainsi, la menace immédiate est contenue du côté des infrastructures impliquées. Ce qui reste non résolu, c’est le bilan financier : la bad debt figurant dans la comptabilité d'Aave, la question ouverte de la manière dont Kelp répartira les pertes entre les détenteurs de rsETH sur mainnet et sur les Layer 2, et le sort incertain des fonds détenus par l'attaquant.

Qui va subir les pertes ?

À ce stade, la question qui demeure non résolue est aussi simple que déterminante : qui devra payer ?

La réponse repose sur une distinction technique que la plupart des détenteurs de rsETH n'avaient probablement jamais envisagée : le rsETH sur Ethereum est adossé aux positions de staking avec des ETH bien réels de Kelp, avec de vrais dépôts en ETH qui génèrent du rendement et peuvent être rachetés via le processus de retrait normal de Kelp.

L'OFT Adapter n'a, en réalité, rien à voir avec ce backing. Le rsETH sur les Layer 2 est, en revanche, adossé exclusivement à l'OFT Adapter sur Ethereum, lequel a été quasi intégralement vidé.

À titre informatif, les 40 373 rsETH restants dans l'OFT Adapter après le blocage de la seconde attaque ne représentent que 26,46% des 152 577 rsETH circulant actuellement sur l'ensemble des L2.

Le rapport d'incident d'Aave publié par Llama Risk modélise deux scénarios plausibles pour la manière dont Kelp résoudra cet écart :

• Scénario 1 : Socialisation uniforme des pertes.

Selon cette première approche, les 112 204 rsETH non adossés (l'écart entre ce qui a été volé et ce qui a été récupéré) diluent l'ensemble de l'offre de rsETH de manière égale, mainnet et L2 confondus. Le calcul aboutit à un depeg de 15,11%, ce qui signifie que chaque rsETH conserverait 84,89% de sa valeur oracle d'avant le hack.

Sur Aave, cela se traduirait par environ 123,7 millions de dollars de bad debt, concentrée principalement sur Ethereum Core (91,8M$). Bien que ce chiffre soit significatif dans l’absolu, cela ne représente que 1,54% de sa réserve de WETH équivalente à 5,98 milliards de dollars. Le Layer 2 Mantle fait face à la pression proportionnelle la plus forte avec un shortfall sur le WETH évalué à 9,54%. Dans ce scénario, l'Ethereum Core Umbrella WETH module (54M$) pourrait absorber une partie significative des dommages.

• Scénario 2 : Pertes isolées au rsETH sur les Layer 2.

Dans ce scénario, les rsETH du mainnet sont traités comme intégralement intacts (étant véritablement adossés à des ETH), tandis que la valeur des rsETH sur les Layer 2 est réévaluée pour refléter le ratio de backing réel de l'adapter de 26,46%, ce qui se traduit par une perte d’environ 73,54%. En clair, les conséquences financières seraient catastrophiques pour les marchés concernés sur les Layer 2, et pour les utilisateurs.

La bad debt totale s’établirait à 230,1 millions de dollars, entièrement concentrée sur les Layer 2. Mantle ferait face à un shortfall sur le WETH de 71,45%, ce qui signifie que plus de 70% de chaque WETH fourni au marché Aave de Mantle pourrait être perdu. De son côté, Arbitrum fait face à un shortfall de 26,67%, et Base de 23,28%.

Ainsi, les deux scénarios exposent une asymétrie profonde dans la répartition des pertes. Le Scénario 1 est plus équitable, mais répartit des dommages modérés sur l'ensemble des détenteurs de rsETH. Si le Scénario 2 semble techniquement plus défendable (les détenteurs de rsETH sur L2 font face aux conséquences directes de la défaillance du bridge à laquelle ils étaient exposés), il serait néanmoins catastrophique pour les marchés Aave de Mantle et Arbitrum.

Par ailleurs, la situation a également suscité des réactions véhémentes de la part des utilisateurs affectés. Leur principal argument de défense repose sur la propre documentation de LayerZero, qui stipule que les Omnichain Fungible Tokens (OFTs) bénéficient d'une liquidité unifiée. De leur point de vue, cela implique une fongibilité qui transcende les frontières des réseaux : théoriquement, les détenteurs de rsETH sur le Layer 1 ne devraient pas disposer d’un quelconque droit hiérarchique par rapport à ceux qui détiennent l'actif sur les Layer 2.

Pour sa part, KelpDAO n'a jamais explicitement abordé une hiérarchie potentielle des créances en cas de défaillance de l'infrastructure cross-chain. Quoi qu'il en soit, le choix appartient à KelpDAO, et au moment où ces lignes sont écrites, aucune décision officielle n'a été publiée.

En parallèle, la réponse d'Arbitrum a introduit une dimension supplémentaire dans cette histoire. Le 21 avril, l'Arbitrum Security Council a eu recours à un type de transaction spécifique ArbitrumUnsignedTxType (EIP-2718), permettant à la DAO d’Arbitrum de transférer 30 776 ETH d'une valeur d'environ 70,6 millions de dollars depuis l'adresse du hacker vers une adresse contrôlée par la DAO.

Pour le moment, il est admis que ces fonds seront conservés en attente d'une résolution basée sur les décisions des autres parties. Il convient de noter que cette fonction a toujours fait partie d'ArbOS mais n'avait jamais été utilisée jusqu'à présent. Seul l'Arbitrum Security Council, composé de 12 membres, a l'autorité pour l'invoquer.

Cette décision a suscité des réactions mitigées et de nombreux débats publics. Bien qu'elle crée un précédent pour l'activation de cette fonctionnalité pour des raisons moins importantes et place une lourde charge de responsabilité sur l'Arbitrum Security Council, il est important de considérer les conséquences pour la blockchain et ses utilisateurs si cette décision n'avait pas été prise.

Si beaucoup y voient une rupture du principe de décentralisation, le choix pour le Security Council d’Arbitrum consistait soit à agir rapidement pour sauver 70M$ de fonds qui auraient directement alimenté la Corée du Nord, soit ne rien faire et laisser les utilisateurs livrés à leur sort.

Alors que l'industrie se retrouve dans une sorte de limbes entre la finance décentralisée et la finance on-chain, nous avons clairement fait un pas vers quelque chose de moins décentralisé qui protège les utilisateurs au détriment de la décentralisation. Il est aussi également important de souligner que maintenant que cette fonctionnalité a été utilisée, elle découragera probablement les hackers de tenter de voler des fonds sur Arbitrum à l'avenir.

Ce que l'industrie doit retenir

L'exploit de KelpDAO est, pour le moment, le plus grand hack dans la DeFi de l’année 2026. Mais sa signification va bien au-delà du montant volé : il a révélé un ensemble de vulnérabilités structurelles qui ne sont pas spécifiques à KelpDAO.

En réalité, elles sont endémiques à la manière dont les protocoles cross-chain sont conçus, déployés et évalués par les protocoles et les utilisateurs qui en dépendent.

1. Le problème du DVN 1/1 n'est pas un cas isolé.

Le dashboard Dune Analytics suivant les configurations DVN de LayerZero que nous avons mentionné plus tôt a révélé au lendemain du hack qu'environ 32% des OApps LayerZero utilisent une sécurité DVN minimale, c’est-à-dire des configurations similaires ou aussi faibles que celle de KelpDAO. Le hack de KelpDAO a démontré ce qui se produit lorsqu'un vérificateur unique est compromis.

Il est cependant important de noter qu'une configuration DVN 2/2 n'aurait très probablement pas changé grand-chose dans ce cas précis. Si deux DVN distincts s’étaient appuyés sur la même infrastructure sous-jacente et les mêmes RPC, l'attaque aurait probablement produit des résultats similaires, elle aurait simplement eu un coût supplémentaire minime pour l'attaquant.

C’est pourquoi plusieurs DVN devraient se différencier par la diversification de leurs providers RPC, la diversité de vérification avec l'introduction potentielle de preuves zk plutôt que de simples RPC, ainsi qu'un système de gestion des clés séparé qui réduirait les points de défaillance uniques.

2. Les attaques au niveau de la couche d’infrastructure contournent les modèles de sécurité traditionnels.

L'incident KelpDAO a débuté au niveau de la couche d’infrastructure, et non dans les smart contracts, ce qui lui a permis de contourner les contrôles de sécurité attendus. Les attaquants ont ciblé le système de messagerie de LayerZero qui vérifie les transferts cross-chain, plutôt que la logique des contrats elle-même.

Les audits de smart contracts traditionnels, soit l'outil de sécurité principal dans la DeFi, n'auraient pas détecté cette vulnérabilité. La surface d'attaque était en réalité un système entièrement off-chain : l'infrastructure RPC alimentant les données d'un DVN. Cela représente une catégorie de risque pratiquement absente des évaluations de risque protocolaires standards, et cela devrait exiger une nouvelle discipline d'audit de sécurité au niveau de la couche infrastructure.

3. La composabilité de la DeFi est un amplificateur de risque systémique.

Le rsETH était intégré dans des dizaines de protocoles, de blockchains et de stratégies. La composabilité, la fonctionnalité même qui rend la DeFi si innovante, devient une source de vulnérabilité systémique lorsqu'un actif interconnecté est compromis.

Si un liquid restaking token comme le rsETH est impliqué dans une faille similaire, chaque stratégie de yield farming et chaque lending pool l'utilisant fait mécaniquement face à une insolvabilité immédiate. Les protocoles ayant accepté le rsETH comme collatéral acceptaient implicitement les propriétés de sécurité du bridge de KelpDAO, un risque qui n'a jamais été rendu explicite dans leurs cadres de gestion des risques. Et ce, tout simplement parce que l'architecture du bridge n'a jamais été scrutée comme facteur de qualité du collatéral.

À l'avenir, les processus d'onboarding de collatéral et leur déploiement cross-chain devront être examinés de manière approfondie par les risk managers. Chaque fois qu'un émetteur d'actif existant s'étend vers de nouvelles blockchains, les paramètres de risque devront être réévalués après un examen approprié de la structure cross-chain et de sa sécurité.

Les smart contracts d'Aave ont fonctionné parfaitement. Ses mécanismes de liquidation, ses modèles de taux d'intérêt et la réponse de son Risk Steward ont tous été bien coordonnés. Mais ses paramètres de risque, notamment l'acceptation du rsETH comme collatéral avec un LTV allant jusqu'à 95% sans analyse du mécanisme de bridge associé, l'ont exposé à des défaillances externes. À l'avenir, tout token dont la valeur dépend d'un bridge cross-chain devrait intégrer la configuration de sécurité de ce bridge dans son évaluation des risques.

Un token adossé à un DVN 1/1 présente un profil de risque fondamentalement différent de celui d'un token à vérificateurs multiples ou natif d'un bridge.

Conclusion

Avant de présenter notre propre point de vue sur la situation, nous souhaitons remercier les chercheurs et les sources qui ont rendu ce rapport possible. En particulier : Banteg (@banteg), Tay (@tayvano_), Seal911 (@_SEAL_Org), LlamaAI (l'IA de DefiLlama qui a été utilisée pour collecter davantage de sources et de données pour ce rapport), AlphaFolio (@AlphaFolio), ainsi que les communications des différentes parties impliquées.

Au vu des éléments réunis, il est clair que toutes les parties impliquées et affectées par ce hack ont tenté de rejeter la responsabilité sur les autres. LayerZero ne souhaite pas assumer la responsabilité de la défaillance de son infrastructure DVN. KelpDAO ne souhaite pas assumer la responsabilité d'avoir ignoré des directives publiées. Les détenteurs de rsETH sur Ethereum ne souhaitent pas subir de pertes sur leurs positions parce qu'ils n'ont jamais souscrit à un risque de bridge. Aave ne souhaite pas être tenu responsable d'avoir intégré le rsETH dans sa configuration e-mode malgré un setup de risque manifestement défaillant du côté de l'infrastructure LayerZero.

La décision d'Arbitrum consistant à geler les fonds du hacker a établi un précédent pour l'ensemble de sa blockchain et une possible responsabilité juridique dans un cas où un autre hack surviendrait sans réaction de la part du Security Council. Si elle dissuade les hackers de s'attaquer aux protocoles construits sur Arbitrum, elle soulève néanmoins des questions sur le fait de savoir si la "décentralisation" est aujourd'hui davantage un spectre qu'une simple définition binaire.

Dans l'attente de la décision finale de KelpDAO, des blockchains et protocoles comme Mantle et Aave ont signalé leur volonté de soutenir les utilisateurs affectés via leurs trésoreries. Encore une fois, les conséquences complètes du hack ne deviendront pleinement visibles qu'une fois que toutes les parties auront coordonné une réponse appropriée.

Alors que l'ensemble de l'écosystème DeFi s'affaire à répondre aux événements qui se sont déroulés, certains utilisateurs ont proposé d'implémenter les mêmes garde-fous que la TradFi a mis en place, tels que des limites, des timelocks, des actifs gelés, etc. Si cela peut paraître attrayant de prime abord, cela supprimerait également les principes pour lesquels la DeFi existe.

La leçon la plus importante de ce hack, tout comme ceux du bridge de Ronin ou de Wormhole l'ont montré par le passé, concerne les problèmes que nous avons créés avec l'interopérabilité et la composabilité entre blockchains et protocoles, lesquels affectent des utilisateurs qui n'avaient pas souscrit à ce risque.

En fin de compte, la question que nous devons nous poser, alors que les rendements en DeFi se compressent et que les risques augmentent, est la suivante : le risque vaut-il d'être pris ?

Pour l’heure, une chose est claire : LayerZero et les protocoles cross-chain doivent faire évoluer leurs standards pour offrir un service qui ne compromet pas les fonds des utilisateurs, tout en assumant la responsabilité des fonctionnalités qu'ils proposent.