XRPL Addresses Escrow Bug Impacting Institutional Tokenization Workflows

• XRPL 3.0.0 introduces TokenEscrowV1 to fix MPT escrow accounting with transfer fees, preventing LockedAmount supply drift.
• The amendment requires validator approval to activate, ensuring consistent escrow completion behavior across network nodes.

Ripple has released XRP Ledger version 3.0.0 and urged validators and node operators to upgrade without delay. The release targets an escrow accounting bug found during internal testing of token escrow for issued assets. Ripple said the fix supports consistent settlement behavior when institutions use time-locked or condition-based token delivery on XRPL. Why This Crucial For The XRP Ledger Escrow is a long-standing XRPL function used for scheduled transactions and conditional releases. It has historically worked with XRP only, which limited how issuers could use escrow for their own tokens. The XLS-85 Token Escrow proposal extends escrow to other issued assets, including IOUs and multi-purpose tokens, enabling escrowed delivery beyond XRP for enterprise workflows.

PSA: XRPL Version 3.0.0 is available, and we encourage all validators and node operators to upgrade at their earliest convenience to ensure service continuity. ✅

This latest version includes several fix amemdments, including a fix for TokenEscrow, which you can learn about…

— RippleX (@RippleXDev) January 5, 2026

Multi-purpose tokens are an XRPL-native token format that blends fungible and non-fungible properties. They can carry shared traits while also storing asset-specific metadata on-chain. Developers describe them as suited for compliance tokenization because they can embed rules and lifecycle handling without relying on external smart contracts for core controls. Internal testers of the original Token Escrow design, which has not been enabled on the main network, identified an accounting mismatch for Multi-Purpose Tokens that charge transfer fees.  In a test case, an escrow locked one hundred tokens and applied a one-token transfer fee at unlock. The recipient correctly received ninety-nine tokens after the fee was applied. The issuer accounting, however, reduced the issuer’s LockedAmount by ninety-nine instead of the full one hundred. One token remained recorded as locked after completion, which would leave issuer metrics out of sync over time. TokenEscrowV1 Separates Gross Escrow From Net Delivery Version 3.0.0 includes the TokenEscrowV1 amendment, which changes how the ledger processes escrow completion for fee-bearing multi-purpose tokens. The amendment separates gross escrow accounting from net delivery accounting.  When an escrow finishes, LockedAmount now decreases by the entire amount originally placed into escrow, returning to its pre-escrow level. Transfer fees are processed independently through the issuer’s fee mechanism, so only the net amount delivered affects outstanding supply calculations. The issuer’s transfer-fee mechanism accounts for the fee amount separately. The network said this approach prevents tokens from remaining stuck in a locked state after escrow completion and keeps issuer LockedAmount metrics aligned with the ledger’s state. It linked the fix to institutional tokenization workflows that depend on accurate escrow accounting, including scheduled payouts, and automated treasury operations that use issued assets with transfer fees. Because TokenEscrowV1 modifies core ledger processing, it requires activation through an amendment vote. Validators must approve the amendment to ensure nodes apply the same escrow completion rules across the network. Ripple asked operators to upgrade to version 3.0.0 so implementations remain compatible as the network moves toward activation. The new XRP Ledger version 3.0.0 arrived weeks after Ripple expanded its Japan footprint through the Japan Financial Infrastructure Innovation Program, in a partnership with the Asia Web3 Alliance Japan and Web3 Salon. At the time of writing, XRP traded at $2.33 after it rallied 9.34% over the past 24 hours.