La XRP Ledger Foundation a publié une explication détaillée de la récente faille de sécurité, qui a suscité des inquiétudes quant à la possibilité que des XRP supplémentaires aient été créés et à savoir si la manière dont le problème a été corrigé avait compromis la décentralisation du réseau.
La Fondation affirme qu’aucun XRP supplémentaire n’a été créé.
Elle a également confirmé que la vulnérabilité avait été corrigée dans la version 3.4.1 et indiqué que l’offre actuelle reste d’environ 99,986 milliards de XRP.
L’annonce a rapidement alimenté un débat plus large sur la sécurité et la décentralisation du XRPL. L’avocat pro-Ripple Bill Morgan a répliqué aux critiques qui estimaient que la coordination confidentielle autour du correctif soulevait des inquiétudes quant à la centralisation.
La XRP Ledger Foundation affirme qu’aucun nouveau XRP n’a été créé
La Fondation a déclaré que l’offre de XRP avait été fixée à 100 milliards au lancement du registre et que le bug créait un moyen potentiel de contourner cette règle.
Il a toutefois souligné qu’aucun XRP supplémentaire n’avait été créé.
Comme les soldes du XRPL sont publics, tout nouveau jeton serait apparu sur la chaîne et aurait pu être suivi par les explorateurs et les plateformes de données.
La Fondation a déclaré qu’elle surveillait le registre en continu et avait vérifié que l’offre était restée intacte tout au long de l’histoire du réseau.
Le récent correctif de sécurité du XRP Ledger a soulevé de nombreuses questions et suscité quelques idées reçues. Clarifions tout cela. 1. Des XRP ont-ils été créés ? Non. L’offre de XRP a été fixée à 100 milliards au lancement du XRP Ledger, et aucune transaction ne peut en créer davantage. Ce bug permettait de contourner cette règle, et la version 3.4.1 l’a corrigé il y a deux semaines. Vous n’avez pas besoin de nous croire sur parole. Toutes les données du registre sont publiques, et les explorateurs et sites de données les consultent chaque jour. De nouveaux XRP apparaîtraient dans les soldes des comptes, visibles par tous. Il n’existe aucun endroit caché où pourraient se trouver des XRP sur le XRP Ledger : tous les soldes sont publics. Nous surveillons le XRP Ledger 24 h/24 et 7 j/7 et avons vérifié l’offre sur toute l’histoire du registre. D’autres membres de la communauté l’ont également vérifiée, et chacun peut faire de même. Les frais de transaction sont détruits, ce qui rend l’offre déflationniste. Il existe aujourd’hui environ 99,986 milliards de XRP. 2. Comment ce bug a-t-il pu passer inaperçu, et quelle est la suite ? Aucun paiement normal ne s’en approche, même de loin. Il fallait des centaines d’opérations conçues délibérément à cette fin. L’IA permet de trouver plus rapidement des bugs de ce type, aussi bien aux acteurs malveillants qu’aux acteurs bien intentionnés. Avec RippleX et la communauté, nous veillerons à ce que le XRP Ledger soit protégé contre de telles vulnérabilités. Cela implique de mettre en œuvre à grande échelle la vérification formelle et les tests adversariaux par IA, de collaborer étroitement avec des chercheurs en sécurité et de renforcer le programme de chasse aux bugs. Vous en entendrez beaucoup plus à ce sujet au fil de nos avancées. 3. La décentralisation du XRP Ledger est au cœur de cette question. Un correctif rendu public indique aux attaquants où se trouve le bug, et l’IA leur permet de le découvrir rapidement. Dans le cadre d’un vote d’amendement normal, le correctif aurait été public pendant des semaines avant son entrée en vigueur, ce qui aurait mis en péril la sécurité du réseau. En réaction, la communauté XRPL s’est rassemblée et, en son sein, la XRP Ledger Foundation, RippleX, les développeurs principaux et les validateurs ont formé un consensus social et convenu d’une voie à suivre consistant à déployer directement le correctif. Corriger un réseau en fonctionnement n’est jamais anodin ; le plan a donc également été conçu pour limiter au maximum les perturbations pour tous ceux qui l’utilisent. Nous avons transmis la version aux validateurs de l’UNL par défaut, en utilisant les coordonnées que chacun publie dans son fichier xrp-ledger.toml. Les binaires publics ont suivi le même jour, le 25 septembre. Aucune partie ne pouvait prendre cette décision seule. Chaque validateur et opérateur de nœud choisit le logiciel qu’il exécute, et la version 3.4.1 n’est devenue obligatoire qu’à la suite d’un vote d’amendement normal, après avoir recueilli le soutien de plus de 80 % des validateurs pendant deux semaines. Les changements de protocole passent toujours par des amendements. Un grand merci à Cayden Liao et Veria AI pour avoir découvert le problème et l’avoir signalé de manière responsable, aux développeurs principaux du XRPL pour avoir créé et testé le correctif, et à tous les opérateurs de nœuds qui ont effectué la mise à niveau si rapidement, en particulier les validateurs. Rapport complet : https://t.co/aWxdvthYPt
— XRP Ledger Foundation (@XRPLF) 11 octobre 2026
Elle a également souligné que les frais de transaction sont détruits, ce qui signifie que l’offre totale de XRP diminue progressivement au fil du temps.
Le bug lui-même était inhabituel.
La Fondation a indiqué qu’un paiement normal n’aurait pas pu déclencher le bug. Son exploitation aurait nécessité des centaines d’opérations conçues délibérément à cette fin.
C’est l’une des raisons pour lesquelles le problème est passé inaperçu aussi longtemps.
Pourquoi le correctif a été traité en privé
La partie la plus controversée de l’histoire concerne le déploiement du correctif.
La Fondation a expliqué que révéler publiquement la vulnérabilité avant que le correctif soit prêt aurait pu exposer le registre à des attaques.
L’IA facilitant l’analyse du code et la détection des faiblesses, le risque lié à la publication prématurée des détails a été jugé important.
La XRPL Foundation, RippleX, les développeurs principaux et les validateurs se sont donc coordonnés en privé avant de publier le correctif.
La version 3.4.1 a d’abord été communiquée aux validateurs de l’UNL par défaut, puis les binaires publics ont été publiés plus tard le même jour.
La Fondation a souligné qu’aucune partie ne pouvait imposer la mise à niveau.
La version n’est devenue obligatoire qu’après que le processus habituel d’amendement a obtenu le soutien de plus de 80 % des validateurs pendant deux semaines.
À l’avenir, le XRPL prévoit de développer la vérification formelle, les tests adversariaux par IA, la collaboration en matière de recherche sur la sécurité et son programme de chasse aux bugs.
À lire aussi : voici où le cours du XRP pourrait se diriger cette semaine (du 12 au 18 octobre)
Bill Morgan réfute les accusations de centralisation
Bill Morgan a adopté un ton beaucoup plus ferme.
Il a déclaré en avoir assez des critiques qui se servent du bug et de la manière dont il a été corrigé comme preuve que le XRPL est centralisé.
J’en ai très vite eu assez d’entendre des acteurs malveillants qui détestent le XRPL parler du bug qui aurait pu entraîner la création de XRP, ainsi que de la manière dont le problème a été corrigé, pour remettre en question la décentralisation du XRPL. On peut replacer cela dans le contexte d’une campagne menée depuis une décennie par des personnes extérieures à la communauté XRP pour attaquer les garanties de décentralisation du XRPL. Mais je voudrais retourner la question et demander ce que cela révèle de la définition de la décentralisation défendue par ces critiques. Si, pour eux, la décentralisation signifie que les personnes compétentes d’une communauté ne peuvent pas se réunir en privé pour corriger un bug grave susceptible d’endommager le registre, parce que rendre le problème public avant de l’avoir corrigé donnerait aux acteurs malveillants l’occasion d’exploiter la vulnérabilité, alors quelle est leur définition de la décentralisation ? Cela ne peut pas être l’anarchie ou le chaos. Cela n’attirera aucun investisseur, particulier ou institutionnel. Quoi qu’il en soit, à mon avis, la manière dont le problème a été résolu n’a rien à voir avec la notion de décentralisation. Elle relève de la question de la sécurité par rapport à la divulgation. La solution a été rendue publique après sa mise en œuvre. Elle n’a pas été dissimulée. Des personnes compétentes et de bonne foi ont corrigé le problème avant que des acteurs malveillants puissent l’exploiter. Où est le problème ?
— bill morgan (@Belisarius2020) 12 octobre 2026
Morgan a soutenu que la situation devait plutôt être considérée comme une question de sécurité par rapport à la divulgation.
Son argument est simple : si les membres compétents d’une communauté décentralisée ne peuvent pas se coordonner en privé pour corriger une vulnérabilité dangereuse avant que des attaquants puissent l’exploiter, alors la définition de la décentralisation retenue est irréaliste.
Il a également souligné que le correctif avait été rendu public après son déploiement et qu’il n’avait pas été dissimulé de façon permanente.
Cette distinction est importante.
Une coordination privée autour d’un correctif de sécurité d’urgence ne signifie pas automatiquement qu’une seule entité contrôle le réseau.
Le meilleur critère consiste à déterminer si une seule partie pourrait imposer des changements au protocole de manière unilatérale.
Dans ce cas, les validateurs devaient tout de même adopter le logiciel, et le processus d’amendement devait toujours recueillir plus de 80 % de soutien.
Pour plus d’actualités sur les cryptomonnaies et de prévisions de cours, cliquez ici.
Abonnez-vous à notre chaîne YouTube pour recevoir des actualités quotidiennes sur les cryptomonnaies, des analyses de marché et des commentaires d’experts.
L’article Un avocat pro-Ripple réplique après qu’un bug du XRP Ledger alimente les accusations de centralisation est paru en premier sur CaptainAltcoin.