XRPL Commons approves proposals for permissioned domains, DEX after Devnet tests

XRPL Commons said it backed two network upgrades on Friday after completing its routine amendment voting session, following a successful development network testing.

According to the community’s statement on X released Monday, one of the two proposals it voted for reached the validator voting threshold to be integrated into XRPL. One amendment it had backed earlier on was rejected after a flaw surfaced, and another amendment on token escrow is under review pending more testing.

XRPL Commons Voting Update

On Friday January 23rd, we completed our regular amendment voting session.

Amendment votes:
🔷XLS-80 (Permissioned Domains): Voted YES following successful Devnet testing

🔷XLS-81 (Permissioned DEXes): Voted YES following successful Devnet testing…

— XRPL Commons (@xrpl_commons) January 26, 2026

XRPL Commons participates in the validator-driven process that determines which changes advance toward activation. Amendments require sustained support from a supermajority of validators before they go live on the ledger.

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.