XRPL Commons Greenlights Permissioned Domains and DEX After Successful Devnet Trials

XRPL just got a major institutional upgrade path. The XRPL Commons governance body has formally approved proposals to implement permissioned domains and a dedicated decentralized exchange (DEX) on the ledger, following a rigorous devnet testing phase. This move signals a strategic pivot towards regulated, enterprise-grade blockchain infrastructure.

Building Walls to Open Doors

The permissioned domains feature introduces a gated layer atop the public XRPL. Think of it as a private members' club within a public park—specific participants operate in a controlled environment with predefined rules, while the underlying public chain ensures settlement finality. This architecture directly targets financial institutions shackled by compliance but hungry for blockchain efficiency.

A DEX Built for Compliance, Not Anarchy

Alongside, the approved DEX proposal isn't your typical wild-west automated market maker. It's engineered with compliance hooks, offering institutions a non-custodial trading venue that can integrate know-your-customer (KYC) and anti-money laundering (AML) checks directly into the trade lifecycle. It bypasses the regulatory gray area that keeps traditional finance lawyers awake at night.

The approval cuts through years of theoretical debate, proving the tech works in a sandboxed environment. The devnet tests demonstrated core functionality: secure asset issuance within permissioned zones, atomic swaps between public and private liquidity pools, and audit trails deep enough to satisfy even the most skeptical regulator—a rare feat in crypto.

This dual-track approach lets XRPL chase two futures simultaneously: remain a vibrant public ledger for developers and retail, while carving out a fortified zone for the suits. It’s a pragmatic bet that the real money still sits in boardrooms, not Telegram groups. One cynical finance jab? It's the blockchain equivalent of adding a velvet rope—because nothing attracts institutional capital like exclusivity and the illusion of control.

XRP validators greenlight credential-based network zones

88% of validators have voted in favor of the XLS-80 proposal, also known as Permissioned Domains, after successful Devnet testing. The group said the change is tracking an estimated activation date of February 4, 2026, at 09:57:51 UTC.

The proposal introduces restricted environments within the XRP Ledger that limit the participation of accounts holding approved credentials. The framework WOULD not expose sensitive personal records, as only proof that a credential is valid is recorded on-chain, while any personal details remain off the ledger. 

Permissioned Domains are gated zones that institutions can use, provided they verify counterparties before transacting. This is different from the fully open access model that blockchain systems used before, including XRPL.

XRPL Commons also voted in favor of the XLS-81 “Permissioned DEX” amendment, which was proposed during the launch of software version v2.5.0 last year. According to the XRP amendment voting page, XLS-81 has not yet been enabled but is still in the voting phase.

The amendment requires 27 out of 34 validator votes to meet its threshold. At the time of reporting, consensus stood at 55.88%, with only 19 validators in favour.

The proposal expands the XRP Ledger’s built-in exchange by allowing trading inside controlled settings. Participants must hold approved credentials before placing or filling orders, including financial firms operating under identity and reporting rules.

Permissioned DEX instances have “allow-lists” that determine who can access a given trading venue. Orders placed in these settings are kept separate from the main open order books. One type limits activity strictly to traders within a specific domain. At the same time, another structure lets traders interact with both the restricted pool and the public exchange, giving priority to the controlled venue.

The framework is meant to work alongside XRP Ledger compliance mechanisms, such as authorized trustlines, asset freezing, and clawback functions, to enable regulated on-chain trading.

However, the Commons switched its vote on XLS-56 (Batch Transactions) from yes to no after the discovery of a software issue during review. According to the group, the bug could validate inner transactions in a batch that seemed properly signed when they were not. Commons recommended that developers make fixes before its support on the ledger could resume.

XRPL token escrow upgrade awaits further testing

The XLS-85 amendment that extends escrow features to issued tokens in other chains saw no change in position. XRPL Commons said more testing is scheduled ahead of the next voting session.

Per the proposal’s semantics, the ledger could hold IOUs and Multi-Purpose Tokens in escrow. It could also impact coin releases by conditions such as time, specific events, or programmable rules. 

Token issuers would be barred from placing their own assets into escrow, and any assets under escrow could not be clawed back during the lock period. Transfer fees for certain tokens would be calculated when the escrow is created.

The amendment was also introduced with software version v2.5.0 and would require 80% validator backing to activate. Still, it does not provide direct cross-chain escrow functionality as that limitation is outside its current scope.

Beyond amendment decisions, XRPL Commons said fee-based reserve remains at 1 XRP, while the owner reserve is capped at 0.1 XRP. All other open amendments had already been voted on in prior sessions, and no new proposals were added to the agenda this round.

The next amendment voting session is scheduled for February 6, when validators will revisit pending proposals and review test results.

Don’t just read crypto news. Understand it. Subscribe to our newsletter. It's free.