The XRP Ledger has activated Token Escrow (XLS-85) on mainnet on Feb.12, extending the network’s native escrow mechanics beyond XRP to Trustline-based tokens (IOUs) and Multi-Purpose Tokens (MPTs). The amendment was enabled today with 88% consensus (30/34 validators) and was introduced in rippled v2.5.0 under the XLS-85 specification.
Escrow, But For Every Asset On XRP Ledger
RippleX framed the change as a broadening of XRPL’s settlement primitives from one native asset to the wider token stack via X:
“Token Escrow (XLS-85) is now live on XRPL Mainnet! This feature extends native escrow functionality beyond XRP to all Trustline-based tokens (IOUs) and Multi-Purpose Tokens (MPTs). From stablecoins like RLUSD to Real World Assets, the XRPL now supports secure, conditional, onchain settlement for all assets.” It added: “The toolbox for Institutional DeFi just got bigger.”
Token Escrow (XLS-85) is now live on XRPL Mainnet!
This feature extends native escrow functionality beyond XRP to all Trustline-based tokens (IOUs) and Multi-Purpose Tokens (MPTs).
From stablecoins like RLUSD to Real World Assets, the XRPL now supports secure, conditional,... pic.twitter.com/DNCJxZsoK2
— RippleX (@RippleXDev) February 12, 2026
XRPL.org describes escrow in familiar terms, then emphasizes what the ledger automates: “Traditionally, an escrow is a contract between two parties to facilitate financial transactions... The XRP Ledger takes escrow a step further, replacing the third party with an automated system built into the ledger.” With the TokenEscrow amendment, that same approach now applies to fungible tokens, not just XRP.
For Trust Line Tokens, the issuing account must enable the Allow Trust Line Locking flag so the issued token can be escrowed. For MPTs, the issuer must set Can Escrow and Can Transfer flags at issuance so those tokens can both be held in escrow and transferred when released. One notable constraint: issuers cannot create escrows using their own issued tokens, though they can receive escrowed tokens as recipients.
Authorization gating also matters. If a token requires authorization, the sender must be pre-authorized by the issuer before creating an escrow, and must be authorized to receive the tokens back if an expired escrow is canceled—regardless of who submits the cancellation. Separately, the recipient must be pre-authorized before an escrow can be finished.
XRPL supports time-based, conditional, and combination escrows. The flow is anchored around EscrowCreate to lock funds, EscrowFinish to release them when conditions are met, and EscrowCancel to return funds once an escrow expires. For token escrows specifically, an expiration time is mandatory.
The feature is not free. XRPL.org flags that escrow “requires two transactions” and that Crypto-Conditions increase fees. While the ledger supports Crypto-Conditions, it currently only supports PREIMAGE-SHA-256, and fulfillment verification raises EscrowFinish costs. The documentation gives a concrete minimum: an EscrowFinish with a fulfillment requires at least 330 drops of XRP plus an additional amount based on fulfillment size, with the formula scaling if fee settings change.
RippleX highlighted use cases spanning vesting and grants, conditional payments and OTC-style swaps, treasury workflows like legal holds and collateral, and tokenized rights and RWA-style unlocks. The common thread is a native, on-ledger “lock until X” mechanism now available to the token layer, useful for structured settlement, compliance-shaped flows, and predictable release conditions without relying on a third-party custodian or purely off-chain coordination.
At press time, XRP traded at $1.35.
