XRP Ledger a fait passer 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 la mise à niveau des permissions de compte.
Résumé
- PermissionDelegationV1_1 pourrait s'activer le 5 octobre si le soutien des validateurs reste au-dessus du seuil requis de 80 %.
- La mise à niveau permet aux comptes XRPL de déléguer des permissions spécifiques sans donner à un autre compte le contrôle total de leurs clés.
- La délégation de permissions ne modifie pas directement l'offre ou la tokenomique du XRP, ce qui rend tout impact sur le prix largement dépendant de l'adoption et de l'activité du réseau.
Selon le tableau de bord en direct des amendements du XRP Ledger, le compte à rebours a commencé le 21 septembre et pourrait mettre PermissionDelegationV1_1 en vigueur le 5 octobre à 11:18 UTC si le soutien des validateurs reste au-dessus du seuil requis tout au long de 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 divise l'autorité des comptes du XRP Ledger
PermissionDelegationV1_1 modifie la façon dont un compte XRP Ledger peut donner à un autre compte l'autorité d'effectuer des tâches spécifiques.
Dans la structure de compte actuelle, 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 de donner à un compte opérationnel plus d'autorité qu'il n'en a réellement besoin. La délégation de permissions est conçue 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 garder ses clés principales hors ligne tout en donnant à un système de conformité connecté à Internet la permission d'approuver les clients pour détenir son token.
Chaque compte délégué peut recevoir jusqu'à 10 permissions, tandis que le compte accordant l'autorité conserve la capacité de les modifier ou de les révoquer.
L'arrangement 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 groupe plus large d'amendements introduits via xrpld 3.3.0. La version incluait BatchV1_1, ConfidentialTransfer, DynamicMPT et Sponsor aux côtés de la délégation de permissions, 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 pour les utilisateurs sans contrôler leurs comptes. DynamicMPT donne aux émetteurs plus de flexibilité sur certaines propriétés des Multi Purpose Tokens sélectionnées, tandis que ConfidentialTransfer est conçu pour dissimuler les soldes MPT et les montants des paiements au public tout en conservant des mécanismes d'accès pour les parties autorisées.
Crypto.news a précédemment rapporté que ConfidentialTransfer cible les cas d'usage institutionnels où les entreprises peuvent avoir besoin de confidentialité des transactions tout en fournissant des informations aux auditeurs et autres parties autorisées.
La délégation de permissions revient après une faille de sécurité antérieure
PermissionDelegationV1_1 est la deuxième tentative d'apporter des permissions de compte déléguées au XRP Ledger.
L'amendement original a été arrêté 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 affectée, le logiciel vérifiait si un compte avait la permission d'effectuer une transaction avant de vérifier correctement sa signature. Certaines transactions rejetées pouvaient encore entraîner des frais.
Un attaquant aurait donc pu soumettre des transactions non autorisées comportant des frais délibérément élevés et faire payer un autre compte même si les transactions n'étaient pas correctement signées. La répétition du processus aurait pu épuiser le solde XRP disponible 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 la version affectée de s'activer sur le mainnet.
Le remplacement a été inclus dans xrpld 3.3.0 avec des modifications dans la façon dont les transactions non autorisées sont traitées. La vérification de la signature a désormais lieu avant le type d'échec qui pourrait facturer le compte ciblé.
La délégation de permissions n'est pas la seule fonctionnalité de la version à faire son retour après le travail 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é de signature critique distincte. La mise à niveau de Batch révisée a progressé à travers le vote des validateurs après des correctifs et un examen plus approfondi.
PermissionDelegationV1_1 pourrait-elle affecter le prix du XRP ?
PermissionDelegationV1_1 ne modifie pas directement l'offre, le calendrier d'émission ou l'économie du jeton XRP, ne laissant aucune raison mécanique pour que sa seule activation crée une demande nouvelle substantielle pour le XRP.
L'amendement concerne les permissions de compte plutôt que le jeton XRP lui-même. Les institutions utilisant des comptes délégués utiliseraient toujours le XRP pour les frais normaux du registre et les exigences de réserve, mais la 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 du XRPL et la demande de XRP est importante.
Une analyse précédente de l'exposition au XRP de Ripple Prime a révélé que même une activité institutionnelle substantielle au sein de l'écosystème de Ripple ne se traduit pas automatiquement par une demande équivalente de XRP. Les stablecoins et autres actifs émis peuvent gérer 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 de routage.
Une structure similaire s'applique à la délégation de permissions. Les émetteurs de stablecoins, les fournisseurs d'actifs tokenisés et d'autres entreprises pourraient utiliser la fonctionnalité sans faire du XRP l'actif transféré.
Le lien possible avec le prix dépend plutôt de la question de savoir si la mise à niveau contribue à apporter plus d'activité au XRP Ledger au fil du temps.
Les émetteurs institutionnels qui souhaitent garder les clés de haute autorité hors ligne 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 le XRPL, l'activité résultante créerait une utilisation accrue du réseau, où le XRP reste l'actif natif utilisé pour les frais et les réserves.
Les preuves jusqu'à présent suggèrent que la croissance du réseau et le prix du XRP n'évoluent pas toujours ensemble. Le RLUSD et les actifs tokenisés se sont développés sur le XRPL tandis que le XRP a connu des périodes de faiblesse des prix, montrant que l'augmentation de l'activité du registre ne produit pas nécessairement une pression d'achat immédiate pour le jeton.
Un test institutionnel de juin impliquant JPMorgan, Mastercard, Ondo Finance et Ripple a fourni un autre exemple. Le rachat de Treasury tokenisé utilisait le 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 fournir une pièce d'infrastructure supplémentaire pour les utilisateurs institutionnels sans devenir un catalyseur majeur autonome pour le 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'utilisation ultérieure de la fonctionnalité et d'autres facteurs de marché plutôt que du simple déclenchement de l'amendement.
Le XRP Ledger développe davantage d'outils pour les transactions institutionnelles
La délégation de permissions progresse vers son activation tandis que plusieurs autres fonctionnalités du XRP Ledger restent à différents stades du processus d'amendement.
BatchV1_1 est conçu pour regrouper plusieurs opérations en 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 en même temps.
ConfidentialTransfer donnerait aux émetteurs de Multi Purpose Token la possibilité de dissimuler 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 de la conception proposée.
Les développeurs du 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 aux fonctions de prêt proposées aux côtés d'un autre ensemble de correctifs de protocole.
Le cadre de prêt reste soumis au processus d'amendement du réseau, avec l'approbation des validateurs requise avant que les fonctions proposées puissent devenir actives sur le mainnet.
