L'XRP Ledger approche d'une seconde échéance pour activer une correction de sécurité conçue pour combler une faille de création de tokens aux implications potentielles pour la sécurité des stablecoins du réseau. L'amendement, connu sous le nom de fixCleanup3_4_0, devrait s'activer le 4 novembre, après un premier retard causé par la baisse du soutien des validateurs.

Nothing fancy here but happy this fixCleanup amendment is going live on the XRP Ledger in the next 48h! Hardening and improving the XRP protocol. pic.twitter.com/XAzbFW4rPY

— Vet (@Vet_X0), 2 novembre 2026

L'amendement bénéficie actuellement du soutien de 33 des 35 validateurs de confiance du registre, dépassant confortablement le seuil requis pour maintenir l'activation. Le soutien doit toutefois rester à ce niveau de manière continue pendant 14 jours, et une nouvelle baisse sous le seuil pourrait de nouveau repousser l'échéance. Le décompte des votes en direct est consultable publiquement sur la page XRPSCAN de l'amendement, offrant aux émetteurs et aux développeurs une vue directe de l'état du compte à rebours.

Cette correction est particulièrement pertinente pour la sécurité des stablecoins car elle concerne les permissions utilisées pour détruire des tokens émis. Dans certaines conditions, un compte autorisé uniquement à détruire des tokens — c'est-à-dire chargé uniquement de retirer des tokens de la circulation — pourrait également en créer de nouveaux, augmentant l'offre sans autorisation.

Seconde échéance d'activation

L'amendement visait initialement le 23 octobre comme date d'activation, mais le soutien des validateurs est brièvement tombé à 26 sur 35 le 21 octobre. Ce chiffre était inférieur aux 29 voix requises pour maintenir le seuil d'approbation, réinitialisant le compte à rebours d'activation de deux semaines.

Le soutien est revenu au niveau requis plus tard dans la journée, relançant le compteur et repoussant la date d'activation la plus proche au 4 novembre. L'amendement compte désormais 33 validateurs en faveur, soit une marge de quatre voix au-dessus du minimum — l'équivalent d'au moins 29 voix selon la règle des 80 % du registre.

XRP LEDGER BIG UPDATE XRPL bug fix is delayed until November 4. It closes a loophole that could let burn only accounts create new tokens. Will this delay affect confidence in $XRP, even as ETFs have attracted $1.8 billion in net inflows since launch? pic.twitter.com/hgzHkyQvXV

— TMA | The Money Ape (@TheMoneyApe), 22 octobre 2026

Selon le processus d'amendement de l'XRP Ledger, les modifications au niveau du protocole doivent maintenir le soutien de plus de 80 % des validateurs de confiance pendant 14 jours consécutifs avant de pouvoir s'activer. Les validateurs de confiance sont les opérateurs de serveurs qui pilotent le consensus du registre, et leurs décisions individuelles de soutien déterminent donc directement quand les mises à niveau du protocole entrent en vigueur. Le réseau vérifie le soutien à intervalles réguliers, ce qui signifie qu'une baisse même temporaire peut réinitialiser le compte à rebours. Les amendements n'expirent pas lorsque le soutien faiblit ; une modification attend simplement qu'assez de validateurs la soutiennent pendant toute la période de deux semaines.

L'estimation actuelle d'activation est le 4 novembre à 14h46 UTC, sur la base du compteur de soutien relancé le 21 octobre. Cette date reste conditionnelle jusqu'à ce que l'amendement soit formellement activé sur le réseau.

Pourquoi cette correction est importante pour la sécurité des stablecoins

La vulnérabilité concerne la permission PaymentBurn déléguée du XRPL, qui permet à un compte de détruire des tokens fongibles ou des Multi-Purpose Tokens au nom d'un émetteur. Les permissions déléguées permettent aux émetteurs de confier des opérations spécifiques sur les tokens, comme la destruction, à des comptes externes ou des prestataires de services. Dans certaines circonstances, cette même permission pourrait également permettre à un délégataire de créer de nouveaux tokens sans disposer de l'autorisation nécessaire. L'amendement est conçu pour établir une séparation plus claire entre la destruction et l'émission de tokens.

Contrairement au XRP lui-même, tous les autres tokens du registre sont des actifs émis, liés aux comptes émetteurs par des lignes de confiance qui déterminent qui peut les détenir et les transférer. C'est important pour les stablecoins car les émetteurs peuvent dépendre de services tiers pour détruire des tokens lorsque les clients les échangent contre des monnaies fiduciaires, et ces services ne devraient pas pouvoir créer de tokens supplémentaires sans l'autorisation de l'émetteur. Une émission non autorisée pourrait miner la confiance dans les contrôles d'offre d'un token, en particulier pour les actifs conçus pour maintenir une valeur fixe adossée à des réserves.

La documentation officielle du XRPL met en garde les développeurs contre la délégation de PaymentBurn jusqu'à l'activation de la correction. Cette mise en garde est liée au calendrier d'activation, si bien que tout nouveau retard au-delà du 4 novembre prolongerait la période pendant laquelle l'avertissement de la documentation reste en vigueur.

Le RLUSD de Ripple, un stablecoin adossé au dollar américain, fonctionne à la fois sur l'XRP Ledger et sur Ethereum, ce qui rend les contrôles de tokens du XRPL pertinents pour l'écosystème des stablecoins du réseau. Cependant, aucun élément public n'indique que le RLUSD ait été affecté par la faille ou que ses réserves aient été compromises.

L'amendement fait partie d'un ensemble plus large de corrections techniques couvrant les permissions de tokens, les teneurs de marché automatisés, les coffres, les calculs de prêt, l'escrow et d'autres fonctions du registre. Il n'active pas à lui seul le protocole de prêt proposé par le XRPL, qui demeure une proposition distincte nécessitant sa propre approbation par les validateurs.

Si l'amendement s'active comme prévu, il combinera la faille de permission et renforcera les garanties autour des actifs émis sur le registre. Toutefois, une nouvelle baisse du soutien des validateurs pourrait de nouveau retarder la mise à niveau et laisser le réseau attendre sa prochaine fenêtre d'activation.