Ripple has released XRP Ledger version 3.0.0 and urged validators and node operators to upgrade promptly to avoid disruptions. It is not just an upgrade. This is because it fixes a fundamental technological problem that relates to token escrow.
This is one of the key functions used for settlement as well as scheduled transactions on XRPL. Those involved in developing enterprise applications have considered escrow to be one of the vital pillars of trust.
Also Read: XRPL Q2 Sees 154% Record RLUSD Adoption Amid Rising XRP Market Cap
Why Token Escrow Matters for XRPL
However, escrow has always been an integral part of XRPL settlement services. For a long time, it has exclusively supported the use of XRP. But this meant that if a business were to issue its tokens on the XRPL, it would find it difficult to take advantage of the advanced features.
The proposal called XLS-85 Token Escrow introduced the escrow service for the issued assets, such as IOUs and Multi-Purpose Tokens.
Multipurpose Tokens are particularly relevant in tokenization. They are a combination of fungible and non-fungible tokens and also contain a great deal of metadata.
XRPL developers quote Multipurpose Tokens as a solution for a high-compliance setting because they are able to include rules and lifecycles without using external smart contracts.
The Accounting Bug That Raised Concerns
Internal testers of the original Token Escrow design noticed the problem concerning MPTs, which contain transfer fees. This problem emerged after the completion of the escrow process and the unloading of the tokens.
When 100 tokens were unlocked, with the transfer fee of 1 token, the recipient was indeed rewarded 99 tokens.
The issue lay in the accounting of the issuers. The Ledger decreased the LockedAmount of the issuer only by 99 instead of the entire 100 originally escrowed. Thus, one token remained in the locked state. Eventually, this minor issue may accumulate and lead to discrepancies in the supply amounts on the network.
Experts tracking the XRPL infrastructure have constantly highlighted the dangers of the tiniest accounting discrepancies in the context of token networks and how they may undermine trust in such networks.
How TokenEscrowV1 Fixes the Issue
This issue has been resolved in the TokenEscrowV1 amendment, in which gross escrow logic has been isolated from net delivery. Once escrow has been completed, LockedAmount will diminish by its entire previously locked value.
Transfer charges will be processed independently so that only the net value impacts supply. No tokens shall be left locked, and total supply values will be kept accurate.
Also Read: Next-Gen XRPL Wallet from Anodos Simplifies Onboarding and Rewards Users
