XRP Ledger 3.4.0 Ajoute Prêts Natifs Et Correctifs

On pourrait croire qu’une mise à jour de nœud se résume à un numéro de version et à une note de patch. Dans le cas du XRP Ledger, la sortie de xrpld 3.4.0, datée du 16 septembre 2026, raconte autre chose. Elle dépose sur la table deux paquets d’amendements, un modèle de prêt redessiné, un lot de durcissements transactionnels et une nouvelle filière de distribution pour les opérateurs Linux. Rien de tout cela n’active encore le prêt natif sur le réseau principal. C’est précisément ce décalage, entre code publié et règles votées, qui mérite d’être lu avec attention.

Ce Que Change Vraiment La Version 3.4.0

Le communiqué officiel indique que 3.4.0 introduit LendingProtocolV1_1 et fixCleanup3_4_0, tout en retirant fixAMMOverflowOffer une fois que son comportement post-amendement est devenu une pièce permanente du protocole. Installer le logiciel n’équivaut pas à basculer le registre. Sur XRPL, un amendement n’entre en vigueur qu’après un soutien supérieur à 80 % des validateurs de confiance, maintenu sans interruption pendant deux semaines. Tant que ce seuil n’est pas tenu, les nouvelles règles restent du code en attente.

Ce point de méthode n’est pas un détail de gouvernance. Il explique pourquoi la communauté peut saluer une version tout en voyant, le lendemain, les mêmes compteurs de vote inchangés. Un serveur mis à jour comprend les propositions. Il ne les approuve pas par magie. La Fondation XRPL conserve d’ailleurs un comportement de vote par défaut négatif : sans configuration explicite, l’opérateur n’envoie pas un oui automatique.

Pourquoi Cette Sortie Arrive Maintenant

Le registre XRP n’est pas un laboratoire isolé. Depuis plusieurs cycles, les équipes ont empilé des propositions autour des coffres à actif unique, du prêt à terme, des jetons multi-usages, des lots de transactions et des frais sponsorisés. La 3.3.0 avait déjà embarqué du code pour plusieurs de ces pistes, sans que le consensus ne bascule. La 3.4.0 reprend le fil, corrige des angles morts et reformule le prêt pour le rendre plus cadencé, plus lisible comptablement, plus fermé dans le temps.

Ce rythme, parfois frustrant pour qui attend un produit prêt à l’emploi, est cohérent avec l’histoire du réseau. XRPL privilégie la stabilité des invariants avant l’effet d’annonce. Un prêt natif mal calé sur les arrondis, les défauts ou les signatures rejouables coûterait plus cher qu’un calendrier trop prudent. D’où ce mélange, dans la même version, d’une refonte fonctionnelle et d’un grand ménage transactionnel.

LendingProtocolV1_1 : Des Coffres Fermés Dans Le Temps

Le premier amendement ne se contente pas d’ajouter une case à cocher. Il change la géométrie des Single Asset Vaults et du protocole de prêt. Les coffres deviennent closed-ended : ils vivent selon des périodes définies de souscription, d’investissement, puis de rachat. Pendant la souscription, les déposants peuvent ajouter ou retirer des actifs. Pendant l’investissement, les flux s’arrêtent et le capital peut financer des prêts. Quand la période d’investissement s’achève, le rachat s’ouvre et chacun récupère sa quote-part après maturité des prêts.

Une fois V1.1 actif, de nouveaux courtiers de prêt ne pourraient plus s’attacher qu’à des coffres fermés. Les relations déjà nées sous les règles antérieures recevraient un traitement distinct, afin de laisser vivre les positions en cours. C’est une manière de ne pas casser l’existant tout en interdisant, pour l’avenir, un modèle plus poreux.

Déposer n’est plus un geste continu. C’est entrer dans une fenêtre, accepter un gel, puis attendre que le cycle rende sa part.

Documentation technique du prêt XRPL, reformulée

Cette architecture rappelle moins un compte d’épargne instantané qu’un fonds à échéances. Elle force les participants à penser en calendrier. Elle réduit aussi les allers-retours opportunistes pendant que l’argent travaille. Pour un réseau qui vise des usages institutionnels autant que de la finance ouverte, le message est clair : le prêt natif ne sera pas un robinet qu’on ouvre et ferme à la seconde.

La Comptabilité De Caisse Change Le Revenu Du Coffre

