Les développeurs du XRP Ledger ont publié la version 3.3.0 de xrpld le 6 août, rapprochant plusieurs modifications de protocole d'une éventuelle activation sur le réseau principal (mainnet).
La publication officielle sur GitHub confirme les travaux sur ConfidentialTransfer, BatchV1_1, Sponsor et DynamicMPT, ainsi que des correctifs et d'autres modifications de protocole. La publication du logiciel elle-même n'active pas ces fonctionnalités sur le réseau.
La distinction est importante car certains rapports décrivent six mises à niveau comme étant déjà actives. Dans le cadre du processus d'amendement du XRP Ledger, les nouvelles fonctionnalités du protocole nécessitent le soutien des validateurs avant leur activation. Un amendement doit maintenir plus de 80 % de soutien de la part des validateurs de confiance pendant deux semaines continues avant d'entrer en vigueur.
ConfidentialTransfer est conçu pour ajouter de la confidentialité aux jetons multi-usages (Multi-Purpose Tokens), ou MPT. La documentation de XRPL indique que cet amendement utilise la cryptographie pour masquer les soldes individuels et les montants de transfert tout en préservant les mécanismes permettant aux parties autorisées, y compris les émetteurs ou les auditeurs, de vérifier les informations nécessaires à la conformité.
Cette fonctionnalité reste soumise à l'activation de l'amendement, de sorte que les transferts privés de MPT ne doivent pas encore être décrits comme actifs sur le réseau principal de XRPL.
BatchV1_1 est un autre composant majeur. La norme XLS-56 permet de regrouper et de traiter plusieurs transactions ensemble, y compris des transactions impliquant différents comptes. L'exécution atomique peut faciliter les flux de travail de règlement où plusieurs actions doivent réussir conjointement plutôt que de laisser une étape complétée tandis qu'une autre échoue.
Batch a une histoire importante. Une version antérieure a été désactivée avant l'activation sur le réseau principal après la découverte d'un problème de sécurité dans la logique de signature des transactions. La Fondation XRPL s'est ensuite orientée vers BatchV1_1 comme remplacement corrigé. Comme précédemment rapporté dans la couverture de sécurité de XRPL, les développeurs ont renforcé l'examen formel des récentes mises à niveau.
La Délégation de Permission (Permission Delegation) a suivi un chemin similaire. XRPL a révélé en septembre 2025 qu'un bug dans l'amendement précédent aurait pu permettre à une transaction non autorisée de facturer des frais à un autre compte dans des conditions spécifiques. Il a été conseillé aux validateurs de voter non, et la fonctionnalité vulnérable n'a jamais été activée. PermissionDelegationV1_1 a été développé pour la remplacer.
Le concept révisé permet à un compte d'accorder des permissions de transaction définies sans remettre sa clé privée principale, supportant ainsi les portefeuilles opérationnels avec une autorité limitée.
Sponsor, basé sur XLS-68, est conçu pour permettre à un autre compte de couvrir les frais de transaction ou les exigences de réserve tandis que l'utilisateur conserve le contrôle de son compte et de ses clés. Cette fonctionnalité pourrait permettre aux applications d'intégrer des utilisateurs sans exiger qu'ils acquièrent du XRP uniquement pour couvrir les coûts du réseau. La proposition XLS-68 soutient explicitement le parrainage des frais et des réserves tout en préservant le contrôle des clés par l'utilisateur.
DynamicMPT cible les émetteurs de jetons. La proposition XLS-94 permet aux émetteurs de désigner certaines propriétés MPT comme mutables lors de la création d'un jeton, puis de mettre à jour ces champs autorisés ultérieurement. La norme est destinée à s'adapter aux exigences commerciales ou de conformité changeantes sans rendre chaque propriété de jeton librement modifiable.
Ensemble, ces fonctionnalités s'inscrivent dans l'orientation croissante de XRPL vers la finance tokenisée. Dans le cadre d'une couverture connexe sur la tokenisation, crypto.news a rapporté que JPMorgan, Mastercard, Ondo Finance et Ripple ont testé un rachat de bons du Trésor tokenisés en utilisant XRPL.
Une correction est nécessaire concernant le cadre largement diffusé des « six mises à niveau ». fixCleanup3_2_0 appartient au cycle xrpld 3.2.0 précédent, et non au nouveau paquet de fonctionnalités 3.3.0. Le changelog GitHub 3.3.0 montre plutôt des travaux autour de LendingProtocolV1_1 et une piste distincte fixCleanup3_3_0 à côté des fonctionnalités principales.
La publication ne doit donc pas être interprétée comme la mise à disposition simultanée de six fonctionnalités achevées. Il s'agit d'une étape importante du logiciel serveur qui fournit aux validateurs et aux opérateurs le code nécessaire aux décisions d'amendement. Les amendements individuels peuvent avoir des calendriers de vote différents et peuvent échouer à s'activer si le soutien tombe en dessous du seuil requis.
Ce processus de gouvernance a déjà été important par le passé. Les amendements originaux de Batch et Permission Delegation ont été arrêtés après l'identification de bugs avant l'activation sur le réseau principal, démontrant que l'inclusion dans le logiciel ou le vote des validateurs n'est pas la même chose qu'un déploiement en production.
Les opérateurs de nœuds doivent maintenant évaluer la version 3.3.0 et décider s'ils souhaitent effectuer la mise à niveau et soutenir les amendements individuels. Les dates d'activation exactes dépendent du vote des validateurs, plutôt que de la publication du logiciel le 6 août. Les règles d'amendement de XRPL exigent que la supermajorité persiste continuellement pendant deux semaines.
Pour les détenteurs de XRP, le changement immédiat est technique plutôt que monétaire. La version 3.3.0 étend la boîte à outils potentielle du réseau pour la confidentialité, le règlement en plusieurs étapes, l'autorité déléguée, l'intégration sponsorisée et l'émission de jetons configurables, mais aucune ne garantit une demande accrue de XRP ou une appréciation de son prix.
Les prochaines étapes vérifiables seront l'adoption de la version 3.3.0 par les validateurs, les niveaux de soutien aux amendements et les dates d'activation prévues. Tant que ces seuils ne sont pas atteints, les nouvelles capacités doivent être décrites comme étant publiées dans le logiciel des nœuds et en cours de gouvernance, et non comme des fonctionnalités entièrement actives du réseau principal du XRP Ledger.
Les décisions des validateurs, plutôt que le marketing de publication, détermineront quand chaque fonctionnalité deviendra utilisable sur le réseau principal.
XRP