XRP Ledger : l’amendement de nettoyage glisse au 4 novembre après un creux de moins de deux heures, le prêt reste loin du seuil

Mise à jour du 22 octobre 2026, 5 h 30 UTC : fixCleanup3_4_0 ne s’activera finalement pas le 23 octobre. Son soutien est tombé à 26 des 35 validateurs de confiance au ledger de signalisation de 12 h 54 UTC le 21 octobre, sous les 29 voix désormais nécessaires, avant de remonter à 29 à 14 h 46 UTC, ce qui a relancé le compte à rebours de deux semaines. L’activation est maintenant attendue vers 14 h 46 UTC le 4 novembre si la majorité tient ; à 4 h 38 UTC le 22 octobre, l’amendement avait 31 voix sur 35, selon les outils de suivi XRPL Dashboard et XRPLWin, des chiffres que rapporte aussi CoinDesk. Les amendements de prêt n’ont toujours pas de majorité, avec 19 voix sur 35 chacun.

Le 17 octobre, le XRP Ledger semblait à moins de six jours d’activer son prochain lot de correctifs, alors que la fonction de prêt natif, celle qui a concentré l’attention cette année, n’avait toujours pas les voix pour entrer en service. L’amendement du XRP Ledger baptisé fixCleanup3_4_0 recueillait le soutien de 26 des 32 validateurs de confiance comptés sur les derniers ledgers, soit 81,25 %, selon XRPScan à 19 h 27 UTC le 17 octobre. blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il détenait cette majorité depuis le 9 octobre à 09 h 34 UTC, ce qui plaçait alors son activation vers 09 h 34 UTC le vendredi 23 octobre. Un creux de moins de deux heures, le 21 octobre, a depuis repoussé cette date au 4 novembre.

Les deux amendements consacrés au prêt, LendingProtocol et sa version révisée LendingProtocolV1_1, comptaient chacun 17 voix sur 32 (53,1 %) au même moment, d’après les mêmes données. SingleAssetVault, la norme de coffres sur laquelle repose le prêt, en avait 19 (59,4 %). Aucun des trois n’a la majorité, donc aucun n’a de date.

Bitcoin.com News a rapporté le même clivage le 17 octobre, avec des chiffres légèrement différents, car le nombre de validateurs qui votent varie d’un ledger à l’autre. Bitcoin.com situait fixCleanup3_4_0 entre 26 et 29 soutiens sur 32 à 35 ces derniers jours. Sauf mention contraire, cet article s’en tient aux chiffres de XRPScan relevés à 19 h 27 UTC le 17 octobre.

Comment un amendement du XRP Ledger s’active : 80 % pendant deux semaines

Le XRP Ledger n’a ni mineurs ni vote de jetons sur la chaîne. Les changements apportés aux règles que tous les serveurs appliquent, d’un nouveau type de transaction à une correction d’arrondi, passent par des amendements, et ce sont les validateurs du réseau qui décident du moment où ils s’activent. Chaque validateur indique pour chaque amendement connu s’il vote oui ou non, et les serveurs additionnent ces signaux à chaque ledger de signalisation (« flag ledger »), un ledger sur 256, soit environ toutes les 15 minutes.

Ce qui compte, ce n’est pas l’ensemble des validateurs du réseau, mais ceux auxquels la plupart des serveurs font confiance : la liste par défaut, appelée UNL. XRPScan en comptait 32 sur les derniers ledgers à 19 h 27 UTC le 17 octobre.

La règle est courte. La page des amendements connus de XRPL.org indique qu’un amendement « peut être activé s’il conserve une supermajorité pendant au moins deux semaines ». La page de XRPL.org sur le fonctionnement des amendements fixe cette supermajorité à plus de 80 % des validateurs de confiance. Exactement 80 % ne suffit pas. Un correctif activé en avril 2021, fixAmendmentMajorityCalc, a comblé une faille d’arrondi qui avait permis à un amendement de passer avec 28 validateurs sur 36 (77,8 %) ; depuis, le minimum n’est jamais inférieur à 80 % de la liste de confiance.

