Kelp DAO a annoncé son intention de migrer le jeton de restaking rsETH vers la plateforme d’oracles de Chainlink, une décision prise à la suite d’un exploit d’envergure en avril. L’organisation attribue l’incident à des failles liées à l’infrastructure inter-chaînes de LayerZero, tout en estimant que ce changement doit renforcer la sécurité du dispositif.

Une migration motivée par l’exploit d’avril

Le hack de Kelp DAO, évalué à environ 292 millions de dollars, reste parmi les incidents de sécurité les plus importants du secteur. Après l’attaque, Kelp affirme vouloir sécuriser davantage rsETH en changeant de brique d’infrastructure oracle. Selon le protocole, la migration vers Chainlink s’appuiera notamment sur CCIP, son mécanisme de communication inter-chaînes.

Lors de l’exploitation, des attaquants auraient détourné des jetons restakés et les auraient ensuite utilisés comme collatéral sur Aave v3 afin d’emprunter du wrapped Ether. Cette séquence illustre la manière dont une faille sur une couche d’infrastructure peut se répercuter sur des protocoles connectés.

Le désaccord porte sur la configuration LayerZero

Dans le prolongement de l’incident, LayerZero a publié une analyse expliquant que l’attaque aurait été facilitée par une configuration jugée insuffisante au niveau du réseau de vérification décentralisée (DVN). L’approche évoquée repose sur un chemin de vérification unique, au lieu de recourir à des contrôles multiples et indépendants pour valider les messages inter-chaînes.

De son côté, Kelp DAO soutient que la configuration incriminée correspond au réglage par défaut utilisé par de nombreux acteurs. Le protocole avance également que LayerZero aurait validé cette configuration et n’aurait pas suffisamment mis en garde contre les risques associés. Dans ce contexte, le débat ne porte pas uniquement sur la présence d’une vulnérabilité, mais aussi sur la responsabilité entre intégrateur et fournisseur d’infrastructure.

LayerZero conteste plusieurs affirmations de Kelp

Interrogé sur la controverse, un responsable de LayerZero a indiqué que certaines affirmations de Kelp seraient inexactes. Il explique notamment que l’implémentation initiale aurait reposé sur des paramètres reposant sur plusieurs vérificateurs, avant que Kelp ne modifie manuellement la configuration vers un mode moins recommandé en environnement de production.

Dans cette position, LayerZero annonce également des changements concrets : le protocole indique qu’il ne validerait plus les messages inter-chaînes pour des applications s’appuyant sur un seul vérificateur, et qu’une migration vers des configurations multi-DVN serait en cours.

Ce que révèle le dossier sur la sécurité DeFi

Au-delà du cas précis, cet épisode met en lumière une dynamique fréquente dans la finance décentralisée : la sécurité ne dépend pas d’un seul composant, mais de la chaîne complète d’interactions entre ponts inter-chaînes, oracles, mécanismes de restaking et marchés de prêt. Un point de défaillance, même localisé, peut entraîner des effets d’entraînement lorsque des contrats sont interconnectés et autorisent l’utilisation du collatéral détourné.

La décision de Kelp de migrer rsETH vers Chainlink s’inscrit donc comme une mesure de réduction des risques, mais elle relance aussi le débat sur les standards de configuration attendus dans les environnements inter-chaînes, ainsi que sur la qualité des communications entre équipes d’intégration et fournisseurs d’infrastructure.

Pour les lecteurs qui souhaitent mieux comprendre les architectures DeFi et l’usage des oracles dans des systèmes inter-chaînes, un ouvrage sur la sécurité des smart contracts en Solidity peut servir de base pour analyser ce type d’incident. De la même manière, un guide pédagogique sur les mécanismes d’oracles et de communication inter-chaînes aide à contextualiser les choix techniques évoqués dans cette affaire.