La documentation officielle du XRP Ledger (XRPL) recommande aux détenteurs de comptes de ne pas déléguer la permission PaymentBurn tant qu'un amendement appelé fixCleanup3_4_0 n'est pas activé sur le réseau. L'avertissement porte sur une faille située à la frontière entre la destruction et l'émission de tokens — une faille qui, dans certaines circonstances, permettait à un délégué disposant uniquement de PaymentBurn d'émettre de nouveaux tokens au lieu de les détruire. La faille ne peut pas créer de nouveaux XRP elle-même, mais elle touche précisément la tâche que la délégation de permissions était censée conserver derrière des clés hors ligne.

Le rôle prévu d'un délégué limité à la destruction

La délégation de permissions permet à un compte de confier des tâches spécifiques à un second compte, qui signe avec ses propres clés. La documentation XRPL est explicite sur cet objectif : les tâches courantes s'exécutent avec des clés maintenues en ligne, tandis que les clés à contrôle total restent hors ligne pour des tâches spéciales telles que l'émission de tokens. Le guide de Coindoo sur les contrôles de comptes délégués du XRPL explique comment les institutions peuvent répartir ces rôles.

Deux des douze permissions granulaires du registre concernent l'offre de tokens. PaymentMint couvre les paiements qui créent des tokens fongibles ou des Multi-Purpose Tokens (MPT). PaymentBurn couvre les paiements qui les détruisent, et la documentation fixe précisément sa limite : la destruction s'arrête à un solde zéro.

La faille se situe précisément à cette limite. Avant le correctif, un paiement envoyé sous PaymentBurn pouvait, dans certaines circonstances, dépasser zéro et émettre de nouveaux trust-line tokens ou MPT. fixCleanup3_4_0 rejette tout paiement délégué limité à la destruction dont le montant franchirait le seuil de l'émission, à moins que le même délégué ne détienne également PaymentMint. Les onze autres permissions granulaires ne sont pas affectées.

Cela rend le bug limité en portée mais dérangeant par ce qu'il touche. Seul un compte qu'un émetteur a déjà désigné comme délégué peut l'exploiter, mais ce qu'il déverrouille est l'émission — la tâche même que la délégation était censée garder derrière des clés hors ligne.

Le stockage à froid ne couvre pas les clés d'un délégué

Les transactions déléguées sont signées avec la clé maître du délégué, sa clé régulière ou sa liste multi-signatures. Un émetteur peut conserver ses identifiants principaux entièrement hors ligne et rester exposé si un délégué détenant PaymentBurn est compromis, mal configuré ou agit au-delà de son mandat.

Pour un token adossé à une monnaie fiduciaire, le risque économique réside dans des unités en circulation sans réserves correspondantes. Une attestation de réserves montre les actifs détenus en regard des tokens en circulation à une date de reporting donnée. Elle ne dit rien sur les comptes susceptibles de modifier ce chiffre entre les rapports — et c'est précisément le contrôle que cette faille affaiblit.

La délégation lancée avant que son correctif ne recueille les votes

Il s'agit de la deuxième faille découverte dans la fonctionnalité de délégation du XRPL. La version initiale avait été retirée en 2025 après qu'un testeur de la communauté eut découvert sur devnet qu'elle pouvait facturer des frais de transaction à des comptes n'ayant pas signé, et la divulgation officielle confirme qu'elle n'a jamais atteint le Mainnet. Son remplacement, PermissionDelegationV1_1, a été activé le 8 octobre, selon le tableau de bord des amendements du XRPL, tandis que la correction de PaymentBurn recueillait encore le soutien des validateurs.

L'exposition est donc évaluée compte par compte : seuls les émetteurs ayant accordé PaymentBurn depuis le lancement sont concernés. Chaque autorisation est publique, car les entrées Delegate du registre enregistrent le compte accordant l'autorisation, le délégué et sa liste de permissions. Au moment de la rédaction, ni la documentation XRPL ni les reportages publiés n'identifient d'émetteur affecté ni d'usage malveillant.

Une augmentation de l'offre à elle seule ne prouverait rien, car un émetteur peut avoir accordé PaymentMint délibérément. Ce qu'il faudrait expliquer, c'est un délégué ne détenant que PaymentBurn dont les paiements auraient ajouté des tokens.

Ce que les émetteurs peuvent vérifier avant mercredi

Les conseils publiés par le XRPL sont de cesser de déléguer PaymentBurn tant que le correctif n'est pas activé. Pour les émetteurs qui l'ont déjà accordé, le travail s'effectue dans cet ordre :

1. Extraire chaque entrée Delegate du compte émetteur et signaler toute liste de permissions contenant PaymentBurn.
2. Renvoyer DelegateSet avec la liste complète des permissions à conserver. Une nouvelle liste remplace l'ancienne, donc tout ce qui en est omis est supprimé.
3. Considérer une autorisation comme révoquée uniquement lorsque la modification apparaît dans un registre validé.
4. Auditer séparément les paiements passés du délégué, car la révocation de l'autorisation empêche toute utilisation future sans annuler les transactions antérieures.
5. Déléguer à nouveau PaymentBurn uniquement après que fixCleanup3_4_0 apparaît comme activé sur le Mainnet.

Pourquoi le vote peut encore glisser

Selon les règles officielles des amendements, une modification nécessite une supermajorité de validateurs de confiance maintenue pendant deux semaines ininterrompues. Avec 35 validateurs dans l'ensemble suivi, ce seuil est de 29, et passer en dessous réinitialise le compteur. Cette réinitialisation s'est déjà produite une fois ; le soutien s'élève actuellement à 33 des 35 validateurs de confiance en faveur du correctif.

Même avec un soutien intact, 14:46 UTC marque l'ouverture de la fenêtre de deux semaines. L'activation se produit à un point de contrôle de vote du registre, de sorte que la modification peut prendre effet quelque temps après.

Les validateurs votent également sur bien plus que cette seule correction. fixCleanup3_4_0 regroupe 25 changements couvrant les coffres (vaults), les prêts, les teneurs de marché automatisés, les NFT, l'escrow et le sponsoring, et le correctif PaymentBurn est le dernier élément de sa liste. Il corrige le code de prêt sans activer le Lending Protocol lui-même, qui fait l'objet de son propre amendement encore soumis au vote.

Pour les émetteurs, la confirmation qui compte est l'inscription de fixCleanup3_4_0 comme activé sur le Mainnet. D'ici là, une autorisation PaymentBurn confère davantage de pouvoir que son nom ne l'indique.

Cet article est initialement paru sur Coindoo.