Si le soutien retombe à 80 % ou moins à n’importe quel moment de ces deux semaines, l’amendement perd sa majorité et le compte à rebours s’arrête. Quand une majorité revient, un nouveau décompte de 14 jours repart de zéro.

Le 17 octobre, fixCleanup3_4_0 gardait sa majorité à une seule voix près

Quatre-vingts pour cent de 32 validateurs, cela fait 25,6. XRPScan affiche un seuil de 25 pour tous les amendements soumis à ces 32 validateurs : c’est 80 % arrondi à l’entier inférieur, le chiffre que le soutien doit dépasser. Comme la règle exige plus de 80 %, le minimum est de 26 voix pour. fixCleanup3_4_0 en avait exactement 26 à 19 h 27 UTC le 17 octobre.

La marge était donc d’une voix. Si un seul validateur favorable était passé au non, l’amendement serait tombé à 25 sur 32 (78,1 %) et la date du 23 octobre aurait disparu. Une variation de la taille de la liste de confiance pouvait produire le même effet : avec 33 validateurs comptés, 80 % feraient 26,4 et le minimum passerait à 27.

C’est ce qui s’est produit. Le 21 octobre, les outils de suivi comptaient 35 validateurs de confiance, ce qui portait le minimum à 29, et le soutien n’était plus que de 26 voix au ledger de signalisation de 12 h 54 UTC. On ignore si l’allongement de la liste a provoqué ce creux, ou si des validateurs ont changé de vote ou se sont déconnectés (un validateur hors ligne compte comme un non) : ni XRPL Dashboard ni XRPLWin n’identifient ceux qui ont décroché.

Le 17 octobre, rien n’indiquait un tel basculement : la majorité tenait sans interruption depuis le 9 octobre. Six validateurs du décompte ne votaient pas oui à 19 h 27 UTC ce jour-là, et leurs raisons ne sont pas publiques.

Les réglages par défaut comptent aussi. D’après XRPL.org, la dernière version stable de xrpld livre fixCleanup3_4_0 sur « Non » par défaut : les 26 opérateurs qui le soutenaient le 17 octobre l’ont donc activé eux-mêmes.

Le décompte des voix au 17 octobre, amendement par amendement

Le tableau ci-dessous recense les amendements encore ouverts sur le XRP Ledger, avec les voix relevées par XRPScan à 19 h 27 UTC le 17 octobre. Le numéro XLS désigne la norme (XRP Ledger Standard) qui décrit chaque fonction.

Source : données d’amendements de XRPScan, 17 octobre 2026, 19 h 27 UTC. Un correctif plus ancien, fixBatchInnerSigs, que XRPScan classe comme obsolète, avait 10 voix sur 35 dans un ancien état de la liste de validateurs au même moment.

Plusieurs amendements sont déjà passés ces dernières semaines. PermissionDelegationV1_1 (XLS-75) a été activé à 21 h 29 UTC le 8 octobre avec 28 voix sur 33. Le lendemain, fixBatchV1_2 l’a été à 14 h 15 UTC avec les 32 voix, suivi de BatchV1_1 (XLS-56) à 14 h 47 UTC avec 27 sur 32.

Ces dates montrent aussi comment l’activation se déclenche. BatchV1_1 a obtenu sa majorité à 14 h 46 UTC le 25 septembre et est entré en service à 14 h 47 UTC le 9 octobre, soit deux semaines et moins de deux minutes plus tard. Le changement s’applique au premier ledger de signalisation qui suit l’échéance des deux semaines : avec le premier compte à rebours, 09 h 34 UTC le 23 octobre était donc l’heure la plus précoce. Avec le nouveau, c’est 14 h 46 UTC le 4 novembre, et XRPL Dashboard prévoit que les étapes sur le ledger soient terminées vers 15 h 03 UTC.

