Je viens de me rattraper sur quelque chose de très important qui s’est produit avec XRPL le mois dernier : une faille de sécurité critique dans l’amendement Batch proposé, qui aurait permis à des attaquants de vider des comptes et de manipuler les paramètres du grand livre sans posséder les clés privées. Honnêtement, le timing était fou. La chercheuse en sécurité Pranamya Keshkamat et l’outil Apex de Cantina AI ont signalé la vulnérabilité le 19 février, et cela coïncidait avec l’implication d’XRPL dans l’infrastructure institutionnelle. Si cela était passé en mainnet, cela aurait été catastrophique pour leur crédibilité.

Voici ce qui rendait cela dangereux : l’amendement Batch était conçu pour permettre aux utilisateurs de regrouper plusieurs transactions de manière atomique — soit toutes réussissent, soit toutes échouent ensemble. Concept simple pour des opérations multi-étapes. Mais le modèle d’autorisation comportait une faille dans la validation des signataires. Le code rencontrait un compte pas encore créé dont la clé de signature correspondait à ce compte, réussissait, et... arrêtait simplement de vérifier le reste de la liste. Cela peut sembler mineur, mais dans un système de batching ? Un attaquant aurait pu s’insérer comme signataire valide pour un compte inexistant, déclencher cette sortie prématurée, et contourner la validation pour des signataires falsifiés prétendant autoriser des comptes victimes. Ils auraient pu exécuter des transactions Payment pour vider les réserves, déclencher des opérations AccountSet ou TrustSet — en gros, des scénarios de « dépense sans clés ».

La réponse a été en fait impressionnante. Le réseau de validateurs XRPL a coordonné rapidement. Le 23 février, ils ont publié rippled 3.1.1, une version d’urgence marquant la fin de support pour Batch et fixBatchInnerSigs. Les validateurs ont reçu le signal pour voter « Non ». Une réinitialisation du devnet a été planifiée pour coïncider avec le déploiement. Aucun fonds perdu. Aucune activation. Le système de gouvernance a tenu bon.

Mais voici le truc — cela importe plus qu’il n’y paraît au premier abord. XRPL se positionne comme une infrastructure pour la finance régulée, la tokenisation d’actifs réels, et la DeFi institutionnelle. Ils ont environ $50 millions en DeFi verrouillés sur la plateforme et près de $2 milliards en actifs RWA. Ils déploient des Domaines Permissionnés, des DEXs sécurisés, des plateformes de trading vérifiées KYC. Une défaillance d’autorisation dans cette trajectoire aurait brisé tout leur récit de sécurité. En crypto, la perception reste longtemps après la correction technique.

L’équipe travaille déjà sur BatchV1_1 en tant que remplacement corrigé — supprime la sortie prématurée, ajoute des garde-fous d’autorisation plus stricts, limite la portée de la signature. Ils prévoient aussi des audits assistés par IA plus larges et de meilleures vérifications d’analyse statique pour repérer les motifs de boucle dangereux. C’est la bonne démarche.

Le vrai défi arrive maintenant : XRPL peut-il déployer cette version de remplacement en toute sécurité tout en conservant la marge de sécurité nécessaire pour l’adoption institutionnelle ? Ils essaient de construire une plateforme financière sophistiquée, et cela signifie que les aspects ennuyeux — validation des signataires, comportement des boucles, limites d’autorisation — deviennent cruciaux. Le résultat de février constitue une victoire de gouvernance. La question est de savoir s’ils pourront maintenir cette discipline à mesure qu’ils grandissent. À suivre de près pour voir comment cela évolue.