L’amendement Batch V1.1 du XRP Ledger se rapproche de son activation avec 27 votes de validateurs
Points clés
- •Deux validateurs favorables supplémentaires porteraient l’approbation à 82,86 %, au-dessus du seuil nécessaire pour commencer la période d’activation.
- •Batch V1.1 peut coordonner jusqu’à huit transactions liées et exiger que chaque instruction aboutisse avant d’enregistrer l’ensemble du lot.
- •L’amendement révisé remplace une version précédente retirée après la découverte par des chercheurs d’une vulnérabilité d’autorisation avant son activation sur le réseau principal.
- •Batch serait facultatif, n’accélérerait pas les transferts XRP ordinaires et n’imposerait pas de changement à toutes les applications.
- •Les portefeuilles, les places de marché et les services de paiement devraient encore intégrer la fonctionnalité avant que les utilisateurs puissent en bénéficier.

L’amendement Batch V1.1 du XRP Ledger se rapproche de son activation après avoir reçu le soutien de 27 des 35 validateurs suivis par XRPScan à 06:25 UTC le 15 septembre 2026.
Deux validateurs favorables supplémentaires porteraient l’approbation à 82,86 %, au-dessus du seuil de 80 % requis pour commencer la période d’activation. L’amendement devrait ensuite conserver le soutien requis pendant deux semaines consécutives avant de devenir une partie des règles actives du XRP Ledger.
Le processus distingue la mise à disposition du code de l’amendement de son activation sur le réseau principal. Un amendement peut être inclus dans le logiciel serveur du XRP Ledger, mais il ne modifie pas le comportement du réseau principal tant que les validateurs ne l’ont pas approuvé et que la période requise n’est pas achevée.
Comment Batch V1.1 pourrait éviter les paiements incomplets
Batch V1.1 permettrait de soumettre simultanément jusqu’à huit transactions liées. Le registre pourrait vérifier et enregistrer les instructions sélectionnées lors de la même clôture du registre, au lieu d’exiger d’une application qu’elle soumette et confirme chaque étape séparément.
Par exemple, une vente sur une place de marché pourrait comprendre trois actions : l’acheteur envoie le paiement, le vendeur transfère un actif et la place de marché reçoit ses frais. Avec l’option d’exécution intégrale ou d’échec complet, les trois instructions devraient aboutir, faute de quoi l’ensemble du lot échouerait. Cela empêcherait l’enregistrement du paiement de l’acheteur si le transfert d’actif correspondant ne pouvait pas être effectué.
Un lot pourrait également coordonner des instructions impliquant plusieurs comptes. Cette fonctionnalité serait donc pertinente pour les applications dans lesquelles plusieurs participants doivent autoriser différentes parties d’une même opération.
L’amendement n’accélérerait pas les transferts XRP ordinaires et n’obligerait pas toutes les applications à utiliser des lots. Il fournirait plutôt une structure de transaction facultative aux développeurs qui créent des services comportant plusieurs étapes liées.
V1.1 remplace un amendement Batch retiré
L’amendement Batch original comportait une faille dans la manière dont il vérifiait l’autorisation des transactions au sein d’un lot. Des chercheurs en sécurité ont identifié le problème en février, alors que l’amendement attendait encore son activation.
Il a été conseillé aux validateurs de retirer leur soutien avant que la fonctionnalité n’atteigne le réseau principal, de sorte que la vulnérabilité n’a pas affecté les fonds des utilisateurs. La divulgation de vulnérabilité de la XRP Ledger Foundation décrit la réponse apportée et précise que l’ancienne implémentation n’est plus prise en charge.
Batch V1.1 remplace cette version après la correction de sa logique d’autorisation. Selon RippleX, l’implémentation révisée a également fait l’objet d’un examen supplémentaire du code, de tests et d’évaluations externes de sécurité avant de revenir au processus de vote des validateurs.
Le nouveau vote constitue donc davantage qu’une seconde tentative d’activation de la même fonctionnalité. Les validateurs déterminent si le remplacement répond suffisamment au problème qui avait interrompu l’amendement original.
Batch est plus proche de l’activation que le système de prêts prévu par XRPL
La position de Batch peut être comparée à celle de deux autres évolutions du XRP Ledger qui avancent dans le processus d’amendement. La proposition fixCleanup3_3_0 traite des questions de maintenance et de sécurité concernant les coffres, les teneurs de marché automatisés et les échanges soumis à autorisation. Elle améliore les parcours de transaction existants plutôt que d’introduire une nouvelle fonction de paiement pour les applications.
Le système de crédit institutionnel prévu reste plus éloigné de sa mise en œuvre. Les Single Asset Vaults comme le Lending Protocol nécessitent un soutien suffisant des validateurs, et l’activation d’un seul de ces éléments ne créerait pas un marché de prêts natif opérationnel.
Batch a une portée plus limitée, car il coordonne des transactions déjà prises en charge par le XRP Ledger, notamment les paiements, les transferts d’actifs et les frais. Ses 27 validateurs favorables le placent plus près du seuil d’activation que les deux amendements nécessaires aux prêts natifs.
Cette comparaison montre également pourquoi l’approbation d’un amendement ne se traduit pas toujours directement par un produit finalisé. Les prêts nécessitent plusieurs composants de protocole interconnectés, tandis que Batch fournirait aux applications individuelles un outil qu’elles pourraient intégrer de manière indépendante.
Ce que l’activation impliquerait pour les portefeuilles et les places de marché
L’achèvement du processus d’activation rendrait Batch disponible sur le registre actif, mais les portefeuilles, les places de marché et les services de paiement devraient encore l’intégrer à leurs produits.
Les utilisateurs n’auraient pas besoin de modifier la manière dont ils effectuent un transfert XRP standard. La différence deviendrait visible dans les applications qui demandent actuellement aux clients d’accomplir plusieurs actions liées ou de relancer une opération après l’échec d’une instruction.
Les services qui combinent un paiement, un transfert d’actif et des frais de plateforme figurent parmi les utilisateurs potentiels les plus évidents. Chaque fournisseur devrait néanmoins déterminer quelles étapes doivent être regroupées et si elles doivent toutes réussir avant que la demande du client soit considérée comme terminée.
Le vote n’est que le premier test pour Batch V1.1
Atteindre le seuil d’activation établirait que les validateurs sont prêts à exécuter Batch V1.1, mais ne montrerait pas le niveau de demande pour cette fonctionnalité. Cette question ne pourra être tranchée que par son adoption auprès des portefeuilles, des places de marché et des applications de paiement.
Batch pourrait présenter un avantage par rapport aux propositions de prêts plus ambitieuses de XRPL, car les développeurs n’auraient pas besoin d’attendre plusieurs composants de protocole ou la création d’un marché financier entièrement nouveau. Ils pourraient l’appliquer à des flux de transaction déjà existants.
Son importance à terme dépendra donc moins du vote sur l’amendement que de la fréquence à laquelle les services XRPL rencontrent suffisamment d’échecs en plusieurs étapes pour justifier son intégration.
Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil financier ou en investissement. Le soutien des validateurs et le statut de l’amendement peuvent évoluer.
Source : Coindoo.