Le second geste de V1.1 est comptable. Dans le modèle antérieur, l’intérêt programmé était reconnu dès l’origine du prêt. Dans le nouveau modèle, un coffre ne reconnaît l’intérêt que lorsque l’emprunteur paie réellement. L’intérêt futur non encaissé reste hors revenu jusqu’à l’arrivée du paiement. Cela touche AssetsTotal, le calcul de la dette et le traitement des défauts.

Le changement n’est pas rétroactif. Les coffres nés sous l’ancienne méthode conservent cette méthode après activation. Deux mondes comptables pourront donc coexister un temps. Pour un auditeur, un intégrateur ou un tableau de bord, c’est une source de friction. Pour la sincérité des chiffres, c’est un progrès : on ne gonfle plus le revenu avec de l’intérêt encore théorique.

Cette bascule vers une logique de caisse n’est pas cosmétique. Elle modifie ce qu’un déposant croit détenir. Elle change aussi la manière dont un défaut se propage dans les totaux. Un protocole qui affiche trop tôt des gains paperasse un risque de désillusion. Un protocole qui n’inscrit le revenu qu’au paiement force tout le monde à regarder le cash, pas le calendrier d’origine.

XLS-65 Et XLS-66 Restent Le Socle Inachevé

LendingProtocolV1_1 ne flotte pas dans le vide. Il dépend de l’architecture sous-jacente décrite notamment par XLS-66 : un prêt à terme, non collatéralisé, alimenté par des fonds mis en commun via des coffres à actif unique. L’analyse de crédit et la sélection de l’emprunteur restent hors chaîne. La spécification est encore classée comme brouillon. Aucune source examinée pour cette actualité n’a montré un prêt mainnet exécuté via ce protocole natif, ni une date d’activation pour V1.1.

Un instantané du 17 septembre, fondé sur l’historique des validateurs de la Fondation, indiquait 16 soutiens sur 35 pour SingleAssetVault et 13 sur 35 pour LendingProtocol. Ces chiffres bougent. Ils ne remplacent pas la règle officielle : plus de 80 % pendant deux semaines d’affilée. On est donc encore loin d’un basculement, même si le validateur de Ripple avait déjà voté pour les propositions sous-jacentes en août.

fixCleanup3_4_0 : Un Grand Ménage Transactionnel

Le second amendement ressemble à une valise. Il rassemble des correctifs qui touchent le prêt, les coffres, les teneurs de marché automatisés, les jetons multi-usages, les NFT, l’escrow, le trading permissionné et l’autorisation de compte. L’idée n’est pas de lancer un produit. Elle est de rendre plus durs des chemins déjà empruntés, parfois jusqu’aux arrondis.

Un exemple parlant concerne AMMClawback. Une correction empêche de brûler les jetons de fournisseur de liquidité d’un détenteur tout en récupérant zéro actif sous-jacent, lorsque l’arrondi MPT réduit le montant calculé à zéro. Autrement dit, on ne détruit plus une position pour un recouvrement fantôme. C’est le genre de bug qui, laissé ouvert, mine la confiance plus sûrement qu’un discours marketing.

Les invariants MPT se durcissent aussi. Les contrôles ValidMPTBalanceChanges et ValidMPTTransfer, qui produisaient surtout des journaux, deviennent réellement appliqués sous l’amendement, y compris lorsque la transaction échoue. Un log n’arrête pas une incohérence. Une règle appliquée, si.

Précision Des Coffres, Offres Et Identifiants

Pour les coffres à actif unique, la version liste des ajustements de précision et d’arrondi sur les dépôts, les retraits et les clawbacks. L’objectif est de garder alignés les actifs enregistrés, les actifs disponibles et l’offre de parts lorsque les conversions frôlent les limites de précision. Ce n’est pas glamour. C’est exactement le type de détail qui, négligé, produit des écarts invisibles jusqu’au jour où quelqu’un réclame sa part.

Le trading permissionné reçoit plusieurs reprises. Le paquet exclut les offres de domaine déjà supprimées d’un invariant du DEX permissionné, resserre les contrôles de domaine et corrige le retrait des identifiants expirés lors des transactions OfferCreate ou Payment. La signature, elle, gagne une protection distincte : des préfixes de hash différents pour les signatures de contrepartie et de sponsor, afin qu’une signature créée pour un rôle ne puisse pas être rejouée pour l’autre.

