David Schwartz, ancien CTO de Ripple, a déclaré que l'exploitation du Kelp DAO reflète un problème plus vaste dans l'infrastructure cross-chain. Il a affirmé que de nombreux systèmes de pont offrent des protections solides, mais que les équipes sont souvent encouragées à utiliser des configurations plus simples qui réduisent les coûts opérationnels. Ses commentaires sont intervenus après que le pont rsETH du Kelp DAO ait été exploité le 18 avril, avec environ 116 500 rsETH volés, l'une des pertes DeFi les plus importantes de 2026 à ce jour. Ces remarques ont de nouveau attiré l'attention 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 à de grands pools de valeur.
Le CTO de Ripple lie l'analyse de RLUSD aux choix de sécurité du pont
David Schwartz a déclaré qu'il avait évalué plusieurs systèmes de pont DeFi en examinant les options pour RLUSD, en accordant la majeure partie de son attention au risque et à la sécurité. Il a écrit que de nombreux systèmes semblaient bien conçus et incluaient des mécanismes pouvant remédier au type de défaillance observé dans le cas du Kelp DAO.
Il a ajouté que le problème n'était pas toujours l'absence d'outils de sécurité. Au lieu de cela, les fournisseurs mettaient souvent en avant la facilité de déploiement et l'expansion rapide des chaînes, en supposant que les projets éviteraient les protections les plus robustes. Dans les dernières nouvelles sur XRP liées à la planification de la stablecoin de Ripple, Schwartz a présenté ce compromis comme une faiblesse récurrente dans les déploiements de ponts.
L'exploitation de Kelp DAO a relancé l'accent sur la configuration de LayerZero
Le pont rsETH de Kelp DAO a été exploité le 18 avril, avec une perte d'environ 290 millions à 292 millions de dollars. Les rapports publics et l'analyse de l'incident ont indiqué que l'attaquant a vidé 116 500 rsETH via une activité de pont liée à LayerZero, rendant cette exploitation la plus grande violation DeFi de 2026 à ce jour.
Les analyses techniques publiées après l'attaque ont identifié une configuration de vérification faible comme problème central. Une analyse largement citée indiquait que la configuration du pont reposait sur un modèle de vérificateur un-sur-un, créant un point unique de défaillance qui a permis à un message falsifié de libérer des actifs de la garantie. Cette structure est devenue centrale dans la discussion sur la question de savoir si la violation provient de paramètres de sécurité facultatifs n'ayant pas été entièrement utilisés.
Suite à l'exploitation de Kelp DAO, la valeur totale verrouillée d'Aave a fortement chuté car les attaquants auraient utilisé du rsETH volé comme garantie pour emprunter du wETH sur Aave v3. Aave a ensuite gelé plusieurs marchés de rsETH et de wETH après que l'incident ait exposé le protocole à une dette impayée estimée à 195 millions de dollars.
Un dirigeant de Ripple met en avant la commodité plutôt que la sécurité
Schwartz a déclaré avoir eu un « pressentiment étrange » que la partie du problème pourrait impliquer Kelp DAO qui n'utilise pas certaines fonctionnalités de sécurité clés de LayerZero pour des raisons de commodité. Ses remarques corroborent les préoccupations plus larges selon lesquelles certaines équipes de ponts adoptent des configurations allégées pendant les premières phases de croissance et retardent l'implémentation de contrôles plus robustes jusqu'à plus tard.
Cette perspective ajoute une autre couche à la couverture actuelle des nouvelles concernant XRP, car RLUSD est toujours en cours d'évaluation en tenant compte des risques liés à l'infrastructure. Les commentaires de Schwartz suggèrent que l'analyse interne de Ripple a accordé une grande importance à la manière dont les systèmes de pont sont configurés dans la pratique, et non seulement à leur apparence sur papier.
Par conséquent, l'exploit a déclenché un débat plus large sur qui devrait assumer la responsabilité de la conception sécurisée des ponts. Certains développeurs affirment que les applications ont besoin de flexibilité pour choisir leur propre modèle de vérification, tandis que les critiques estiment que cette liberté peut créer une pression pour adopter des options par défaut plus faibles, plus faciles à lancer et à maintenir.