XRPL corrige un bug d'Escrow impactant les flux de travail de tokenisation institutionnelle

• XRPL 3.0.0 introduit TokenEscrowV1 pour corriger la comptabilité de l'escrow MPT avec les frais de transfert, empêchant la dérive de l'approvisionnement LockedAmount.
• L'amendement nécessite l'approbation des validateurs pour être activé, garantissant un comportement cohérent de finalisation de l'escrow sur tous les nœuds du réseau.

Ripple a publié la version 3.0.0 du XRP Ledger et a exhorté les validateurs et les opérateurs de nœuds à effectuer la mise à niveau sans délai. La version cible un bug de comptabilité d'escrow découvert lors des tests internes de l'escrow de tokens pour les actifs émis. Ripple a déclaré que la correction prend en charge un comportement de règlement cohérent lorsque les institutions utilisent une livraison de tokens verrouillée dans le temps ou basée sur des conditions sur XRPL.

Pourquoi C'est Crucial Pour Le XRP Ledger

L'escrow est une fonction XRPL de longue date utilisée pour les transactions planifiées et les libérations conditionnelles. Elle a historiquement fonctionné uniquement avec XRP, ce qui limitait la manière dont les émetteurs pouvaient utiliser l'escrow pour leurs propres tokens. La proposition XLS-85 Token Escrow étend l'escrow à d'autres actifs émis, y compris les IOUs et les tokens multi-usage, permettant une livraison sous escrow au-delà de XRP pour les flux de travail d'entreprise.

Les tokens multi-usage sont un format de token natif XRPL qui combine des propriétés fongibles et non fongibles. Ils peuvent porter des caractéristiques partagées tout en stockant également des métadonnées spécifiques aux actifs on-chain. Les développeurs les décrivent comme adaptés à la tokenisation de conformité car ils peuvent intégrer des règles et une gestion du cycle de vie sans dépendre de smart contracts externes pour les contrôles de base.

Les testeurs internes de la conception originale de Token Escrow, qui n'a pas été activée sur le réseau principal, ont identifié une incompatibilité comptable pour les tokens multi-usage qui facturent des frais de transfert. 

Dans un cas de test, un escrow a verrouillé cent tokens et a appliqué des frais de transfert d'un token au déverrouillage. Le destinataire a correctement reçu quatre-vingt-dix-neuf tokens après l'application des frais. La comptabilité de l'émetteur, cependant, a réduit le LockedAmount de l'émetteur de quatre-vingt-dix-neuf au lieu de la totalité des cent. Un token est resté enregistré comme verrouillé après la finalisation, ce qui laisserait les métriques de l'émetteur désynchronisées au fil du temps.

TokenEscrowV1 Sépare L'Escrow Brut De La Livraison Nette

La version 3.0.0 inclut l'amendement TokenEscrowV1, qui modifie la manière dont le registre traite la finalisation de l'escrow pour les tokens multi-usage portant des frais. L'amendement sépare la comptabilité brute de l'escrow de la comptabilité de livraison nette. 

Lorsqu'un escrow se termine, le LockedAmount diminue désormais du montant total initialement placé en escrow, revenant à son niveau pré-escrow. Les frais de transfert sont traités indépendamment par le mécanisme de frais de l'émetteur, de sorte que seul le montant net livré affecte les calculs d'approvisionnement en circulation. 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 tokens de rester bloqués dans un état verrouillé après la finalisation de l'escrow et maintient les métriques LockedAmount de l'émetteur alignées avec l'état du registre. Il a lié la correction aux flux de travail de tokenisation institutionnelle qui dépendent d'une comptabilité d'escrow précise, y compris les paiements planifiés et les opérations de trésorerie automatisées qui utilisent des actifs émis avec des frais de transfert.

Parce que TokenEscrowV1 modifie le traitement de base du registre, il nécessite une activation par un vote d'amendement. Les validateurs doivent approuver l'amendement pour garantir que les nœuds appliquent les mêmes règles de finalisation de l'escrow 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 alors que le réseau se dirige vers l'activation.

La nouvelle version 3.0.0 du XRP Ledger est arrivée quelques semaines après que Ripple a étendu sa présence au Japon via le Japan Financial Infrastructure Innovation Program, dans le cadre d'un partenariat avec l'Asia Web3 Alliance Japan et Web3 Salon.

Au moment de la rédaction, XRP s'échangeait à 2,33 $ après avoir augmenté de 9,34 % au cours des dernières 24 heures.