Ces précautions parlent à quiconque a déjà vu, ailleurs, une autorisation mal bornée devenir une clé passe-partout. Sur un registre où les rôles se multiplient, le moindre recyclage de signature est une faille de conception, pas un accident d’implémentation.

Durcissement Des Nœuds En Dehors Du Vote

Tout n’est pas amendement. Les développeurs ont aussi corrigé une recherche de base de données non bornée via TMGetLedger, plafonné la taille des listes TMTransactions entrantes et introduit des frais pour les transactions impossibles à désérialiser. Ce sont des mesures de surface d’attaque et de charge. Elles protègent le nœud avant même que le consensus ne discute d’une nouvelle règle métier.

La version intègre par ailleurs des correctifs de phase un issus d’audits et d’un attackathon autour des MPT et du DEX. Le texte de sortie ne présente pas ces correctifs comme la preuve d’un exploit actif sur le réseau principal. La nuance compte. On répare des chemins identifiés. On ne raconte pas une brèche en production.

Des Paquets Signés Par La Fondation

La 3.4.0 change aussi le tuyau de distribution Linux. Les paquets Debian et RPM sont désormais hébergés via packages.xrplf.org et signés avec une clé de la Fondation XRPL. Les fichiers publiés portent des sommes de contrôle SHA-256. GitHub présente 3.4.0 comme la dernière version immuable d’xrpld, liée au commit 4a4fded2eba11427c48ce3f24d9c1aea5e7a9d17, avec des signatures vérifiées sur l’étiquette et le commit de version.

Les développeurs demandent aux opérateurs d’installer « dès que possible » pour préserver la continuité de service. Derrière la formule, il y a une réalité d’exploitation : un nœud en retard finit par mal parler le réseau, surtout lorsque des chemins de messages et des invariants évoluent. La nouvelle filière de paquets vise aussi à clarifier la provenance. Une signature de Fondation n’élimine pas tout risque. Elle réduit le brouillard sur l’origine du binaire.

Bibliothèques Cliente Et Revue De Sécurité

Le serveur n’avance pas seul. L’historique du client JavaScript de la Fondation place le support de LendingProtocolV1_1 dans la section non publiée, après xrpl.js 5.2.0 sortie le 11 septembre. Le codec binaire 2.11.0 contient déjà les préfixes de signature distincts pour sponsor et contrepartie, ainsi que des définitions de protocole générées à partir d’xrpld 3.4.0. L’écosystème applicatif se met donc en ordre de marche avant même que le vote ne bascule.

Côté sécurité, Sherlock indiquait fin août que Ripple avait lancé un examen uniquement assisté par intelligence artificielle de Lending Protocol V1.1 via son moteur d’audit. Des informations supplémentaires étaient promises après la fin de la revue. Aucun rapport final public de cette passe V1.1 n’a été localisé dans les matériaux consultés pour cette actualité. Une ré-audit antérieure par Halborn, portant sur une version précédente du système de prêt, n’avait pas relevé de problème critique ou élevé, tout en identifiant un constat moyen, deux bas et deux informatifs.

Un audit d’une version n’est pas un sésame pour la suivante. Chaque refonte comptable rouvre la question des invariants.

Lecture prudente des revues publiques

Ce Que Le Prêt Natif N’Est Pas

Il faut dire clairement ce que cette version ne livre pas. Elle ne crée pas, à elle seule, un marché du crédit on-chain mature. Elle ne remplace pas l’analyse de risque humaine ou institutionnelle. Elle ne garantit pas qu’un emprunteur paiera. Elle ne transforme pas XRP en collatéral magique. Le design retenu, tel que décrit, s’appuie sur un pooling via coffre et laisse l’underwriting hors registre. Le protocole transporte des flux et des règles. Il ne juge pas la qualité du dossier.

Cette frontière est saine. Trop de récits DeFi ont vendu le smart contract comme substitut au jugement de crédit. XRPL, ici, refuse ce raccourci. Le registre devient un rail de mise en commun, de calendrier et de règlement. La décision d’accorder un prêt reste un acte économique, pas une fonction hash.

Une Gouvernance Lente Par Conception

Le processus d’amendement XRPL agace parfois. Deux semaines à plus de 80 %, un défaut de vote négatif, des dépendances en cascade : tout cela retarde le moment où un communiqué peut écrire « c’est en production ». Cette lenteur protège aussi contre les bascules précipitées. Un réseau de règlement n’a pas le luxe d’une finance expérimentale qui rollback un week-end.

