Back to All Updates

Lock, Control, Release, Trade: Two New Primitives Just Went Live on XRPL

XRPL Canada – February 18, 2026

For years, one question followed Ripple's growing network of 300+ bank partnerships: if institutional adoption was so broad, why wasn't there massive on-chain volume on the XRP Ledger? The answer, as Ripple CTO David Schwartz explained, wasn't technical performance. Banks couldn't guarantee who was providing liquidity or whether counterparties met regulatory requirements when settling on-chain. That compliance barrier is now addressed — at the protocol level.

The XRP Ledger activated two protocol upgrades this week that have been years in the making. Token Escrow (XLS-85) went live on February 12. The Permissioned DEX (XLS-81) activated today, February 18.

These aren't UI improvements or partnership announcements. They are protocol-level primitives — new capabilities baked directly into the ledger that every application, institution, and developer building on XRPL can now use. XRPL Commons, who tested both amendments end-to-end on Devnet, described the pattern they unlock: lock → control access → automate release → bridge to open markets. All protocol-native. No custom contracts required.

Token Escrow: Programmable Locks for Any Token

Before this upgrade, native escrow on XRPL only worked with XRP. Token Escrow (XLS-85) extends that capability to all tokens — IOUs and Multi-Purpose Tokens (MPTs).

Any token can now be locked with conditions:

The reserve cost is 0.2 XRP per escrowed asset. One important detail: clawback is not available during the lock period.

This is foundational infrastructure. Vesting schedules, conditional payments, collateral management, invoice settlement — these are all patterns that previously required off-chain coordination or custom contract logic. They're now native to the ledger.

The Permissioned DEX: Controlled Markets Within the Open DEX

The XRP Ledger has operated an open decentralized exchange since 2012. Anyone with an account can place offers, match trades, and settle value — with no regard for who is on the other side. That openness is a feature for crypto-native users. For regulated financial institutions bound by AML and KYC requirements, it has been a dealbreaker.

The Permissioned DEX solves this directly. It creates controlled trading environments within the broader XRPL DEX where only pre-approved, credentialed participants can place and match offers — a compliance-gated order book running on the same infrastructure as the open DEX, with the same speed, cost efficiency, and finality, but with identity controls baked in at the protocol level.

There can be multiple permissioned DEXes on XRPL simultaneously. Each one is tied to a Permissioned Domain — an allowlist that specifies which credentials grant access. Trades within a permissioned DEX can only execute against other trades in the same DEX. Each can support order books for any number of currency pairs.

💡 Three Layers Working Together

The Permissioned DEX doesn't exist in isolation. It builds on two foundational amendments deployed first:

Together, these three features form a compliance-by-design framework built directly into the protocol — no custom smart contracts, no private blockchains, no isolated infrastructure required.

Understanding the Three Offer Types

With the Permissioned DEX live, a trade offer on XRPL can now be one of three types:

Open Offers work exactly as before — anyone can place them, anyone can match them. They interact with Automated Market Makers (AMMs) as usual. Nothing changes for participants in the existing open DEX.

Permissioned Offers specify a Domain ID and can only be matched by other valid offers within that same domain. A permissioned offer cannot be filled by an open offer, and an open offer cannot be filled by a permissioned offer. The two pools are fully isolated from each other. Cross-currency payments can also specify a domain ID, restricting them to only consuming offers from the corresponding permissioned DEX. Trades in a permissioned DEX can use auto-bridging as long as all the necessary orders exist within the same permissioned DEX.

Hybrid Offers are the bridge. A hybrid offer specifies a Domain ID but can match offers from both the permissioned DEX and the open DEX. When placed, it preferentially matches within the permissioned domain first — useful for market makers who want to arbitrage price differences across both environments while maintaining their compliance credentials.

Offer Type Open Hybrid Permissioned AMM
Open
Hybrid ✅ (same domain)
Permissioned ✅ (same domain)

A Note on AMMs

Permissioned offers and permissioned payments cannot interact with Automated Market Makers. AMM access cannot be restricted by a permissioned domain, and permissioned trades cannot consume AMM liquidity. Hybrid offers can use a mix of one permissioned DEX and the open DEX — including AMMs on the open side — but a single transaction cannot use multiple different permissioned DEXes. AMM support within permissioned DEXes is noted in the specification as a potential future addition.

Invalid Permissioned Offers

Beyond the ways offers can become unfunded in the open DEX, permissioned offers have additional invalidity conditions. An offer becomes invalid if the credential that granted domain access expires or is deleted, if the domain updates its accepted credentials and the account no longer qualifies, or if the domain itself is deleted. Invalid offers are treated like unfunded offers — automatically removed when a transaction touches the relevant order book. It is also possible for an offer to become temporarily invalid and then valid again: if a credential expires and is later renewed, offers that hadn't already been removed automatically become valid again.

How Token Escrow and Permissioned DEX Work Together

The real unlock is what happens when you combine both primitives. XRPL Commons laid out a concrete example from their Devnet testing:

A payments provider locks stablecoin liquidity in escrow for instant settlement guarantees. Issues credentials to verified business customers. Creates a permissioned trading pool for regional partners with compliance requirements. Liquidity unlocks automatically based on transaction volume thresholds. Switches to hybrid offers so partners can access regional liquidity privately — or tap the open DEX for cross-border FX conversion.

One ledger. Automated execution. No off-chain coordination.

🏦 What This Enables in Practice

Ripple and XRPL Commons have both outlined concrete applications this infrastructure is designed to support:

The pattern across all of these: lock assets with conditions, control who can trade them, automate the release, then bridge to open markets when ready.

The Compliance Stack Is Now Complete

It's worth understanding the Permissioned DEX in the context of what the XRP Ledger already supported. XRPL has long had compliance-focused features: Deposit Authorization, Authorized Trustlines, Clawback, Freezing, Multisign, and Payment Paths. Each addressed a specific compliance need at the account or asset level.

But the open DEX remained off-limits for regulated institutions because counterparty identity couldn't be guaranteed at the trading layer. Permissioned Domains addressed that at the identity layer. The Permissioned DEX closes the loop at the trading layer. The open DEX continues operating unchanged — this is additive infrastructure that extends what XRPL can do without disrupting what already works.

🇨🇦 What This Means for Canada

Canada is a trading nation. Cross-border commerce with the US, Europe, and Asia is not peripheral to the Canadian economy — it's central to it. And yet international payments remain slow, expensive, and opaque. SWIFT transfers still take 3-5 business days. Fees run $25-$50 per transaction plus hidden FX markups. For Canadian businesses exporting goods, freelancers working with international clients, and immigrants sending remittances home, that hasn't changed in decades.

What changed today is the infrastructure that makes a better alternative viable for regulated institutions. Canadian banks, fintechs, and payment service providers operate under strict compliance obligations. KYC, AML, counterparty verification — these aren't optional. Until now, settling on a public DEX meant accepting that you had no idea who was on the other side of the trade. That's not a risk any regulated Canadian institution could take.

The Permissioned DEX removes that barrier. Compliance-gated order books, credential-verified counterparties, jurisdiction-specific trading zones — all of it is now native to the ledger. No private blockchain required. No custom infrastructure build. The same rails that settle in 3-5 seconds at sub-cent cost are now accessible to institutions that couldn't touch them before.

Canada has a progressive regulatory environment — the first G7 nation to approve Bitcoin ETFs, with clear crypto taxation frameworks already in place. The infrastructure is ahead of most jurisdictions. The question now is whether Canadian institutions move to meet it.

Sources & Further Reading