Permissioned DEX Performance Test Report

Introduction

The Permissioned DEX (Decentralized Exchange) feature is a proposed enhancement to the XRP Ledger (XRPL) that integrates compliance-focused features directly into the core DEX functionality. It enables market participants to place offers and execute payments within domains that enforce KYC/AML requirements through credential verification. This solution supports regulated institutions by allowing them to interact with the XRPL DEX ecosystem without compromising compliance requirements.

This report presents the performance impact of the Permissioned DEX feature based on dedicated benchmarks carried out by the RippleX performance team. We assessed how the introduction of permissioned offers and payments affects ledger throughput, consensus times, and overall system resource usage. Our findings confirm that the XRPL can support this feature at scale while maintaining performance stability.

“Permissioned DEX does not fundamentally alter the core design of the order book. For cross-currency payments within a domain, the payment engine must verify whether the offer owner still possesses valid credentials within that domain. This check is expected to incur only minimal performance overhead,” Shawn Xie, RippleX Engineer, outlined. “This report tests the worst-case scenario, where all credentials in the domain must be evaluated for each offer. The observed performance impact aligns with expectations and remains well within acceptable limits.”

---

Testing Objectives

The primary objective of this testing was to assess the mass of transactions involving Permissioned DEX and their impact on consensus processing, particularly under high-load conditions. Specifically, we aimed to:

• Evaluate the XRPL's ability to process Permissioned DEX transactions under high-throughput conditions.
• Identify potential bottlenecks introduced by domain-based permission checks.
• Ensure the 5-second consensus latency threshold is met across varied transaction scenarios.

---

Testing Methodology

Capacity Planning

To measure the maximum performance impact of integrating permissioned dex, we used the 5-second consensus latency limit as the benchmark for network capacity. This threshold ensures that the network remains in optimal condition while processing permissioned-dex transactions. During testing, we monitored both ledger and consensus performance to determine whether the network load exceeded this latency criterion. Instances where the network surpassed this limit are referred to as “overvalidation” in the results below.

---

Test Environment

Our testing infrastructure simulated a private XRPL environment with 9 nodes, matching Ripple's MainNet in terms of hardware specifications. The key features of this environment are the following:

• Network Setup
  • 5 function as validator nodes
  • 4 serve as client P2P nodes, interfacing with load generators
• Uniform System Specifications: Each system mirrors the hardware specifications found in Ripple’s MainNet rippled infrastructure. Specifically, they are hosted on AWS's EC2 instance type, z1d.2xlarge, boasting 8 CPU cores, 64GB RAM, and 300GB NVMe SSD storage, dedicated to the rippled database.
• Network Configuration: All nodes operate within the same AWS region and are interconnected through a shared LAN.
• Load Submission: Between 1 and 4 load servers are actively engaged in transmitting transactions to the 4 P2P nodes.
• Account Setup: A total of 100K synthetic accounts were established, built atop a public ledger synchronized from the MainNet as of Aug 22nd, 2024. Provisions were made in the simulation logic to ensure the uniqueness of source and destination accounts for every consensus cycle.
• Configuration Continuity: The rippled configuration file was sourced directly from a Ripple MainNet validator. While the core configurations remained unchanged, requisite modifications were made to align with the specific needs of our environment.

---

Test Data Setup

To model realistic permissioned trading behavior at scale, we created a synthetic dataset consisting of:

• Credential Issuers: A pool of accounts responsible for issuing credentials via CredentialCreate transactions.
• Subjects: Each of the 100,000 test accounts received credentials from various issuers and responded with CredentialAccept transactions.
• Permissioned Domains: Dedicated domain-owner accounts created PermissionedDomainSet ledger entries, each configured to accept up to 10 unique credentials (the maximum permitted by the spec).

Example Domain Setup

{
  "method": "submit",
  "params": [
    {
      "tx_json": {
        "TransactionType": "PermissionedDomainSet",
        "Account": "${domain_account}",
        "AcceptedCredentials": [
          {
            "Credential": {
              "Issuer": "r3cFEueRyVKstW1XwuvQJCaTGWHHU7g9mx",
              "CredentialType": "4B5943"
            }
          },
          ...
          {
            "Credential": {
              "Issuer": "rwZAGV84nkkv1yxrdV3kNrpz8B1mXGFLmB",
              "CredentialType": "4B5943"
            }
          }
        ]
      },
      "secret": "${domain_account_seed}"
    }
  ]
}

Offer Setup: Offers were created with and without the DomainID, representing both open and permissioned orderbooks. Offers were distributed across currency pairs and various path complexities.

Payment Configuration: Payment transactions were configured to consume both open and permissioned offers.

---

Load Modeling

Payment Routing Terminology

Before diving into the test scenarios, it’s important to understand the terminology used to describe different payment types on the XRPL:

• IOU-Direct Transaction: A simple transaction where both sender and receiver hold the same issued currency (IOU) from the same issuer — no intermediary is needed.

• Path: A sequence of intermediaries (accounts or orderbooks) used to bridge the gap between sender and receiver when a direct transfer isn't possible. It’s used for cross-currency or cross-issuer payments.

• Step: A single segment within a payment path. For example, moving funds from XRP to USD through an orderbook is one step. Complex payments may require multiple steps across various currencies or issuers.

• LOB (Limit Order Book): A decentralized exchange mechanism on the XRPL that enables currency conversions by matching offers.

---

#1 Payment Mixload Baseline

• A mixed load of standard payment transactions involving LOB-based decentralized exchanges (DEX).
• This scenario establishes a baseline for network performance under typical MainNet conditions.

We integrated a realistic payment distribution, encompassing various transaction types:

• XRP-XRP Transaction
• IOU-Direct Transaction
• LOB 1path1step transaction
• LOB 3path3step transaction
• LOB 6path8step transaction

System Statistics

#2 Payment Mixload with Permissioned DEX

• Same distribution as above, with path-based payments routed through the Permissioned DEX for 1-path/1-step, 3-path/3-step, and 6-path/8-step transactions.

System Statistics

#3 Open DEX Orderbook Transactions

• A mix of payments that only interact with open orderbooks via LOB (Limit Order Book) transactions.
• LOB 1path1step transaction, 3path3step transaction, 6path8step transaction

System Statistics

#4 Permissioned DEX Orderbook Transactions

• A mix of payments that exclusively route through permissioned orderbooks, testing credential and domain validation at scale.
• LOB 1path1step transaction, 3path3step transaction, 6path8step transaction

System Statistics

---

Conclusion

Performance testing of the Permissioned DEX feature demonstrates that XRPL maintains its performance guarantees even under high-throughput scenarios involving domain-restricted offers and credential-validated paths. Across all modeled workloads, consensus times remained under the 5-second threshold, and throughput levels remained consistently above 140 TPS.

Compared to baseline payment scenarios, Permissioned DEX scenarios showed a slight increase in memory usage — from 20 GB to 21 GB in mixed payment loads, and 25 GB to 26 GB in DEX-only workloads. CPU utilization remained steady at 10–11%, and response times increased by less than 2 ms.

These results validate that Permissioned DEX functionality can be safely introduced into XRPL’s production infrastructure without compromising performance or stability.