Kelp DAO conteste désormais ouvertement la version des événements de LayerZero après l'exploit de 292 millions de dollars qui a drainé 116 500 rsETH et déclenché des inquiétudes plus larges sur les marchés de prêt DeFi.
Dans une déclaration publiée sur X, Kelp a repoussé les critiques de LayerZero concernant sa configuration DVN 1-of-1, affirmant que cette configuration n'avait pas été improvisée ni choisie à l'encontre des recommandations. Selon Kelp, cette configuration était celle documentée dans les propres supports de LayerZero et fournie par défaut pour les nouveaux déploiements OFT.
Cette réponse est importante car le rapport précédent de LayerZero avait présenté la configuration de Kelp comme une faiblesse fondamentale. Dimanche, LayerZero a déclaré que l'attaquant, probablement lié au groupe Lazarus de Corée du Nord, avait accédé à la liste des nœuds RPC utilisés par le réseau vérifié décentralisé de LayerZero Labs, puis avait empoisonné deux de ces nœuds et lancé une attaque DDoS pour forcer l'acceptation d'un faux message cross-chain.
LayerZero a soutenu que la configuration DVN 1-of-1 de Kelp avait créé un point de défaillance unique, car elle manquait de la vérification indépendante nécessaire pour détecter le message frauduleux avant qu'une transaction illégitime ne soit signée.
Kelp, cependant, trace la limite ailleurs. Il a indiqué qu'il opère sur l'infrastructure LayerZero depuis janvier 2024 et qu'il a maintenu un canal ouvert avec l'équipe tout au long de cette période. Il a également précisé que la configuration DVN avait été spécifiquement discutée lors de son expansion vers la Layer 2, et que la structure par défaut avait été « affirmativement confirmée comme appropriée » à l'époque.
Ce désaccord n'est pas seulement une question de réputation. Il survient alors qu'Aave examine des scénarios de mauvaises créances liés aux effets de contagion de l'exploit, notamment autour des positions liées au rsETH et aux tensions de liquidité en ETH.
La déclaration de Kelp suggère qu'il souhaite que le post-mortem s'éloigne d'une simple attribution de responsabilité pour aller vers un rapport technique partagé. « Établir un compte rendu partagé et précis de ce qui s'est passé est le fondement pour apporter ensemble les bonnes corrections », a écrit l'équipe.
Pour l'instant, ce compte rendu partagé n'existe pas. Ce qui existe à la place, c'est une fracture croissante entre le fournisseur d'infrastructure et l'utilisateur du protocole, à un moment où un seul exploit est déjà devenu suffisamment important pour mettre à l'épreuve non seulement la sécurité des bridges, mais aussi la crédibilité des systèmes et des hypothèses construits autour de lui.
]]>

