
- XRPL 3.0.0 introduit TokenEscrowV1 pour corriger la comptabilité séquestre MPT avec frais de transfert, empêchant ainsi la dérive de l'offre LockedAmount.
- L’amendement nécessite l’approbation du validateur pour être activé, garantissant ainsi un comportement cohérent d’achèvement du dépôt sur tous les nœuds du réseau.
Ripple a publié XRP Ledger version 3.0.0 et a exhorté les validateurs et les opérateurs de nœuds à mettre à niveau sans délai. Le libérer cible un bug de comptabilité séquestre trouvé lors des tests internes du séquestre de jetons pour les actifs émis. Ripple a déclaré que le correctif prend en charge un comportement de règlement cohérent lorsque les institutions utilisent la livraison de jetons verrouillée dans le temps ou basée sur des conditions sur XRPL.
Pourquoi est-ce crucial pour le grand livre XRP
Escrow est un engagement de longue date XRPL fonction utilisée pour les transactions planifiées et les libérations conditionnelles. Historiquement, il a fonctionné uniquement avec XRP, ce qui limitait la manière dont les émetteurs pouvaient utiliser le dépôt pour leurs propres jetons. La proposition XLS-85 Token Escrow étend le séquestre à d'autres actifs émis, y compris les reconnaissances de dette et les jetons polyvalents, permettant une livraison séquestre au-delà de XRP pour les flux de travail d'entreprise.
PSA : La version 3.0.0 de XRPL est disponible et nous encourageons tous les validateurs et opérateurs de nœuds à effectuer la mise à niveau dès que possible pour garantir la continuité du service. ✅
Cette dernière version comprend plusieurs modifications de correctifs, y compris un correctif pour TokenEscrow, sur lequel vous pouvez en apprendre davantage…
– RippleX (@RippleXDev) 5 janvier 2026
Les jetons polyvalents sont un format de jeton natif XRPL qui mélange des propriétés fongibles et non fongibles. Ils peuvent comporter des caractéristiques partagées tout en stockant en chaîne des métadonnées spécifiques à des actifs. Les développeurs les décrivent comme étant adaptés à la tokenisation de conformité, car ils peuvent intégrer des règles et gérer le cycle de vie sans recourir à des contrats intelligents externes pour les contrôles de base.
Les testeurs internes de la conception originale de Token Escrow, qui n'a pas été activé sur le réseau principal, ont identifié une inadéquation comptable pour les jetons polyvalents qui facturent des frais de transfert.
Dans un cas de test, un séquestre a verrouillé cent jetons et appliqué des frais de transfert d'un jeton au déverrouillage. Le destinataire a correctement reçu quatre-vingt-dix-neuf jetons après application des frais. Cependant, la comptabilité de l'émetteur a réduit le LockedAmount de quatre-vingt-dix-neuf au lieu de cent. Un jeton est resté enregistré comme verrouillé une fois terminé, ce qui aurait pour effet de désynchroniser les mesures de l'émetteur au fil du temps.
TokenEscrowV1 sépare le séquestre brut de la livraison nette
La version 3.0.0 inclut l'amendement TokenEscrowV1, qui modifie la façon dont le grand livre traite la finalisation du dépôt pour les jetons polyvalents payants. L’amendement sépare la comptabilité séquestre brute de la comptabilité des livraisons nettes.
Lorsqu'un séquestre se termine, LockedAmount diminue désormais du montant total initialement placé dans le séquestre, revenant à son niveau d'avant le séquestre. Les frais de transfert sont traités indépendamment via le mécanisme de frais de l'émetteur, de sorte que seul le montant net livré affecte le calcul de l'offre en cours. Le mécanisme de frais de transfert de l'émetteur comptabilise le montant des frais séparément.
Le réseau a déclaré que cette approche empêche les jetons de rester bloqués dans un état verrouillé une fois le dépôt terminé et maintient les métriques LockedAmount de l'émetteur alignées sur l'état du grand livre. Il a lié le correctif aux flux de travail de tokenisation institutionnels qui dépendent d'une comptabilité séquestre précise, y compris les paiements programmés, et aux opérations de trésorerie automatisées qui utilisent des actifs émis avec des frais de transfert.
Étant donné que TokenEscrowV1 modifie le traitement principal du grand livre, il nécessite une activation via un vote d'amendement. Les validateurs doivent approuver l'amendement pour garantir que les nœuds appliquent les mêmes règles d'achèvement du dépôt fiduciaire sur l'ensemble du réseau. Ripple a demandé aux opérateurs de passer à la version 3.0.0 afin que les implémentations restent compatibles à mesure que le réseau progresse vers l'activation.
La nouvelle version 3.0.0 de XRP Ledger est arrivée des semaines après Ripple étendu sa présence au Japon à travers le Japan Financial Infrastructure Innovation Program, en partenariat avec Asia Web3 Alliance Japan et Web3 Salon.
Au moment de la rédaction de cet article, le XRP se négociait à 2,33 $ après il s'est rallié 9,34% au cours des dernières 24 heures.
Voir l’article original en anglais
