XRP Ledger : deux correctifs proposés resserrent les autorisations sur les jetons restreints

L’autorisation doit suivre les actifs d’un pool

Les développeurs du XRP Ledger examinent des changements visant à mieux faire respecter les autorisations imposées par les émetteurs de certains jetons. Deux demandes de modification ouvertes dans le dépôt rippled, numérotées 8648 et 8650, traitent des chemins permettant à un compte de recevoir une exposition sans l’accord attendu. Le dossier a été repris dans l’actualité du 30 octobre 2026, mais ses textes techniques sont antérieurs. Il s’agit de code proposé et discuté, pas d’une annonce démontrant qu’une nouvelle règle est déjà active sur le réseau principal.

La première modification concerne les jetons représentant une participation dans un pool automatisé. Une telle participation donne une exposition aux deux actifs du pool. Le contrôle effectué lors d’un dépôt initial ne suffit pas si ce jeton de participation peut ensuite changer de détenteur par d’autres chemins. Le texte décrit notamment des paiements, des offres et certains remboursements. L’objectif du correctif est d’exiger les autorisations nécessaires sur les deux actifs au moment où un compte acquiert cette participation, et non uniquement lorsqu’il apporte directement de la liquidité.

Une position existante ne doit pas contourner le contrôle

La seconde modification vise un autre cas : le contrôle d’autorisation d’un paiement ne se déclenchait, dans le chemin décrit, que lorsque le solde de la ligne de confiance était exactement nul. Un compte possédant déjà un solde pouvait alors recevoir davantage sans satisfaire la règle attendue. Le correctif proposé cherche à fermer cette exception. Cette description concerne le fonctionnement des actifs émis avec restriction ; elle ne signifie pas que tout paiement en XRP natif doit désormais être approuvé par un émetteur de jetons.

Les deux changements sont regroupés sous le nom d’amendement technique fixCleanup3_5_0 dans leur présentation. Le dépôt précise que la proposition initiale a été découpée pour faciliter l’examen. Deux couches supplémentaires, consacrées à la gestion des soldes et à une règle de cohérence, ont été fermées après revue. Présenter encore ce dossier comme quatre demandes toutes ouvertes ne correspondrait donc pas à l’état décrit par les documents primaires consultés. Une fermeture doit elle-même être interprétée dans le contexte de l’examen, sans l’assimiler automatiquement à une mise en production.

Proposer, intégrer et activer sont des étapes distinctes

Le statut d’une demande de modification indique l’avancement de son intégration dans le logiciel. Il ne suffit pas, à lui seul, à établir le comportement du réseau utilisé par les détenteurs. Une modification retenue doit encore suivre le parcours de déploiement et d’activation applicable. Les textes examinés ne permettent donc pas de demander aux lecteurs de considérer ces contrôles comme déjà généralisés. Pour documenter un changement effectif, il faudra rapprocher le code retenu, la version distribuée et l’état réel de l’amendement.

Pour les applications utilisant des actifs restreints, l’enjeu est la cohérence des autorisations entre plusieurs types d’opérations. Les effets recherchés portent sur l’acquisition d’une exposition et sur la réception de nouveaux soldes, avec des cas de sortie traités séparément dans les propositions. Ce travail ne constitue pas, par sa seule existence, la preuve d’un vol ou d’utilisateurs lésés. La lecture utile reste celle des chemins techniques corrigés et de leur statut vérifié, sans transformer un durcissement proposé en incident confirmé ou en règle déjà entrée en vigueur.