Ce que les correctifs de fixCleanup3_4_0 changent sur le ledger

fixCleanup3_4_0 n’ajoute aucune fonction. C’est un ensemble de corrections apportées à du code déjà présent sur le ledger, ou en attente d’activation, livré avec xrpld 3.4.0, la version du serveur annoncée par XRPL.org le 16 septembre.

XRPL.org recense des correctifs dans de nombreux domaines : les coffres à actif unique (Single Asset Vaults), le protocole de prêt, les teneurs de marché automatisés (AMM), la bourse décentralisée à permissions, les lignes de confiance, les NFT, les jetons multi-usage (MPT), les séquestres (escrow), le parrainage (sponsorship), la signature des transactions et la délégation de permissions. Quelques changements donnent la mesure.

• Un compte sans ligne de confiance ne peut plus utiliser une offre pour recevoir des jetons d’un émetteur qui a activé le drapeau bloquant les lignes de confiance entrantes.
• Les règles de clawback pour les pools d’AMM sont resserrées, y compris le traitement du dernier détenteur des jetons d’un pool, et les clawbacks de coffres reçoivent une correction d’arrondi.
• Les signatures de la contrepartie et du parrain reçoivent des préfixes de signature distincts, pour qu’un type de signature ne puisse pas être rejoué comme l’autre.
• Terminer ou annuler un séquestre libère d’abord la réserve du propriétaire, si bien que la restitution de jetons à la limite de la réserve n’échoue plus.
• Les retraits d’un coffre acceptent des identifiants de credentials, et les dépôts, retraits et clawbacks s’arrondissent plus précisément.
• Le défaut d’un prêt échappe aux gels et aux verrouillages de MPT sur le transfert du courtier vers le coffre.

Par ailleurs, la version 3.4.0 retire un ancien amendement, fixAMMOverflowOffer, dont le comportement devient une partie permanente du protocole.

Pourquoi les émetteurs de jetons attendent le correctif PaymentBurn

Un correctif a un usage concret et immédiat. PermissionDelegationV1_1, en service depuis le 8 octobre, permet à un compte de confier des pouvoirs précis à un autre compte. L’un d’eux, la permission PaymentBurn, sert à détruire des jetons. XRPL.org prévient qu’avant le correctif, un délégué qui la détient « peut aussi créer de nouveaux jetons fongibles » dans certains cas, et recommande de ne pas déléguer PaymentBurn tant que fixCleanup3_4_0 n’est pas activé. Le correctif fait rejeter par le ledger un paiement de destruction qui franchirait un solde nul pour devenir une création, sauf si le délégué détient aussi la permission PaymentMint.

Le problème concerne les jetons émis sur le ledger, comme les jetons de lignes de confiance et les MPT, et XRPL.org précise que les autres permissions ne sont pas touchées. Il ne concerne pas l’offre de XRP, l’actif natif du ledger. Les émetteurs et les conservateurs qui ont mis en place la délégation doivent tenir PaymentBurn à l’écart jusqu’à l’activation de l’amendement, et vérifier qu’elle a bien eu lieu.

Ce que les opérateurs de nœuds doivent faire avant le 4 novembre

Pour la plupart des opérateurs, rien de nouveau. Un serveur doit connaître un amendement avant que le réseau l’active ; sinon, il devient bloqué par amendement (« amendment blocked »). Un serveur bloqué ne peut pas appliquer les nouvelles règles : il décroche du réseau et ne peut plus valider ni servir les données à jour du ledger. Les fonds présents sur le ledger ne sont pas en danger. Le service que le nœud fournit à un portefeuille, à une plateforme d’échange ou à une application, lui, l’est.

