Permissioned Domains and DEXs on XRPL: What We Learned

We tested XLS-80 (Permissioned Domains) and XLS-81 (Permissioned DEXes) on Devnet. Everything works as specified. On January 23rd, 2026, XRPL Commons voted YES on both amendments.

This blog summarizes our testing of the Permissioned Domains and Permissioned DEXes amendments on the XRP Ledger, and what we learned running them end-to-end on Devnet.

What these amendments enable

Permissioned Domains (XLS-80) let operators create controlled environments on XRPL. A domain operator defines which credentials are accepted, and accounts holding valid credentials automatically become members. This applies regulatory constraints—KYC, sanctions checks—without changing the ledger’s decentralized architecture.

Permissioned DEXes (XLS-81) extend the native DEX with permissioned order books. Only members of the same domain can trade with each other, ensuring all counterparties have been vetted.

Three offer types are introduced:

• Open offers — standard XRPL DEX behavior
• Permissioned offers — restricted to a single domain
• Hybrid offers — trade both within a domain and on the open DEX

Both amendments build on XLS-70 Credentials, which provide an on-chain identity layer where issuers can attest facts about accounts (identity verification, compliance status) that other participants can rely on.

Together, these amendments enable institutional-grade DeFi: stablecoin-fiat FX, payroll disbursements, international B2B payments, and corporate treasury operations—all while remaining compliant.

Critical note on IOU configuration

This was our main blocker during early testing.

For rippling to work properly:

1. The issuer must enable DefaultRipple
2. Users must create trust lines to the issuer
3. The issuer must explicitly clear the NoRipple flag on each user trust line

If the issuer skips step 3, third-party trades fail with tecPATH_DRY or tecKILLED.

What we tested

We manually tested the full lifecycle: credentials (create, accept, verify, delete), domains (create, modify, delete, credential limits), and DEX operations (open/permissioned/hybrid offers, domain-scoped order books, offer matching, non-member rejection).

Results: All XLS-70, XLS-80, and XLS-81 features worked as expected.

• Credential issuance and acceptance behaved correctly
• Domain membership derived automatically from valid credentials
• Permissioned offers properly isolated—only same-domain members could trade
• Non-members correctly rejected with tecNO_PERMISSION
• Hybrid offers matched permissioned liquidity first, then fell back to open DEX
• Expired credentials correctly prevented access

Known limitations

• No auto-cross on placement — a taker transaction is always required to trigger matching
• Liquidity is domain-scoped — trades can’t span multiple permissioned domains
• Strict dependency order — XLS-81 requires XLS-80, which requires XLS-70

Why we voted YES

Based on our testing, these amendments behave as specified and are stable on Devnet. On January 23rd, 2026, XRPL Commons voted YES on both XLS-80 and XLS-81.

A few considerations for those evaluating these amendments:

• Institutions must carefully configure IOU rippling
• Domain operators need clear guidance on credential lifecycle management
• Liquidity fragmentation is an intentional trade-off for regulatory compliance

Resources

• XLS-80 Permissioned Domains Specification
• XLS-81 Permissioned DEXes Discussion

Try it out yourself

Test these features directly: tests.xrpl-commons.org