La branche de développement de XRPL répertorie désormais LendingProtocolV1_2, un nouvel amendement qui n’est pas encore pris en charge et qui vient s’ajouter à LendingProtocolV1_1 et à l’entrée LendingProtocol d’origine. Les travaux sur les normes associés proposent un changement important dans la manière dont les prêts sont créés : leur configuration et leur acceptation seraient gérées au moyen de transactions distinctes avant qu’un prêt ne devienne actif.
Cet ajout indique une nouvelle révision préalable au lancement de l’implémentation des prêts du XRP Ledger, plutôt qu’une extension de ses fonctionnalités phares. Les travaux sont toujours en cours de développement, et la présence de cet élément dans la branche ne prouve ni son déploiement ni son activation sur le registre.
LendingProtocolV1_2 figure dans la branche de développement XRPL
La fonctionnalité figure dans les définitions des fonctionnalités de la branche de développement XRPLF/rippled sous le nom LendingProtocolV1_2. Sa position au-dessus des amendements antérieurs V1_1 et LendingProtocol d’origine montre clairement que la base de code suit des révisions successives du protocole de prêt.
La désignation « pas encore pris en charge » est essentielle pour comprendre le statut à court terme de V1_2. Bien que l’amendement soit en préparation en tant que modification du protocole, il n’a pas encore atteint le statut de déploiement pris en charge dans la branche citée ; les amendements sont le mécanisme utilisé pour représenter les modifications du protocole XRPL dans la base de code rippled.
Le nom suggère également un processus itératif. Plutôt que de remplacer le projet de prêt par une proposition sans rapport, V1_2 fait suite à l’amendement d’origine et à V1_1 dans le cadre d’une série de révisions consacrées aux prêts.
Deux transactions séparent la mise en place du prêt de son acceptation
Selon les travaux de normalisation XLS-65/66, LendingProtocolV1_2 introduit la création de prêts en deux étapes. Une transaction LoanSet proposée établirait le prêt, tandis que LoanAccept l’accepterait séparément ; le prêt ne deviendrait actif qu’après cette étape d’acceptation.
Cette séparation constitue la principale amélioration fonctionnelle associée à V1_2. Elle modifie la séquence par laquelle un prêt proposé devient actif, en distinguant la création des conditions du prêt, ou sa mise en place, de l’acte ultérieur de son acceptation.
Un rapport indépendant de Coin Brief a lui aussi décrit l’amendement comme un travail visant à perfectionner la mise en œuvre des prêts avant son lancement, en mentionnant la création des prêts en deux étapes et des modifications connexes aux transactions de prêt. La proposition de normalisation reste toutefois la source de référence principale pour la structure des transactions décrite.
Ce processus en deux temps pourrait être particulièrement pertinent pour la façon dont le protocole détermine à quel moment un accord devient un prêt actif, même si les documents disponibles ne précisent pas de calendrier définitif de lancement ni n’établissent que la forme actuelle de la proposition est définitive.
Le développement porte sur les domaines des courtiers et la comptabilité des coffres
Une comparaison avec un miroir INFTF répertorie les modifications apportées à rippled jusqu’au 14 octobre pour LendingProtocolV1_2. Ces modifications ont ajouté et testé un comportement soumis à une activation conditionnelle pour les domaines des courtiers en prêts, une comptabilité des coffres à précision fixe et le flux de transactions LoanSet/LoanAccept en deux étapes.
Ce relevé montre que V1_2 est à la fois un projet de mise en œuvre et une proposition de normalisation. Son mécanisme d’activation conditionnelle lie le comportement des domaines des courtiers à l’amendement, tandis que les travaux comptables couvrent les calculs liés aux prêts et aux coffres.
Les relevés ne quantifient pas l’effet des modifications comptables sur les utilisateurs ou les fournisseurs de liquidité. Ils ne font pas non plus état d’un déploiement en production ; la branche de développement indique toujours que LendingProtocolV1_2 n’est pas encore pris en charge.
L’amendement prolonge le déploiement progressif du protocole de prêt
L’amendement LendingProtocol d’origine a été intégré à rippled 3.1.0, publié en janvier 2026. Les versions suivantes ont apporté d’autres correctifs aux prêts et aux coffres, établissant une progression par étapes pour le protocole plutôt qu’une mise en œuvre unique et figée.
LendingProtocolV1_2 ajoute maintenant une nouvelle étape distincte : un amendement séparé, une proposition de normalisation pour la création de prêts en deux étapes et des travaux de mise en œuvre portant sur les domaines des courtiers, la comptabilité des coffres et les tests du flux de transactions. Cette séquence concorde avec les registres de versions et de développement fournis, qui montrent que la fonctionnalité de prêt a continué d’être ajustée après son introduction initiale.
Pour les participants XRPL qui suivent cette fonctionnalité, le principal élément à surveiller est de voir si V1_2 progresse au-delà de son statut actuel, qui est de ne pas être pris en charge. Dans les documents de code et de normalisation disponibles, son objectif actuel est clairement circonscrit : réviser le processus de création des prêts et intégrer les correctifs de mise en œuvre associés avant que le système de prêt n’évolue davantage.
Avertissement : Cet article est fourni à titre informatif uniquement. Il ne constitue pas un conseil juridique, fiscal, en investissement, financier ou autre, et n’est pas destiné à être utilisé comme tel.