L'amendement PermissionDelegationV1_1 du XRP Ledger est désormais actif sur le mainnet, selon le suivi des amendements XRPL, qui enregistre l'entrée en vigueur de la fonctionnalité le 8 octobre au ledger 107,524,865. L'amendement a achevé sa période d'approbation par les validateurs fin septembre, et ce processus a désormais produit un outil de contrôle de compte opérationnel sur le ledger. Dans le cadre du processus d'amendement de XRPL, les fonctionnalités n'atteignent le mainnet qu'après leur approbation par consensus des validateurs, ce qui fait de cette activation le moment où l'outil devient disponible pour un usage en production.

L'activation rend la délégation de permissions disponible pour les institutions, bien qu'aucune banque, émetteur de stablecoin ni gestionnaire de fonds n'ait publiquement confirmé de mise en œuvre à ce jour. Les entreprises peuvent désormais construire ces structures de permissions directement sur XRPL, tandis que les détails pratiques relèvent de la responsabilité de leurs fournisseurs de portefeuilles, dépositaires et équipes de sécurité internes. Le besoin auquel répond l'amendement est de longue date dans les opérations institutionnelles d'actifs numériques, où l'autorité de signature pour les transactions courantes est généralement séparée des identifiants maîtres qui contrôlent une trésorerie. La délégation de permissions déplace une partie de cette séparation sur le ledger lui-même plutôt que de la laisser entièrement à des logiciels externes.

Un émetteur de stablecoin peut répartir le travail courant entre plusieurs comptes

Un émetteur de stablecoin, par exemple, peut avoir besoin qu'une équipe approuve les clients éligibles et qu'une autre traite les transferts courants. Selon le nouveau modèle, le compte principal de l'émetteur peut rester sous une garde plus stricte, tandis qu'un compte de conformité reçoit l'autorité d'approuver les lignes de confiance après les vérifications KYC et qu'un compte d'opérations obtient l'autorité de paiement. Chaque compte ne détient que le rôle qui lui est assigné, limitant ainsi les dégâts qu'une clé quotidienne compromise pourrait causer.

Une entreprise pourrait répartir les tâches de portefeuille comme suit :

• Compte principal : Crée, modifie ou révoque les rôles délégués tandis que sa clé reste sous une garde renforcée.
• Compte de conformité : Reçoit l'autorité pour une tâche définie d'approbation de clients.
• Compte d'opérations : Reçoit l'autorité de soumettre une catégorie approuvée de transactions, telle qu'un paiement.

XRPL enregistre chaque attribution dans une entrée Delegate du ledger. Le compte recevant l'attribution signe avec propres identifiants et paie les frais de transaction depuis son propre solde, tandis que l'action autorisée prend effet pour le compte principal. La documentation de XRPL décrit ce dispositif comme un contrôle d'accès basé sur les rôles pouvant fonctionner conjointement avec la multi-signature.

Les limites de l'autorité déléguée

Une entreprise peut accorder une autorité sur des types de transactions particuliers ou des fonctions granulaires prédéfinies. Chaque délégué peut détenir jusqu'à 10 permissions, et le compte principal peut les mettre à jour ou les révoquer via une autre transaction DelegateSet.

Certains pouvoirs restent exclusivement détenus par le compte principal. Un délégué ne peut pas modifier ses clés cryptographiques, créer d'autres délégations ni soumettre une transaction en dehors des permissions qui lui ont été accordées. Chaque délégation crée également un objet on-ledger qui compte dans le reserve requirement du compte principal.

L'ensemble de permissions n'inclut aucune fonction de politique de paiement personnalisée. Une entreprise ne peut pas utiliser seule la délégation de permissions pour appliquer des règles telles que « paiements inférieurs à 10 000 $ uniquement » ou « transferts uniquement vers ces adresses ». Ces contrôles relèvent toujours des logiciels de portefeuille, des flux d'approbation ou des systèmes de conformité.

Les permissions du ledger et les décisions de conformité restent distinctes

La délégation de permissions détermine uniquement quel compte soumet une action XRPL approuvée, rien de plus. Les vérifications KYC, le filtrage des sanctions, les registres d'investisseurs, les documents de fonds et la responsabilité juridique restent du ressort de l'émetteur et de ses prestataires de services. L'amendement répartit l'autorité technique ; il n'automatise pas la décision de conformité sous-jacente.

Le pilote de registre de fonds de XRPL avec le CSD BR brésilien suit un principe similaire : le ledger peut prendre en charge un flux de travail contrôlé tandis que l'infrastructure de marché établie reste responsable du registre officiel de propriété. La délégation de permissions pourrait offrir aux projets utilisant ce modèle davantage de flexibilité quant au compte qui exécute chaque action autorisée sur le ledger.

Une permission déléguée fait l'objet d'un avertissement publié

La documentation de XRPL déconseille aux entreprises de déléguer la permission granulaire PaymentBurn tant qu'un amendement distinct, fixCleanup3_4_0, n'est pas actif. Jusqu'à l'arrivée de ce correctif, la documentation indique qu'un délégué détenant l'autorité PaymentBurn pourrait également émettre des tokens fongibles dans certaines circonstances. Les autres permissions granulaires ne sont pas concernées.

L'avertissement concerne une seule permission plutôt que l'amendement dans son ensemble, mais il illustre pourquoi les émetteurs doivent examiner chaque rôle délégué avant de déplacer des fonctions courantes vers des comptes en ligne distincts.

Ce que les entreprises peuvent faire avec la nouvelle fonctionnalité

La délégation de permissions offre aux émetteurs XRPL un moyen de répartir les responsabilités entre plusieurs portefeuilles sans partager les identifiants qui contrôlent leur compte principal. Sa valeur pratique dépendra des politiques construites autour d'elle : quelles tâches sont déléguées, la rapidité avec laquelle les permissions peuvent être révoquées, et si les fournisseurs de portefeuilles transforment cette fonctionnalité de protocole en un système de contrôle d'entreprise exploitable. Les signaux à court terme sont observables plutôt que spéculatifs : l'ajout de prise en charge des nouvelles transactions et entrées de délégation du ledger par les fournisseurs de portefeuilles et de garde, et l'activation de fixCleanup3_4_0 — la condition fixée par la documentation de XRPL avant que PaymentBurn puisse être délégué.

Cet article est fourni à titre informatif uniquement et ne constitue pas conseil juridique, financier ou d'investissement. Les entreprises doivent consulter la documentation technique actuelle de XRPL et leurs propres politiques de sécurité avant d'utiliser les permissions déléguées.