Le 8 septembre 2026, les validateurs du XRP Ledger maintenaient l'amendement BatchV1_1 à 24 voix sur 35, soit un soutien de 68,57 %, le laissant bien loin de la supermajorité de plus de 80 % requise pour entamer sa fenêtre d'activation de deux semaines. Bien que BatchV1_1 soit livré dans le logiciel rippled, cela ne signifie pas qu'il est actif sur le XRP Ledger, et les gains en matière de DeFi et de fonctionnalités souvent associés à cette mise à niveau restent non confirmés tant que les validateurs n'ont pas franchi ce cap.

The XRP Ledger's Batch amendment is now at 68% support. We could see Batch going live by the end of this month. Batch will unlock a lot of new use cases for the XRP ecosystem. You can track progress here pic.twitter.com/uoo2Q5kf0X — moonkie (@xmoonkie), September 7, 2026

BatchV1_1 reste sous le seuil d'activation

BatchV1_1 est arrivé dans rippled 3.3.0, publié le 6 août 2026, mais l'inclusion du code et l'activation sur le mainnet sont deux événements distincts sur le XRP Ledger. Contrairement aux réseaux qui déploient des changements de protocole via des hard forks ou des votes de gouvernance hors chaîne, les modifications du XRPL deviennent actives automatiquement par consensus des validateurs : dès qu'un amendement conserve le soutien de la majorité pendant la période requise, il s'active sur chaque serveur exécutant un logiciel compatible, sans scission coordonnée de la chaîne. Au 8 septembre, l'amendement affichait un soutien de 68,57 % au sein de la Unique Node List par défaut, selon les données de XRPScan.

L'activation exige plus de 80 % d'approbation maintenue pendant 14 jours consécutifs, et ce compte à rebours n'a pas commencé. Dans la configuration actuelle de 35 validateurs, au moins 29 votes favorables sont nécessaires pour franchir le seuil, même si ce nombre exact peut varier si l'ensemble des validateurs participants change. Le soutien peut également retomber sous les 80 % en cours de compte à rebours, ce qui réinitialise entièrement le chronomètre.

La version 3.3.0 n'était pas une publication monofonctionnalité – elle a également introduit ConfidentialTransfer, DynamicMPT, Sponsor et PermissionDelegationV1_1, intégrant BatchV1_1 dans un ensemble plus large de mises à niveau orientées institutions. Les investisseurs qui suivent la croissance du XRP Ledger et les flux entrants liés aux ETF devraient considérer ces amendements comme des sujets parallèles, chacun nécessitant sa propre supermajorité de validateurs avant toute mise en service.

Ce que les transactions Batch pourraient permettre si elles sont activées

Une fois actives, une transaction Batch pourrait regrouper jusqu'à huit transactions internes au sein d'une seule transaction externe, avec quatre modes d'exécution : « Tout ou rien », qui exige que chaque transaction interne réussisse ; « Une seule », qui applique la première opération réussie ; « jusqu'à l'échec », qui traite les transactions jusqu'à ce qu'une échoue ; et « Indépendant », qui tente chaque transaction incluse quel que soit le résultat.

Les cas d'usage potentiels incluent les échanges atomiques de tokens, la création de NFT associée à une offre, les frais de plateforme groupés et des actions coordonnées sur plusieurs comptes – à condition que chaque compte participant autorise l'ensemble complet. Chaque transaction interne validée conserverait ses propres métadonnées ainsi qu'une référence vers son lot parent, une structure visant à réduire l'infrastructure de coordination externe dont les applications ont actuellement besoin pour les actions multi-étapes.

Il s'agit pour l'instant de capacités conçues et non de résultats opérationnels. Les gains d'efficacité (et toute hausse d'activité qui en résulterait autour de cas d'usage comme le règlement en RLUSD et les flux de finance tokenisée sur XRPL) dépendent à la fois de l'activation par les validateurs et du soutien ultérieur des portefeuilles et des SDK.

L'historique de sécurité derrière l'amendement de remplacement

BatchV1_1 n'est pas le code Batch original : c'est une réécriture. Les développeurs ont désactivé l'amendement original en février 2026 après que Pranamya Keshkamat et l'outil de sécurité Apex de Cantina AI ont identifié une faille critique dans la logique de vérification des signataires de lot.

Ce bug aurait pu permettre à un attaquant de contourner les vérifications d'autorisation pour certains participants et de soumettre des transactions non autorisées depuis le compte d'une victime. Fait essentiel, la version vulnérable n'a jamais été activée sur le mainnet, et XRPL Labs a indiqué qu'aucun fonds utilisateur n'a été mis en danger. Rippled 3.1.1 a marqué l'amendement Batch original comme non pris en charge, et son remplaçant corrige l'erreur de sortie anticipée, ajoute des garde-fous d'autorisation et resserre les vérifications de signataire, avec un audit indépendant ayant examiné BatchV1_1 avant son inclusion dans la version 3.3.0.

Pourquoi ce n'est pas encore un catalyseur du prix du XRP

Cette nouvelle n'a pas provoqué de mouvement de prix notable, et cela a peu de chances de changer tant que le soutien reste à 68,57 %. L'amendement modifie les fonctionnalités transactionnelles du registre, et non les règles d'offre ou d'émission du XRP : il ne présente donc aucun angle direct de politique monétaire pour les traders qui évaluent le potentiel de hausse du XRP à court terme.

Toute hausse du volume de transactions XRPL, de l'activité DeFi ou de la demande de tokens liée à Batch demeure prospective, conditionnée d'abord au franchissement de la supermajorité, puis à l'intégration effective de la fonctionnalité par les portefeuilles, les exchanges et les protocoles DeFi. D'ici là, Batch constitue un récit d'infrastructure plutôt qu'un catalyseur de valorisation confirmé.

La prochaine étape : une supermajorité de validateurs soutenue

Le prochain jalon confirmé pour les validateurs XRPL est le franchissement des 80 % de soutien. Ce n'est qu'ensuite que le registre commence à enregistrer la période obligatoire de majorité continue de 14 jours. Le soutien doit rester au-dessus du seuil pendant toute la durée, sinon le compteur est remis à zéro.

Une activation fin septembre restait mathématiquement possible au 8 septembre, mais rien n'est programmé. Les opérateurs de nœuds doivent d'abord exécuter un logiciel prenant en charge BatchV1_1 avant de pouvoir voter pour lui, et XRPL a par ailleurs averti les opérateurs Clio de passer à la version 2.8.0 afin que l'infrastructure API puisse traiter les nouveaux formats de transaction et de registre si l'amendement venait à s'activer.

Source : https://icobench.com/news/xrp-news-batchv1-1-xrp-ledger-vote/