Les opérateurs de serveurs se retrouvent au milieu. On leur demande d’upgrader vite pour la continuité, tout en leur rappelant que leur binaire ne vote pas à leur place. Cette double injonction n’est pas contradictoire. Mettre à jour, c’est rester interopérable. Voter, c’est juger si la règle nouvelle est mûre. Confondre les deux reviendrait à transformer chaque release en référendum forcé.

Performance, Historique Et Suppression En Ligne

Au-delà des amendements, la note de version évoque des ajustements de stabilité. La suppression en ligne pause désormais en cas de trou dans l’historique de ledger, afin que les nœuds restent plus proches d’un état cohérent. C’est un sujet d’opérateur, rarement mis en une. Pourtant, un nœud qui avance trop vite dans le ménage de son historique pendant qu’il lui manque des ledgers se retrouve à raconter une histoire incomplète.

Ces détails d’exploitation expliquent pourquoi la Fondation insiste sur une installation rapide. Un réseau n’est pas seulement un ensemble de règles votées. C’est aussi une population de machines qui doivent se parler sans se perdre dans les écarts d’historique, les listes trop longues ou les messages mal formés.

Le Contexte Plus Large Du Registre

XRPL a longtemps été lu à travers le prisme des paiements et de la liquidité inter-devises. Les dernières années ont ajouté des couches : AMM, jetons plus riches, lots, frais sponsorisés, transferts confidentiels de MPT, DEX permissionné. Chaque couche agrandit la surface. Chaque couche exige des invariants plus stricts. La 3.4.0 s’inscrit dans cette accumulation. Elle ne réinvente pas le registre. Elle le serre.

Le prêt natif, s’il s’active un jour dans cette forme, ajouterait une brique de crédit à un socle plutôt connu pour le règlement. Ce n’est pas anodin. Un rail de paiement qui se met à porter des cycles d’investissement change le type d’acteurs qu’il attire : courtiers, dépositaires de fonds, équipes de risque, auditeurs. D’où l’insistance sur les périodes fermées et sur la reconnaissance tardive de l’intérêt.

Ce Que Doivent Faire Les Opérateurs

Pour un opérateur de serveur, la check-list est prosaïque. Vérifier les sommes SHA-256. Installer depuis la source signée. Contrôler que le nœud redémarre proprement. Surveiller les écarts d’historique. Décider ensuite, séparément, de la politique de vote. Ne pas laisser le défaut parler à sa place si l’on a un avis. Ne pas croire non plus qu’un oui isolé active quoi que ce soit.

Pour un développeur d’application, le travail est ailleurs : aligner les bibliothèques, comprendre les préfixes de signature, anticiper la coexistence de deux modèles comptables de coffres, et ne pas promettre à un utilisateur un produit de prêt qui n’existe pas encore on-chain. Pour un observateur de marché, le bon réflexe est de séparer le titre « version disponible » du titre « fonctionnalité active ».

• Vérifier l’origine des paquets et leurs empreintes.
• Mettre à jour pour rester compatible avec les durcissements de nœud.
• Configurer le vote au lieu de subir le défaut.
• Suivre les seuils XLS et les deux semaines de consensus.
• Éviter de vendre un prêt natif comme déjà vivant sur le mainnet.

Risques De Lecture Et Effets De Bord Médiatiques

Dans l’écosystème crypto, une note de version devient souvent un récit de bascule. Ici, le récit honnête est plus plat : le code est là, les règles ne le sont pas encore, le vote est bas, le modèle de prêt a été resserré, des invariants ont été durcis, la distribution Linux a été clarifiée. Quiconque transforme cela en « le lending XRPL est lancé » commet une erreur de catégorie.

Cette erreur n’est pas seulement sémantique. Elle oriente des attentes de rendement, des intégrations marketing, parfois des décisions de trésorerie. Un coffre fermé avec reconnaissance de caisse n’est déjà pas un compte à vue. Un amendement non activé n’est même pas encore ce coffre. La pédagogie du processus d’amendement fait donc partie de l’actualité, au même titre que le contenu technique.

Retrait De fixAMMOverflowOffer : Nettoyer Sans Reculer

Retirer un amendement déjà établi peut sembler paradoxal. Dans le modèle XRPL, la retraite ne ramène pas l’ancien monde. Elle enlève un comportement pré-amendement devenu obsolète, une fois les nouvelles règles installées comme norme permanente. fixAMMOverflowOffer quitte donc le catalogue vivant parce que son travail est fini, pas parce que l’on rouvre la faille qu’il fermait.

