XRP Ledger Turns On Permissioned DEX, Enabling Trading on Mainnet

The PermissionedDEX (XLS-81) amendment is now active on the XRP Ledger mainnet today, February 18, 2026, at approximately 10:58 UTC. The upgrade introduces controlled, credential-gated decentralized exchanges natively on the XRPL, allowing issuers and institutions to create trading venues where participation is restricted to approved, verified participants.

The activation follows strong validator consensus, reaching 82.35% approval (28 yes votes out of the UNL validators), well above the required 80% threshold maintained over the two-week activation window.

The feature builds directly on the recently activated Permissioned Domains (XLS-80), live since early February 2026 and complements other compliance-oriented upgrades like Credentials and Token Escrow (XLS-85), activated February 12.

What are Permissioned DEXes

In practical terms, Permissioned DEXes create controlled order books inside the XRPL DEX, designed for cases where participants must be vetted while keeping activity on the same public ledger infrastructure.

The XRPL documentation describes Permissioned DEXes as “controlled environments for trading” where a permissioned domain determines who can place and accept offers, rather than leaving every order book fully open.

What actually changes on the XRPL DEX

Instead of “one open market for everyone,” the upgrade introduces a way to run multiple parallel markets:

• Open DEX (existing): anyone can place and take offers.
• Permissioned DEX (newly available once all prerequisites are enabled): access is restricted based on credentials, with a domain acting as the gatekeeper.

Permissionsed DEX shifts compliance checks to a reusable on-chain primitive. Rather than every market operator building a separate private venue or using a centralized exchange’s KYC stack, XRPL allows the “who is allowed to trade here?” rule to be embedded at the protocol level via credentials and domains.

Important limitations users should understand

Permissioned DEXes don’t magically merge liquidity across everything on XRPL. The docs outline several constraints that shape how this will work in production:

• Not compatible with AMMs: permissioned offers and payments can’t be filled by AMMs, and AMM access can’t be restricted by a domain.
• Separate liquidity: each permissioned DEX is independent, with its own order books; trades can’t aggregate across multiple permissioned DEXes in a single transaction (though hybrid offers can interact with one permissioned DEX plus the open DEX).
• Credential risk surface: the safety and fairness of any permissioned venue depends heavily on the domain owner and credential issuers who can issue, revoke, or change access rules, meaning “permissioned” is only as strong as the governance around it.

These details are likely to matter for market makers and integrators because they affect routing, pricing, and where liquidity pools actually form.

The bigger picture

Permissioned DEXes are not a standalone switch. XRPL’s documentation explicitly says the Permissioned DEX feature relies on Credentials and Permissioned Domains, and can’t be used until those amendments are enabled.

In other words, this is part of a broader “compliance-by-design” direction: credentials define identity/eligibility, domains enforce access policy, and the DEX uses those controls to gate trading.

The key question now is adoption: whether any payment networks, issuers, or regulated trading desks will actually stand up permissioned domains, define credential standards, and seed liquidity in these gated order books because the upgrade enables the rails but doesn’t create market depth by itself.

Also Read: French Banking Giant Societe Generale Forge Deploys Euro Stablecoin on XRPL

Follow The Crypto Times on Google News to Stay Updated!