Le XRP Ledger (XRPL) se rapproche de l’activation d’une nouvelle série de correctifs logiciels, prévue pour le 23 octobre 2026 sous réserve du maintien du soutien des validateurs. La proposition fixCleanup3_4_0 a atteint le seuil requis de 29 votes favorables, mais les fonctionnalités de prêt attendues sur le réseau restent soumises à des procédures d’approbation distinctes.
Selon les données du XRPL Dashboard au 19 octobre, 29 des 35 validateurs figurant sur la liste de confiance par défaut soutenaient cette modification. Le réseau impose cependant une période de validation continue de deux semaines avant toute activation.
Cette évolution concerne plusieurs aspects techniques du registre, notamment les transactions de jetons, la comptabilité des coffres, les teneurs de marché automatisés et certains processus associés aux prêts.
En revanche, elle ne signifie pas que le système de crédit natif sera immédiatement disponible. Les propositions LendingProtocol et SingleAssetVault n’ont pas encore obtenu suffisamment de votes.
XRP Ledger vise une activation des correctifs le 23 octobre
La modification fixCleanup3_4_0 a atteint la majorité nécessaire le 9 octobre, déclenchant une période d’attente de 14 jours pendant laquelle le soutien doit rester supérieur à 80 %.
Au 19 octobre, environ neuf jours de cette période s’étaient écoulés. Le tableau de suivi prévoyait son achèvement le 23 octobre vers 9 h 34 UTC.
Cette échéance reste toutefois indicative. Le XRP Ledger examine les décisions relatives aux modifications du protocole à des intervalles spécifiques, appelés flag ledgers.
Selon sa documentation, ces vérifications interviennent tous les 256 registres. Une fois la période réglementaire interne achevée, le réseau enregistre la décision et applique les nouvelles règles dans les registres suivants.
L’activation effective pourrait donc intervenir peu après l’heure annoncée.
Un autre élément rend cette échéance particulièrement sensible : la proposition disposait exactement des 29 votes nécessaires au 19 octobre.
Aucun validateur supplémentaire ne soutenait alors la modification au-delà du minimum requis. Le retrait d’un seul vote ferait repasser le soutien sous le seuil d’approbation.
Dans cette situation, la période de deux semaines devrait recommencer lorsque la majorité serait rétablie.
Le 23 octobre représente ainsi une date d’activation projetée, et non une confirmation définitive.
Les opérateurs doivent préparer leurs serveurs
L’approbation des modifications concerne également les exploitants de serveurs du XRP Ledger.
Les opérateurs doivent utiliser une version du logiciel capable de reconnaître les amendements approuvés. Lorsqu’un réseau commence à appliquer de nouvelles règles, les serveurs exécutant une ancienne version incompatible peuvent devenir bloqués par amendement.
Les développeurs ont publié la version 3.4.0 du logiciel serveur xrpld le 16 septembre.
Ils ont recommandé aux opérateurs de procéder à la mise à niveau afin de maintenir la compatibilité avec les modifications prévues.
Cette version contient les corrections techniques associées à fixCleanup3_4_0 ainsi que des éléments nécessaires aux futures fonctionnalités de prêt.
La publication du logiciel ne suffit cependant pas à rendre automatiquement toutes ses nouvelles règles applicables sur le réseau principal.
Chaque modification soumise au mécanisme de gouvernance doit suivre son propre processus d’approbation.
Le protocole de prêt manque encore de dix votes
Le système de prêt natif du XRP Ledger reste en attente malgré les progrès réalisés sur les correctifs.
Au 19 octobre, la proposition LendingProtocol, également appelée XLS-66, disposait de 19 votes favorables parmi les 35 validateurs de confiance.
Elle devait encore obtenir dix soutiens supplémentaires pour atteindre le seuil de 29.
La proposition complémentaire SingleAssetVault, ou XLS-65, comptait 21 votes favorables. Il lui en manquait donc huit.
Ces deux modifications sont nécessaires au fonctionnement du système de prêt prévu sur le réseau principal.
Elles doivent également conserver le soutien requis pendant deux semaines consécutives avant leur activation.
Même si elles obtenaient immédiatement les votes manquants, elles ne pourraient donc pas entrer en vigueur en même temps que les correctifs attendus le 23 octobre.
Cette distinction est importante : les corrections techniques progressent, mais le calendrier de lancement des services financiers reste indépendant.
LendingProtocolV1_1 propose des changements supplémentaires
Une troisième proposition, LendingProtocolV1_1, comptait également 19 votes favorables au 19 octobre.
Introduite avec xrpld 3.4.0, elle prévoit des ajustements concernant la conception des coffres de prêt et la comptabilisation des intérêts.
Le projet imposerait notamment aux nouveaux courtiers de prêt d’utiliser des coffres fermés.
Dans ce modèle, les dépôts, les prêts et les retraits suivent des étapes définies.
Le fonctionnement serait organisé en trois périodes : souscription, investissement et remboursement.
La proposition modifierait également la reconnaissance des revenus d’intérêts.
Au lieu d’enregistrer l’ensemble des intérêts programmés dès l’ouverture d’un prêt, le système comptabiliserait les revenus lorsque les emprunteurs effectuent réellement leurs paiements.
Ces changements restent soumis à l’approbation des validateurs.
La version logicielle publiée en septembre prépare donc certaines évolutions, sans autoriser leur utilisation immédiate sur le réseau principal.
Comment fonctionneraient les prêts sur XRP Ledger ?
Le système proposé repose sur des coffres partagés alimentés par les déposants.
Les utilisateurs pourraient placer des actifs dans un coffre commun, tandis qu’un courtier organiserait des prêts à durée déterminée à partir des fonds disponibles.
Le registre enregistrerait les obligations de remboursement, les paiements et les transactions associées.
Une particularité importante concerne les garanties.
Les emprunteurs ne seraient pas obligés de déposer directement des garanties dans le protocole.
L’évaluation de leur solvabilité serait confiée aux courtiers, qui examineraient leur situation financière et leur capacité de remboursement en dehors de la blockchain.
Ces intermédiaires détermineraient quels emprunteurs peuvent accéder aux financements et selon quelles conditions.
Le système ne supprimerait donc pas l’évaluation du risque de crédit. Il placerait cette responsabilité entre les mains des courtiers.
La conception vise notamment des activités de prêt institutionnel utilisant XRP et d’autres actifs éligibles émis sur le registre.
Ripple soutient le développement de ces propositions dans le cadre de ses activités auprès des institutions financières.
Un mécanisme facultatif pour absorber certaines pertes
Le protocole envisagé comprend une protection facultative appelée first-loss capital.
Un courtier pourrait placer des actifs supplémentaires dans un compte distinct afin de contribuer à couvrir les pertes lorsqu’un emprunteur ne rembourse pas son prêt.
Cette protection dépendrait du montant effectivement disponible.
Elle ne garantirait pas aux déposants la récupération intégrale de leurs fonds en cas de défaut.
La documentation du XRP Ledger précise également que le protocole ne prévoit actuellement ni gestion automatique des garanties sur la blockchain ni liquidation automatique.
Les courtiers auraient la possibilité de déclarer un prêt en défaut après un paiement manqué et l’expiration du délai de grâce applicable.
Le fonctionnement proposé combine ainsi l’enregistrement des opérations sur le registre avec une analyse du risque réalisée en dehors de celui-ci.
Il reste nécessaire de distinguer ce modèle théorique des fonctionnalités déjà activées sur le réseau.
Ripple soutient les propositions, mais le vote reste nécessaire
Ripple a apporté son soutien aux deux principales modifications relatives aux prêts par l’intermédiaire de son validateur en août.
À cette date, elles se situaient toujours sous le seuil nécessaire à leur activation.
Le développement a également fait l’objet d’un nouvel audit de sécurité en juin.
Cette réévaluation, réalisée par l’entreprise de cybersécurité Halborn, n’a relevé aucune anomalie critique ou présentant un risque élevé parmi les changements examinés.
Ce résultat ne constituait cependant ni une approbation du réseau ni une garantie contre d’éventuels problèmes logiciels futurs.
La décision d’activer les nouvelles règles dépend toujours du mécanisme de vote des validateurs.
Au 19 octobre, les chiffres montraient que le paquet de maintenance progressait plus rapidement que les fonctionnalités financières qu’il contribue partiellement à préparer.
Les correctifs ciblent les transactions et les coffres
Les notes de publication de xrpld 3.4.0 détaillent plusieurs corrections incluses dans fixCleanup3_4_0.
L’une concerne les teneurs de marché automatisés.
Elle empêche certaines transactions de récupération de détruire les jetons représentant la participation d’un utilisateur à la liquidité lorsque les règles d’arrondi aboutiraient à une récupération nulle des actifs sous-jacents.
D’autres changements corrigent les calculs utilisés lors des dépôts et des retraits dans les coffres.
Ils visent à maintenir la cohérence entre les soldes d’actifs détenus et le nombre de parts attribuées aux déposants.
Ces ajustements concernent donc directement la précision comptable des opérations effectuées sur le registre.
Leur application dépend néanmoins de l’activation de la modification correspondante.
Les règles de prêt et de signature sont également concernées
Les développeurs ont aussi modifié plusieurs règles associées aux prêts.
Les corrections portent notamment sur les autorisations, les actifs gelés, les identifiants et les destinations de paiement.
Les notes techniques mentionnent également les interactions entre les défauts de remboursement et le gel des actifs, ainsi que les contrôles appliqués aux retraits depuis des coffres soumis à autorisation.
D’autres ajustements concernent les transactions sur les plateformes d’échange décentralisées permissionnées, les offres de NFT et le traitement des séquestres.
Une correction liée aux signatures introduit des préfixes cryptographiques distincts selon les rôles.
Son objectif est d’empêcher qu’une signature destinée à une fonction soit réutilisée dans une autre.
La mise à jour renforce également les restrictions applicables à certaines transactions de jetons et rend obligatoires des vérifications auparavant uniquement consignées dans les journaux logiciels.
Ces règles ne deviendront exécutoires sur le réseau principal qu’après l’activation des amendements correspondants.
Une mise à jour technique distincte du lancement des prêts
La version 3.4.0 modifie aussi la distribution des logiciels serveur compatibles.
Des paquets d’installation Linux signés sont désormais fournis par la XRPL Foundation, dont l’avis de publication recommande aux opérateurs de mettre leurs serveurs à niveau.
Au 19 octobre, le XRP Ledger se trouvait donc face à deux calendriers distincts.
Le premier concerne fixCleanup3_4_0, qui a atteint exactement les 29 votes nécessaires et pourrait entrer en vigueur le 23 octobre si cette majorité est conservée.
Le second concerne le protocole de prêt et ses coffres, qui n’ont pas encore obtenu suffisamment de soutiens.
LendingProtocol manque toujours de dix votes et SingleAssetVault de huit.
La prochaine étape immédiate concerne ainsi la confirmation de l’activation des correctifs, tandis que le lancement des prêts dépendra de nouvelles approbations et du respect de leur propre période d’attente.