Ce ménage de catalogue a une vertu documentaire. Moins de propositions fantômes, moins de confusion pour les nouveaux validateurs, moins de code mort à expliquer. Un protocole qui accumule des rustines sans jamais les classer finit par ressembler à un grenier. XRPL choisit, ici, de ranger.

Le Prêt À Terme Face Aux Habitudes DeFi

Beaucoup de lecteurs compareront instinctivement ce design à des protocoles de prêt collatéralisé, liquides, ouverts en permanence. La comparaison éclaire surtout les écarts. Ici, le cycle est fermé. Le collatéral on-chain n’est pas le cœur du récit. L’intérêt n’est plus anticipé comme un produit d’origine. Le courtier s’attache à un coffre cadencé. On est plus proche d’une émission à fenêtre que d’un pool sans fin.

Cette différence peut décevoir qui cherche le rendement instantané. Elle peut rassurer qui cherche un cadre plus proche de la finance de fonds. Rien n’empêche d’autres couches, plus tard, d’inventer de la liquidité secondaire autour de parts de coffre. Pour l’instant, la 3.4.0 ne raconte pas cette suite. Elle pose un moule plus strict.

Une Actualité Technique Qui Parle Aussi De Confiance

Derrière les sigles, la question est simple : peut-on faire confiance à un registre pour porter non seulement des paiements, mais des cycles d’épargne et de crédit ? La réponse ne se joue pas dans un tweet de release. Elle se joue dans les arrondis, les signatures non rejouables, les invariants MPT, les nœuds qui ne s’écroulent pas sous une liste trop longue, et un consensus assez lent pour refuser une règle mal mûre.

La 3.4.0 ne clôt pas cette question. Elle la rend plus sérieuse. Elle montre une équipe qui accepte de republier un modèle de prêt plutôt que de forcer le précédent. Elle montre une Fondation qui signe ses paquets. Elle montre aussi un réseau qui, à l’heure où ces lignes sont écrites, n’a pas encore donné au prêt natif la majorité qualifiée durable.

Calendrier Mental Pour Les Prochaines Semaines

Les jours qui viennent ne se liront pas seulement à l’aune du cours de l’actif. Ils se liront aux compteurs de validateurs, aux notes des bibliothèques clientes, à d’éventuels rapports d’audit V1.1, et à la vitesse à laquelle les opérateurs adoptent les paquets signés. Si les seuils restent bas, la version 3.4.0 n’en sera pas moins utile : elle aura durci des chemins et clarifié une filière de distribution. Si les seuils montent et tiennent deux semaines, alors seulement le récit basculera d’une publication logicielle à une mutation de règles.

En attendant, la formule la plus honnête reste celle-ci. Le XRP Ledger a reçu une version capable de parler le prêt V1.1 et un grand lot de correctifs. Le réseau principal, lui, continue de parler les règles déjà activées. Entre les deux, il y a des humains qui votent, des machines qui se mettent à jour, et un public qui ferait bien de ne pas confondre les uns avec les autres.

Pour Aller Plus Loin Sans Se Perdre

Qui veut suivre le dossier peut se fixer trois questions stables. Les validateurs de confiance franchissent-ils et tiennent-ils 80 % ? Les spécifications sous-jacentes restent-elles en brouillon ou passent-elles un cran plus ferme ? Les revues de sécurité de la V1.1 deviennent-elles publiques et actionnables ? Tant que ces trois réponses restent floues, toute conclusion définitive sur le crédit natif XRPL est prématurée.

La mise à jour du 16 septembre n’en est pas moins un jalon. Elle fixe un vocabulaire : coffres fermés, périodes, caisse, préfixes de rôle, paquets signés. Elle donne aux intégrateurs de quoi préparer leur code. Elle donne aux opérateurs de quoi durcir leurs nœuds. Elle donne aux lecteurs une actualité dense, à condition de la lire comme une étape, pas comme un aboutissement.

Voilà pourquoi cette sortie mérite mieux qu’un titre de bascule. Elle montre un réseau qui avance par amendements, pas par effets d’annonce, et qui accepte que le crédit, s’il doit un jour vivre sur le registre, vive d’abord dans des fenêtres fermées et des chiffres encaissés. Le reste, pour l’instant, n’est que logiciel en attente de vote.