David Schwartz, chef technologue honoraire de Ripple, a déclaré que la vulnérabilité de Kelp DAO reflète un problème plus vaste dans les infrastructures cross-chain. Il a souligné que de nombreux systèmes de pont offrent des mesures de protection robustes, mais que les équipes sont souvent encouragées à opter pour des solutions plus simples afin de réduire les coûts opérationnels. Précédemment, le pont rsETH de Kelp DAO a été attaqué le 18 avril, entraînant le vol d'environ 116 500 rsETH, l'une des pertes DeFi les plus importantes de 2026 à ce jour. Ses propos ont à nouveau suscité une attention accrue sur la manière dont les opérateurs de ponts équilibrent vitesse, coût et sécurité lors du déploiement de produits liés à des piscines de fonds importantes.
Le CTO de Ripple lie l'examen de RLUSD à un choix sécurisé
David Schwartz a déclaré qu'en évaluant les différentes options pour RLUSD, il a examiné plusieurs systèmes de pont DeFi et a mis l'accent sur les risques et la sécurité. Il a écrit que de nombreux systèmes semblaient bien conçus et incluaient des mécanismes capables de gérer les pannes apparues dans le cas de Kelp DAO.
Il a ajouté que le problème ne vient pas toujours d’un manque d’outils de sécurité. Au contraire, les fournisseurs de services mettent souvent en avant la facilité de déploiement et l’extension rapide de la chaîne, en supposant que les projets éviteront les mesures de sécurité les plus robustes. Dans les récents articles sur XRP liés au projet de stablecoin de Ripple, Schwartz a décrit ce compromis comme une faiblesse récurrente dans les déploiements de ponts.
L'événement d'exploitation de Kelp DAO recentre à nouveau l'attention sur les paramètres de LayerZero
Le pont rsETH de Kelp DAO a été attaqué le 18 avril, entraînant une perte estimée entre 290 millions et 292 millions de dollars. Selon les rapports publics et l'analyse de l'événement, l'attaquant a volé 116 500 rsETH via des activités de pont liées à LayerZero, rendant cette attaque la plus grande faille de sécurité DeFi de 2026 à ce jour.
Après l'attaque, des commentaires techniques ont souligné que le mécanisme de validation faible était le problème central. Un article d'analyse largement cité indique que la configuration du pont repose sur un modèle de validateurs un-à-un, créant un point unique de défaillance qui permet à des messages falsifiés de libérer des actifs depuis les comptes hébergés. Cette structure est devenue le centre du débat sur la question de savoir si cette faille de sécurité provient d'une utilisation insuffisante des paramètres de sécurité optionnels.
Après la faille de Kelp DAO, la valeur totale verrouillée d'Aave a été rapportée comme ayant été exploitée par un attaquant qui a utilisé des rsETH volés comme garantie pour emprunter du wETH sur la plateforme Aave v3, entraînant une forte chute du prix des rsETH. Après l'événement, Aave a gelé plusieurs marchés de rsETH et de wETH, exposant le protocole à un risque de créances douteuses d'environ 195 millions de dollars américains.
Ripple executives emphasize convenience over security
Schwartz a déclaré qu'il avait "un pressentiment" que certains problèmes pourraient provenir du fait que Kelp DAO, pour des raisons de commodité, n'a pas utilisé les fonctionnalités de sécurité clés de LayerZero. Ses propos reflètent les préoccupations générales selon lesquelles certaines équipes de ponts adoptent des configurations plus souples au début du développement et reportent les mesures de contrôle plus strictes à une phase ultérieure.
Ce point de vue apporte une nouvelle dimension aux actualités actuelles sur XRP, car l'évaluation de RLUSD tiendra toujours compte des risques liés à l'infrastructure. Les commentaires de Schwartz indiquent que l'examen interne de Ripple accorde une grande importance à la configuration pratique du système de pont, et non seulement à sa conception théorique.
Ainsi, cette vulnérabilité a déclenché un débat plus large sur la responsabilité de la conception sécurisée des ponts. Certains développeurs estiment que les applications doivent pouvoir choisir leur propre modèle de validation, tandis que les critiques affirment que cette liberté pourrait amener les développeurs à adopter des paramètres par défaut plus faibles pour faciliter le déploiement et la maintenance.