XRP Ledger a fait entrer PermissionDelegationV1_1 dans sa période d’activation de 14 jours après que 29 des 35 validateurs de confiance du réseau ont soutenu cette mise à niveau des permissions de compte.
Selon le tableau de bord en direct des amendements de XRP Ledger, le compte à rebours a commencé le 21 septembre et pourrait faire entrer PermissionDelegationV1_1 en vigueur le 5 octobre à 11h18 UTC si le soutien des validateurs reste au-dessus du seuil requis pendant toute la période.
Au moins 28 des 35 validateurs de confiance doivent continuer à soutenir l’amendement. Si le soutien tombe en dessous de ce niveau avant la fin du compte à rebours, le minuteur d’activation sera réinitialisé.
PermissionDelegationV1_1 modifie la manière dont un compte XRP Ledger peut accorder à un autre compte l’autorité d’exécuter des tâches spécifiques.
Dans la structure actuelle des comptes, les entreprises qui ont besoin de différents systèmes ou employés pour effectuer des opérations peuvent être confrontées au problème consistant à donner à un compte opérationnel plus d’autorité qu’il n’en a réellement besoin. Permission Delegation est conçu pour séparer ces responsabilités.
Un compte pourrait, par exemple, autoriser un autre compte à effectuer des paiements sans lui donner la permission de modifier les clés du compte principal. Un émetteur de stablecoin pourrait conserver ses clés principales hors ligne tout en donnant à un système de conformité connecté à Internet la permission d’approuver les clients autorisés à détenir son token.
Chaque compte délégué peut recevoir jusqu’à 10 permissions, tandis que le compte qui accorde l’autorité conserve la capacité de les modifier ou de les révoquer.
Cette organisation ressemble à la séparation des responsabilités couramment utilisée par les institutions financières, où les fonctions de paiement, de conformité et d’administration ne partagent pas nécessairement le même niveau d’accès.
PermissionDelegationV1_1 fait partie d’un ensemble plus large d’amendements introduits via xrpld 3.3.0. La version incluait BatchV1_1, ConfidentialTransfer, DynamicMPT et Sponsor en plus de Permission Delegation, plusieurs de ces fonctionnalités étant orientées vers les transactions institutionnelles et l’émission de tokens.
Sponsor permettrait à une autre entité de couvrir les frais de transaction et les exigences de réserve des utilisateurs sans contrôler leurs comptes. DynamicMPT offre aux émetteurs davantage de flexibilité sur certaines propriétés des Multi Purpose Tokens, tandis que ConfidentialTransfer est conçu pour masquer aux yeux du public les soldes de MPT et les montants des paiements, tout en conservant des mécanismes d’accès pour les parties autorisées.
Crypto.news avait précédemment rapporté que ConfidentialTransfer cible des cas d’usage institutionnels où les entreprises peuvent avoir besoin de confidentialité des transactions tout en continuant à fournir des informations aux auditeurs et à d’autres parties autorisées.
PermissionDelegationV1_1 constitue la deuxième tentative d’introduire des permissions de compte déléguées sur XRP Ledger.
L’amendement d’origine a été stoppé avant d’atteindre le réseau principal après qu’un testeur de la communauté a signalé une vulnérabilité le 15 septembre 2025.
Dans l’implémentation concernée, le logiciel vérifiait si un compte avait l’autorisation d’effectuer une transaction avant de valider correctement sa signature. Certaines transactions rejetées pouvaient tout de même entraîner des frais.
Un attaquant aurait donc pu soumettre des transactions non autorisées avec des frais volontairement élevés et faire en sorte qu’un autre compte les paie, même si les transactions n’étaient pas correctement signées. En répétant le processus, il aurait pu épuiser le solde disponible en XRP de la victime.
Il a été conseillé aux validateurs de ne pas soutenir l’amendement après la découverte de la vulnérabilité, empêchant ainsi la version concernée d’être activée sur le mainnet.
La version de remplacement a été incluse dans xrpld 3.3.0 avec des modifications dans la manière dont les transactions non autorisées sont traitées. La vérification des signatures a désormais lieu avant le type d’échec qui pourrait facturer le compte visé.
Permission Delegation n’est pas la seule fonctionnalité de cette version à revenir après des travaux de sécurité. BatchV1_1 a remplacé une implémentation antérieure de Batch après que les développeurs ont découvert une vulnérabilité critique distincte liée à la signature. La version révisée de Batch a progressé dans le vote des validateurs après les correctifs et un examen supplémentaire.
PermissionDelegationV1_1 ne modifie pas directement l’offre de XRP, son calendrier d’émission ou son économie de token, ce qui signifie qu’il n’existe aucune raison mécanique pour que son activation, à elle seule, crée une nouvelle demande substantielle de XRP.
L’amendement concerne les permissions des comptes plutôt que le token XRP lui-même. Les institutions utilisant des comptes délégués continueraient d’utiliser le XRP pour les frais normaux du ledger et les exigences de réserve, mais cette fonctionnalité ne les oblige pas à acheter ou à détenir de grandes quantités de XRP simplement pour utiliser des permissions déléguées.
Les développements récents sur le réseau montrent pourquoi la distinction entre l’adoption de XRPL et la demande de XRP est importante.
Une analyse précédente de l’exposition de Ripple Prime au XRP a montré que même une activité institutionnelle importante au sein de l’écosystème Ripple ne se traduit pas automatiquement par une demande équivalente en XRP. Les stablecoins et autres actifs émis peuvent prendre en charge une grande partie du transfert de valeur sous-jacent, tandis que le XRP conserve des rôles incluant les frais de transaction, les réserves et certaines fonctions d’acheminement.
Une structure similaire s’applique à Permission Delegation. Les émetteurs de stablecoins, les fournisseurs d’actifs tokenisés et d’autres entreprises pourraient utiliser cette fonctionnalité sans faire du XRP l’actif transféré.
Le lien potentiel avec le prix dépend plutôt de la capacité de cette mise à niveau à apporter davantage d’activité à XRP Ledger au fil du temps.
Les émetteurs institutionnels qui souhaitent conserver hors ligne des clés à haute autorité pourraient utiliser des comptes délégués pour des paiements récurrents ou des tâches de conformité. Si ces capacités contribuent à ce que davantage d’entreprises émettent des actifs et traitent des transactions sur XRPL, l’activité qui en résulte générera davantage d’utilisation du réseau, où le XRP reste l’actif natif utilisé pour les frais et les réserves.
Les éléments observés jusqu’à présent suggèrent que la croissance du réseau et le prix du XRP n’évoluent pas toujours de concert. RLUSD et les actifs tokenisés se sont développés sur XRPL tandis que le XRP a connu des périodes de faiblesse des prix, montrant qu’une hausse de l’activité du ledger ne produit pas nécessairement une pression acheteuse immédiate sur le token.
Un test institutionnel mené en juin impliquant JPMorgan, Mastercard, Ondo Finance et Ripple a fourni un autre exemple. Le rachat d’un Treasury tokenisé utilisait XRP Ledger, mais le XRP n’était pas l’actif racheté. Son rôle direct restait lié à l’infrastructure réseau sous-jacente.
PermissionDelegationV1_1 pourrait donc apporter une nouvelle brique d’infrastructure pour les utilisateurs institutionnels sans devenir, à elle seule, un catalyseur majeur du prix du XRP.
Une réaction du marché autour de l’activation reste possible, car les traders peuvent réagir aux mises à niveau du réseau et aux attentes entourant l’adoption. Tout effet durable sur le prix dépendrait toutefois de l’usage ultérieur de cette fonctionnalité et d’autres facteurs de marché, plutôt que du simple fait que l’amendement soit activé.
Permission Delegation se rapproche de l’activation tandis que plusieurs autres fonctionnalités de XRP Ledger se trouvent encore à différents stades du processus d’amendement.
BatchV1_1 est conçu pour regrouper plusieurs opérations dans une transaction coordonnée, permettant à chaque action incluse de réussir ou d’échouer ensemble. Une telle structure peut prendre en charge des processus de règlement où un actif et son paiement doivent changer de mains simultanément.
ConfidentialTransfer donnerait aux émetteurs de Multi Purpose Tokens la possibilité de masquer les soldes et les montants des transferts tout en laissant les comptes visibles. Les parties autorisées pourraient toujours recevoir les informations nécessaires à la conformité dans le cadre du modèle proposé.
Les développeurs de XRPL ont poursuivi leur travail au-delà de la version 3.3.0. La version 3.4.0, publiée le 16 septembre, a introduit des révisions des fonctions de prêt proposées, ainsi qu’un autre ensemble de correctifs du protocole.
Le cadre de prêt reste soumis au processus d’amendement du réseau, l’approbation des validateurs étant requise avant que les fonctions proposées puissent devenir actives sur le mainnet.
XRP