Le code de fixCleanup3_4_0 figure dans xrpld depuis la version 3.4.0. En pratique, l’échéance qui comptait est pourtant déjà passée, le 9 octobre. La version d’urgence xrpld 3.4.1, annoncée le 25 septembre et étiquetée sur GitHub le 10 octobre, qui a durci le moteur de paiement contre la faille décrite dans notre article sur le bug de dépassement du XRP Ledger, embarquait aussi fixBatchV1_2, et cet amendement a été activé le 9 octobre. XRPL.org avait averti que les serveurs non mis à jour en 3.4.1 seraient bloqués par amendement et « incapables de rester synchronisés avec le reste du réseau ».

Cela laisse trois cas de figure :

• Les serveurs sous xrpld 3.4.1 ou plus récent contiennent déjà le code de fixCleanup3_4_0 et n’ont rien à faire pour cet amendement.
• Les serveurs restés en 3.4.0 sont bloqués par amendement depuis l’activation de fixBatchV1_2 le 9 octobre, et leurs opérateurs ont besoin de la 3.4.1 pour rejoindre le réseau.
• Tout ce qui tourne en 3.3.x ou plus ancien est bloqué pour la même raison, et n’aurait de toute façon pas fixCleanup3_4_0 lui-même.

Les opérateurs qui installent par paquets doivent noter un changement arrivé avec la 3.4.0 : les paquets DEB et RPM sont désormais servis depuis packages.xrplf.org et signés avec une clé de la fondation XRPL, de sorte que les systèmes configurés pour l’ancien dépôt ont besoin de la nouvelle source et de la nouvelle clé.

Les amendements de nettoyage se succèdent à un rythme régulier cette année. fixCleanup3_1_3 a été activé le 27 mai, fixCleanup3_2_0 le 29 juillet et fixCleanup3_3_0 le 11 septembre. Si fixCleanup3_4_0 entre en service le 4 novembre, l’écart sera de près de huit semaines, entre les neuf et les six semaines des deux précédents.

Protocole de prêt du XRP Ledger : ce qu’apporteraient XLS-65 et XLS-66

Le prêt est le sujet le plus important, et le plus lent. Il repose sur deux normes entrées dans le code du serveur avec xrpld 3.1.0.

La première, XLS-65, crée le coffre à actif unique (Single Asset Vault). Les utilisateurs y déposent un seul actif en commun, par exemple du XRP ou un jeton émis sur le ledger, et reçoivent des parts qui représentent leur quote-part du pool. Le coffre est la cagnotte ; à lui seul, il ne prête rien.

La seconde, XLS-66, ajoute le protocole de prêt. Un courtier de prêts puise dans un coffre pour accorder des prêts à terme fixe. XRPL.org les décrit comme non garantis : rien n’est bloqué en sûreté, à la différence de la plupart des prêts DeFi, où l’emprunteur dépose d’abord une garantie dans des contrats intelligents. Les contrôles de crédit se font hors du ledger, par la souscription et la gestion des risques, tandis que les remboursements, les intérêts et les défauts y sont enregistrés.

La version révisée, LendingProtocolV1_1, est arrivée avec xrpld 3.4.0 et modifie la conception sur deux points. Elle introduit des coffres à durée fermée qui fonctionnent en trois phases : souscription, quand les dépôts arrivent, puis investissement, puis remboursement. Une fois l’amendement activé, les nouveaux courtiers de prêts ne pourront être créés que sur des coffres à durée fermée. Elle passe aussi la comptabilité des coffres en base de caisse : les intérêts ne comptent comme un revenu que lorsque l’emprunteur les paie réellement.

Cette conception vise les institutions plus que les traders particuliers : un fonds ou une banque pourrait constituer un pool pour une durée définie, le prêter à des emprunteurs sélectionnés et le restituer avec les intérêts, le tout inscrit sur un registre public. Elle s’accorderait avec la volonté de Ripple de faire utiliser le XRP et son stablecoin RLUSD par des acteurs professionnels, comme dans l’accord sur le collatéral RLUSD chez Ripple Prime. Rien de tout cela ne peut tourner sur le mainnet du XRP Ledger tant que les amendements ne sont pas passés.

