Ripple heeft XRP Ledger versie 3.0.0 uitgebracht en validators en node-operators opgeroepen om zonder uitstel te upgraden. De release richt zich op een escrow-boekhoudbug die werd gevonden tijdens interne tests van token-escrow voor uitgegeven activa. Ripple zei dat de fix consistent afwikkelingsgedrag ondersteunt wanneer instellingen tijdslot- of voorwaardegebaseerde tokenlevering op XRPL gebruiken.
Escrow is een al lang bestaande XRPL-functie die wordt gebruikt voor geplande transacties en voorwaardelijke vrijgaven. Het werkte historisch gezien alleen met XRP, wat beperkte hoe uitgevers escrow voor hun eigen tokens konden gebruiken. Het XLS-85 Token Escrow-voorstel breidt escrow uit naar andere uitgegeven activa, inclusief IOU's en multifunctionele tokens, waardoor escrow-levering mogelijk wordt gemaakt buiten XRP voor bedrijfsworkflows.
Multifunctionele tokens zijn een XRPL-native tokenformaat dat fungibele en niet-fungibele eigenschappen combineert. Ze kunnen gedeelde eigenschappen dragen terwijl ze ook activaspecifieke metadata on-chain opslaan. Ontwikkelaars beschrijven ze als geschikt voor compliance-tokenisatie omdat ze regels en levenscyclusbeheer kunnen inbedden zonder te vertrouwen op externe smart contracts voor kerncontroles.
Interne testers van het oorspronkelijke Token Escrow-ontwerp, dat niet is ingeschakeld op het hoofdnetwerk, identificeerden een boekhoudkundige mismatch voor multifunctionele tokens die transferkosten in rekening brengen.
In een testcase vergrendelde een escrow honderd tokens en paste bij ontgrendeling een transferkost van één token toe. De ontvanger ontving correct negenennegentig tokens nadat de kosten waren toegepast. De boekhouding van de uitgever verminderde echter het LockedAmount van de uitgever met negenennegentig in plaats van de volledige honderd. Eén token bleef na voltooiing geregistreerd als vergrendeld, wat de uitgeverstatistieken in de loop der tijd niet gesynchroniseerd zou laten.
Versie 3.0.0 bevat de TokenEscrowV1-wijziging, die verandert hoe het ledger escrow-voltooiing verwerkt voor kostendragende multifunctionele tokens. De wijziging scheidt bruto escrow-boekhouding van netto leveringsboekhouding.
Wanneer een escrow eindigt, neemt LockedAmount nu af met het volledige bedrag dat oorspronkelijk in escrow werd geplaatst, terugkerend naar het pre-escrow-niveau. Transferkosten worden onafhankelijk verwerkt via het kostenmechanisme van de uitgever, zodat alleen het netto geleverde bedrag de berekeningen van de uitstaande voorraad beïnvloedt. Het transferkostenmechanisme van de uitgever verantwoordt het kostenbedrag afzonderlijk.
Het netwerk zei dat deze aanpak voorkomt dat tokens vastzitten in een vergrendelde staat na voltooiing van de escrow en de LockedAmount-statistieken van de uitgever op één lijn houdt met de staat van het ledger. Het koppelde de fix aan institutionele tokenisatieworkflows die afhankelijk zijn van nauwkeurige escrow-boekhouding, inclusief geplande uitbetalingen en geautomatiseerde treasury-operaties die uitgegeven activa met transferkosten gebruiken.
Omdat TokenEscrowV1 de kernverwerking van het ledger wijzigt, vereist het activering via een wijzigingsstemming. Validators moeten de wijziging goedkeuren om ervoor te zorgen dat nodes dezelfde escrow-voltooiingsregels toepassen over het hele netwerk. Ripple vroeg operators om te upgraden naar versie 3.0.0 zodat implementaties compatibel blijven terwijl het netwerk naar activering toewerkt.
De nieuwe XRP Ledger versie 3.0.0 kwam weken nadat Ripple zijn aanwezigheid in Japan uitbreidde via het Japan Financial Infrastructure Innovation Program, in een partnerschap met de Asia Web3 Alliance Japan en Web3 Salon.
Op het moment van schrijven werd XRP verhandeld op $2,33 nadat het 9,34% steeg in de afgelopen 24 uur.


