Et si la plus grande nouveauté du XRP Ledger n’était pas encore active, même après une mise à jour majeure ? Le 16 septembre 2026, les développeurs ont publié xrpld 3.4.0. Le code embarque deux paquets d’amendements : une refonte du prêt natif et un lot de correctifs qui durcit des dizaines de chemins de transaction. Les opérateurs de serveurs sont invités à installer la version sans attendre. Sur le mainnet, pourtant, rien ne bascule tout seul. Le réseau attend toujours un consensus durable des validateurs de confiance.
Ce Que Change Vraiment La Version 3.4.0
La note officielle est claire. La 3.4.0 introduit LendingProtocolV1_1 et fixCleanup3_4_0. Elle retire aussi fixAMMOverflowOffer, devenu inutile une fois son comportement intégré de façon permanente. Installer le logiciel ne revient pas à activer les nouvelles règles. Le processus d’amendement exige plus de 80 % de soutien des validateurs de confiance, maintenu sans interruption pendant deux semaines.
Cette distinction explique beaucoup de malentendus. Un dépôt GitHub peut afficher une version « latest ». Les nœuds peuvent déjà comprendre les nouvelles instructions. Les règles économiques, elles, restent celles d’hier tant que le vote n’atteint pas le seuil. C’est précisément le cas des fondations du prêt natif, encore loin de l’activation.
À retenir avant de continuer
La 3.4.0 livre le code. L’activation dépend d’un vote long. Les vaults fermés et la comptabilité de caisse ne s’appliquent qu’après consensus. Les opérateurs, eux, sont pressés de mettre à jour pour la continuité de service.
Le Prêt V1.1 Recadre Les Vaults Et La Comptabilité
LendingProtocolV1_1 revoit la conception des Single Asset Vaults et du protocole de prêt. L’idée centrale est le vault à horizon fermé. Il possède trois phases distinctes : souscription, investissement, puis rachat. Pendant la souscription, les déposants peuvent ajouter ou retirer des actifs. Pendant l’investissement, les flux s’arrêtent et les fonds peuvent financer des prêts. Le rachat s’ouvre une fois la période d’investissement terminée, afin que chaque déposant récupère sa part après maturité des prêts.
Une fois l’amendement actif, les nouveaux courtiers de prêt ne pourraient s’attacher qu’à des vaults fermés. Les relations déjà ouvertes sous les règles antérieures recevraient un traitement distinct, pour continuer à gérer les positions en cours. Le changement n’est donc pas une table rase. Il isole le passé et verrouille le futur.
Les nouveaux vaults ne reconnaîtraient les intérêts que lorsque l’emprunteur paie réellement. L’intérêt futur non encaissé resterait hors du revenu du vault.
C’est le passage à une comptabilité de caisse. L’ancien modèle reconnaissait tout l’intérêt programmé dès l’origine du prêt. Le nouveau modèle change le calcul de AssetsTotal, de la dette du prêt et du traitement des défauts. Les vaults créés avant V1.1 conserveraient leur modèle comptable. Pas de conversion rétroactive.
Pourquoi Cette Architecture Semblait Inevitable
Un prêt à terme fixe, non collatéralisé, financé par une réserve unique, pose un problème de calendrier. Si tout le monde peut entrer et sortir pendant que les fonds sont déjà prêtés, le vault devient un objet instable. Les phases fermées réduisent ce risque de liquidité interne. Elles rendent aussi plus lisible le moment où un déposant peut raisonnablement espérer récupérer son capital.
La comptabilité de caisse répond à un autre piège. Compter des intérêts qui n’ont jamais été versés gonfle artificiellement la santé apparente du vault. En cas de défaut, l’écart entre papier et cash devient brutal. Reconnaître le revenu au moment du paiement aligne davantage les chiffres affichés et l’argent réellement disponible.
Le sous-jacent reste décrit dans les spécifications XLS-65 et XLS-66. XLS-66 présente un prêt à terme fixe, non collatéralisé, alimenté par des vaults mono-actif. L’analyse de crédit et la souscription de l’emprunteur restent hors chaîne. La spécification est encore classée comme brouillon. Aucune source consultée pour cette actualité n’a montré un prêt mainnet exécuté via ce protocole natif, ni une date d’activation de LendingProtocolV1_1.
Le Vote Des Validateurs Reste Le Verrou
Dès août, le validateur de Ripple avait déjà voté en faveur des propositions SingleAssetVault et LendingProtocol. Le soutien global restait largement sous le seuil. Un instantané du 17 septembre, établi à partir de l’historique des validateurs de la fondation XRPL, montrait 16 validateurs de confiance sur 35 favorables à SingleAssetVault, et 13 sur 35 favorables à LendingProtocol. Ces chiffres bougent. Ils ne figurent pas comme constante dans les notes de version. La règle officielle, elle, ne bouge pas : plus de 80 % pendant deux semaines continues.
La liste des fonctionnalités de la fondation marque LendingProtocolV1_1 et fixCleanup3_4_0 comme supportés, avec un comportement de vote DefaultNo. Installer le logiciel ne jette donc pas un oui automatique si l’opérateur n’a rien configuré. C’est une précaution politique autant que technique. Le réseau refuse de transformer une mise à jour logicielle en plébiscite silencieux.
| Élément | État observé |
|---|---|
| xrpld 3.4.0 | Publié le 16 septembre 2026 |
| LendingProtocolV1_1 | Code présent, activation non effective |
| fixCleanup3_4_0 | Correctifs groupés, même logique de vote |
| SingleAssetVault | 16 / 35 validateurs de confiance |
| LendingProtocol | 13 / 35 validateurs de confiance |
| Seuil officiel | Plus de 80 % pendant deux semaines |
fixCleanup3_4_0 Durcit Une Longue Liste De Chemins
Le second amendement n’est pas un gadget. Il rassemble des corrections qui touchent le prêt, les vaults, les teneurs de marché automatiques, les Multi-Purpose Tokens, les NFT, l’escrow, le trading permissionné et l’autorisation de compte. L’intention est de rendre les invariants plus durs, surtout aux frontières d’arrondi et de suppression d’objets.
Un correctif empêche AMMClawback 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. Autre renforcement : les contrôles ValidMPTBalanceChanges et ValidMPTTransfer, auparavant limités à des journaux, deviennent réellement appliqués sous l’amendement, y compris quand une transaction échoue.
Pour les vaults mono-actif, la version liste des changements 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 d’actions en circulation lorsque les conversions touchent les limites de précision. Ces détails paraissent arides. Ils sont exactement le genre de faille qui, sur un registre, se transforme en incohérence comptable durable.
Trading Permissionné, Signatures Et Rôles Distincts
Le trading permissionné reçoit plusieurs corrections. 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. L’idée est d’éviter qu’un objet mort continue d’influencer une règle de validité.
Le comportement de signature gagne une barrière supplémentaire. La 3.4.0 attribue des préfixes de hash différents aux signatures de contrepartie et de sponsor. Une signature créée pour un rôle ne peut plus être rejouée pour l’autre. C’est un classique de la sécurité des protocoles : séparer les contextes pour empêcher le recyclage d’une preuve.
Le codec binaire 2.11.0 contient déjà ces préfixes spécifiques, ainsi que des définitions de protocole générées à partir de xrpld 3.4.0. Côté bibliothèque JavaScript, le support de LendingProtocolV1_1 apparaît dans la section non publiée après xrpl.js 5.2.0, sortie le 11 septembre. Les applications suivent le serveur, avec un léger décalage, ce qui est habituel lors d’un cycle d’amendements.
Le Durcissement Des Nœuds Hors Amendement
Tout n’attend pas le vote. La version contient un durcissement de bas niveau, hors paquet d’amendement. Les développeurs ont 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. Ces mesures visent la stabilité opérationnelle plus que le changement de règles métier.
Les équipes indiquent aussi que la 3.4.0 intègre des correctifs de phase un issus d’un audit et d’un attackathon portant sur les MPT et le DEX. La note ne présente pas ces correctifs comme la preuve d’un exploit actif sur le mainnet. La nuance compte. Une revue de sécurité n’équivaut pas à une brèche publique.
La suppression en ligne pause désormais en cas de trou dans l’historique de ledger, afin que les nœuds restent plus proches de la chaîne utile. C’est un détail d’exploitation. Pour un opérateur, c’est souvent plus concret qu’un amendement encore inactif : moins de dérive, moins de rattrapage douloureux, moins de surprise au redémarrage.
Les Paquets Linux Changent De Circuit De Distribution
La 3.4.0 modifie le chemin de distribution des paquets Linux. Les fichiers Debian et RPM passent par packages.xrplf.org et sont signés avec une clé de la XRPL Foundation. Les développeurs demandent aux opérateurs d’installer « dès que possible » pour préserver la continuité de service. Les fichiers publiés incluent des sommes SHA-256, afin de vérifier le téléchargement avant installation.
GitHub présente 3.4.0 comme la dernière version immutable de xrpld, liée au commit 4a4fded2eba11427c48ce3f24d9c1aea5e7a9d17. L’étiquette de version et le commit portent des signatures vérifiées. Ce déplacement vers la fondation n’est pas cosmétique. Il clarifie qui signe quoi, et réduit l’ambiguïté lorsqu’un opérateur doit décider s’il fait confiance à un binaire.
Retirer fixAMMOverflowOffer s’inscrit dans le même esprit de ménage. Dans le modèle d’amendement du registre, la retraite ne revient pas sur le correctif. Elle enlève un comportement pré-amendement devenu obsolète, une fois les nouvelles règles installées comme comportement permanent du protocole.
Ce Que La 3.3.0 Avait Déjà Préparé
La version précédente avait déjà introduit le code de plusieurs propositions séparées : fonctionnalité Batch corrigée, frais sponsorisés, transferts MPT confidentiels. Là encore, l’approbation des validateurs restait nécessaire avant activation. La 3.4.0 s’ajoute à cette accumulation. Le registre avance par couches. Le logiciel précède presque toujours la politique du réseau.
Cette cadence crée une impression étrange pour le public. On lit « prêt natif » et l’on imagine des marchés déjà ouverts. On lit « Batch » et l’on imagine des transactions groupées partout. En pratique, une part importante du code circule d’abord comme potentiel. Le potentiel n’est pas encore la règle. Cette discipline est lente. Elle évite aussi qu’une minorité d’opérateurs impose un basculement économique à tout le monde.
Sécurité, Revues Et Zones Encore Ouvertes
Les tests de sécurité du travail de prêt ont continué séparément du vote. Sherlock a indiqué le 27 août que Ripple avait lancé un examen uniquement assisté par intelligence artificielle du Lending Protocol V1.1 via son moteur d’audit. Davantage d’informations devaient suivre la fin de la revue. Aucun rapport final V1.1 n’a été localisé dans les matériaux publics vérifiés pour cette actualité.
Des tests plus anciens portaient sur une version précédente du système de prêt. Une ré-audit antérieure de Halborn n’avait pas trouvé de problème critique ou de risque élevé, tout en identifiant un constat moyen, deux bas et deux informatifs. Ce n’est pas un blanc-seing pour V1.1. C’est un historique. Les vaults fermés et la comptabilité de caisse changent assez de surface pour justifier une nouvelle lecture attentive.
Le crédit hors chaîne reste le point le plus politique. Le protocole peut comptabiliser, encadrer les phases et figer des invariants. Il ne décide pas, à lui seul, qui mérite un prêt non collatéralisé. Cette séparation protège le registre d’un rôle qu’il n’est pas conçu pour jouer. Elle laisse aussi aux courtiers une responsabilité que le code ne peut pas absorber.
Ce Que Les Opérateurs Doivent Faire Maintenant
Pour un opérateur de nœud, la priorité n’est pas philosophique. Elle est opérationnelle. Installer 3.4.0, vérifier les signatures, contrôler les sommes SHA-256, puis surveiller les journaux après bascule. Le DefaultNo évite de voter oui par accident. Si l’opérateur souhaite soutenir un amendement, il doit le dire explicitement dans la configuration.
Pour un développeur d’application, le calendrier est différent. Il faut anticiper les nouveaux préfixes de signature, les invariants MPT plus stricts et, plus tard, les vaults fermés. Intégrer trop tôt une logique métier qui n’est pas encore active crée des interfaces fantômes. Intégrer trop tard expose à des rejets une fois le seuil atteint. Le bon rythme consiste à supporter le code, tout en gardant des interrupteurs liés à l’état réel des amendements.
Pour un observateur de marché, la leçon est plus simple encore. Une mise à jour majeure n’est pas un catalyseur automatique. Elle peut le devenir si le vote suit. Elle peut aussi rester longtemps un catalogue de possibilités. Les chiffres de septembre montrent que le prêt natif n’a pas encore cette majorité qualifiée.
Les Risques Qu’On Sous-Estime Souvent
Le premier risque est sémantique. Parler de « prêt natif » laisse croire à un marché monétaire déjà liquide, standardisé, comparable à une application DeFi mature. Or le modèle décrit reste un prêt à terme, non collatéralisé, avec souscription humaine hors chaîne. Le registre fournit le cadre. Il ne fabrique pas, à lui seul, la demande ni la qualité de crédit.
Le deuxième risque est comptable. Même avec la caisse, un vault peut afficher une apparente stabilité pendant l’investissement, puis révéler des écarts au moment du rachat. Les phases fermées réduisent les allers-retours opportunistes. Elles n’abolissent pas le défaut. Elles le rendent simplement plus visible à un moment précis, plutôt que de le diluer dans des flux quotidiens.
Le troisième risque est opérationnel. Un opérateur qui tarde à mettre à jour peut se retrouver désaligné lorsque d’autres nœuds adoptent des durcissements hors amendement, ou lorsque le réseau commence enfin à voter. Les plafonds de listes, les frais sur charges non désérialisables et la pause de suppression en ligne existent précisément pour limiter les comportements pathologiques. Rester en arrière, c’est accepter une surface plus ancienne.
Une Lecture Plus Large Du Cycle XRPL
Le XRP Ledger a longtemps été perçu comme un réseau de règlement rapide, plutôt que comme une plateforme de crédit. Le travail sur les vaults et le prêt cherche à élargir cette identité sans casser la discipline d’amendement. Chaque brique passe par un vote long. Chaque correctif sensible est groupé. Chaque retraite d’amendement ancien sert à nettoyer le langage du protocole.
Cette méthode contraste avec des écosystèmes où une mise à jour de contrat peut changer les règles du jour au lendemain. Ici, le temps politique des validateurs est une fonctionnalité. Il frustre ceux qui veulent un calendrier marketing. Il protège ceux qui opèrent des infrastructures qui ne peuvent pas se permettre une bascule improvisée.
Les MPT, le DEX permissionné, l’escrow et les signatures à rôles séparés montrent la même obsession : réduire les ambiguïtés aux bords. Un protocole mature se juge moins à ses slogans qu’à sa façon de traiter l’arrondi, l’objet supprimé, la signature rejouable, la liste trop longue. La 3.4.0 est, de ce point de vue, davantage un travail d’orfèvre qu’une révolution spectaculaire.
Ce Qu’il Faudra Surveiller Dans Les Semaines Qui Viennent
Le premier indicateur reste le tableau des votes. Si SingleAssetVault et LendingProtocol stagnent sous 80 %, V1.1 restera un texte dans le code. Si le soutien grimpe et tient deux semaines, le calendrier des vaults fermés deviendra concret. Le second indicateur est l’adoption réelle de 3.4.0 chez les opérateurs, visible à travers la distribution des versions plutôt qu’à travers les communiqués.
Le troisième indicateur sera la documentation client. Tant que xrpl.js présente le support V1.1 comme non publié, les intégrateurs avanceront avec prudence. Le quatrième sera la publication, ou non, des conclusions de la revue V1.1. Un silence prolongé n’invalide pas le travail. Il laisse toutefois un angle mort pour quiconque voudrait déployer un courtier dès l’activation.
Enfin, il faudra distinguer les prêts éventuellement conclus hors de ce cadre natif et ceux qui utiliseraient vraiment XLS-66 une fois actif. Aujourd’hui, l’absence de prêt mainnet via le protocole proposé est un fait d’observation. Demain, le premier dossier réellement exécuté pèsera plus que dix notes de version.
Une Mise À Jour Utile, Pas Encore Un Marché Ouvert
La version 3.4.0 du XRP Ledger fait ce qu’une bonne version d’infrastructure doit faire. Elle livre le code du prêt V1.1, elle durcit des invariants, elle change le circuit de paquets Linux, elle demande aux opérateurs d’agir vite. Elle ne transforme pas, à elle seule, le mainnet en place de marché du crédit. Entre le binaire signé et la règle active, il reste un vote, deux semaines, et un seuil que le réseau n’a pas encore tenu.
Ceux qui suivent le registre de près gagneront à lire cette actualité ainsi : un progrès de protocole, un appel à la discipline opérationnelle, et un rappel que le crédit natif, s’il arrive, arrivera selon les règles lentes du consensus, pas selon le rythme d’une publication GitHub. Le code est là. La suite dépend désormais des validateurs, et de ce qu’ils accepteront de rendre permanent.