Pour un lecteur français, la question réglementaire reste en retrait à ce stade : le protocole lui-même est du code, et un produit de prêt proposé à des particuliers en France relèverait du cadre MiCA, sous le contrôle de l’AMF, seulement s’il était offert par un prestataire de services sur crypto-actifs. Aucun produit de ce type n’existe encore sur le XRP Ledger.

Pourquoi les validateurs freinent sur le prêt

Le soutien au prêt progresse, mais lentement. Début juillet, Digital Today rapportait que XLS-66 recueillait environ 20 % des voix des validateurs et XLS-65 22,86 %. Au 17 octobre, les deux amendements de prêt en étaient à 53,1 % et le coffre à 59,4 %.

Dans le même article de Digital Today, daté du 1er juillet, l’ingénieur logiciel de RippleX Mayukha Vadari expliquait que les validateurs attendaient les correctifs du prochain amendement de nettoyage, en ajoutant : « La sécurité d’abord. » Le lot dont elle parlait était fixCleanup3_2_0, activé le 29 juillet. Graffe, un opérateur de validateur cité par le média à partir d’un message sur X, jugeait que la progression de XLS-65 et XLS-66 était très lente et que les chiffres de vote n’avaient presque pas bougé depuis longtemps.

Notre lecture, qu’aucun validateur n’a confirmée pour cette version, est que la même logique s’applique désormais à fixCleanup3_4_0. Le lot corrige directement le code des coffres et du prêt, et un opérateur qui veut ces correctifs en service avant d’allumer le prêt attendrait l’activation du lot, désormais prévue le 4 novembre. La frayeur du bug de dépassement en octobre a donné aux opérateurs une raison de plus d’avancer prudemment.

L’écart reste large. Avec 32 validateurs comptés, LendingProtocolV1_1 avait besoin de neuf voix oui supplémentaires à 19 h 27 UTC le 17 octobre pour atteindre 26, et SingleAssetVault de sept. À 4 h 38 UTC le 22 octobre, les deux amendements de prêt avaient chacun 19 voix sur 35, dix de moins que les 29 désormais requises, selon XRPL Dashboard et XRPLWin ; SingleAssetVault en avait 21, selon XRPLWin. Même si elles arrivaient demain, chaque amendement devrait ensuite tenir deux semaines de plus. Bitcoin.com souligne que les trois amendements nécessaires au prêt complet restent sous la supermajorité, sans date d’activation. Ni RippleX ni la fondation XRPL n’ont publié de calendrier du prêt que nous ayons pu trouver.

Ce qu’il faudra surveiller d’ici au 4 novembre, et après

La première date est fixée par les règles. Si fixCleanup3_4_0 conserve plus de 80 % des validateurs de confiance (29 sur 35 au décompte du 22 octobre) à chaque ledger de signalisation jusqu’à environ 14 h 46 UTC le mercredi 4 novembre, il s’active au ledger de signalisation suivant et l’avertissement sur PaymentBurn peut être levé. C’est déjà arrivé une fois : un creux de moins de deux heures, le 21 octobre, lui a coûté 12 jours. Tout nouveau creux relancerait le décompte.

Ensuite, ce sont les décomptes de SingleAssetVault et des deux amendements de prêt qu’il faut suivre, sur XRPScan ou sur XRPL.org. Un bond du soutien dans les jours qui suivent le 4 novembre irait dans le sens de la lecture ci-dessus ; une absence de changement suggérerait que les validateurs attendent autre chose avant d’avancer. Aucune nouvelle version de xrpld ni aucun nouvel amendement n’a été annoncé.

Les marchés n’ont pas réagi à ce vote. Le XRP s’échangeait autour de 1,30 $ à 19 h 10 UTC le 17 octobre, en baisse de 7,5 % sur sept jours selon les données de marché de Coindaro, et rien ne relie ce mouvement au calendrier des amendements. Les lecteurs qui découvrent le rôle des validateurs et des ledgers peuvent commencer par notre guide pour comprendre ce qu’est une blockchain.