DEV Community: Qi Zhao

Lending Protocol Performance Test Report

Qi Zhao — Thu, 05 Feb 2026 18:22:38 +0000

Introduction

The Single Asset Vault (SAV, XLS-65) and Lending Protocol (XLS-66) together introduce the foundational infrastructure for on-ledger liquidity aggregation and lending within the XRPL ecosystem.

The SAV enables depositors to aggregate XRP, IOU, or MPT assets into a shared vault represented by Multi-Purpose Token (MPT) ownership shares.

The Lending Protocol, built atop these vaults, allows creation of loans, repayments, and deletions tied to vault liquidity through LoanSet, LoanPay, and LoanDelete transactions.

This report summarizes a comprehensive performance evaluation of both amendments under high-load scenarios. Tests were executed in RippleX’s private performance network to quantify throughput, consensus latency, CPU/memory utilization, and ledger growth impacts.

The results demonstrate that the SAV and Lending amendments are performant and stable, with predictable memory growth linked to ledger object expansion, and that both features can be safely activated without compromising the 5-second consensus target.

Testing Objectives

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

Evaluate the capacity limits of the XRPL when processing lending protocol transactions alongside existing payment transactions.
Validate SAV and Lending transaction throughput across XRP, IOU, and MPT asset types.
Measure CPU and memory overhead introduced by new ledger objects (Vault, Loan, LoanBroker, Vault pseudo-account).
Identify potential bottlenecks or performance degradation caused by lending protocol related operations.
Ensure that the network maintains a 5-second consensus latency threshold, even under the most demanding scenarios.

Testing Methodology

Capacity Planning

To measure the maximum performance impact of integrating lending protocol transactions, 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 a mix of lending protocol, single asset vault and standard payment 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 250K synthetic accounts were established, built atop a public ledger synchronized from the MainNet as of Mar 11th, 2025. 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

Permissioned Domain

To simulate the most computationally intensive ledger path, all lending activities were executed within a permissioned domain environment, ensuring every transaction incurred credential verification and domain access checks at runtime.

A synthetic dataset was constructed to model large-scale permissioned lending behavior:

Credential Issuers – A pool of domain-authority accounts issued credentials through CredentialCreate transactions.
Subjects (Participants) – All participating accounts accepted credentials via CredentialAccept, establishing verified identities under their respective domains.
Permissioned Domains – Domain-owner accounts created PermissionedDomainSet ledger entries, each configured to authorize up to 10 unique credentials (the protocol’s maximum).

As a result, every Vault, Broker, and Borrower operated under enforced domain constraints. Each loan transaction therefore required on-ledger verification of PermissionedDomain and Credential objects, — amplifying computational and I/O load during consensus.

Multi-Purpose Token

To support MPT-backed vault testing, the environment was pre-initialized with Multi-Purpose Token (MPT) objects following the XLS-33 specification.

A subset of accounts acted as MPT issuers, each creating several token issuances with authorization and transfer flags enabled to simulate real-world tokenization complexity. After creation, all remaining accounts were authorized as holders and received distributed token balances through MPT-based Payment transactions. This process populated the ledger with a large number of active MPTokenIssuance and MPToken objects, ensuring realistic token distribution and directory-node activity across the network.

In summary, MPT generation followed this sequence:

Select issuer accounts to create new MPT issuances (MPTokenIssuanceCreate).
Enable authorization (lsfMPTRequireAuth) to require holder registration.
Authorize holders using MPTokenAuthorize transactions.
Distribute tokens via standard Payment operations referencing mpt_issuance_id.
Populate ledger with MPT balances to be used by vault depositors and borrowers in lending operations.

Lending Protocol

To comprehensively evaluate the Lending Protocol’s performance, a high-complexity, mixed-role dataset was created to emulate realistic cross-flows between depositors and borrowers.

The database comprised 250,000 total accounts, distributed across four load servers.

Role	Count	Notes
Vault Owners (also LoanBrokers)	8,000	Each account owns one or more Vaults and acts as the associated LoanBroker.
Depositors	130,000	Provide liquidity through VaultDeposit; some also serve as borrowers (dual-role).
Borrowers	130,000	Create loans via LoanSet and make repayments via LoanPay.
Dual-role overlap (Depositor ∩ Borrower)	18,000	Participate in both sides of lending, creating circular fund flows that increase ledger contention.

Each Vault services 15–30 depositors and 10–15 borrowers, deliberately maximizing DirectoryNode update and SHAMap node insertion.

Vault Setup

Vault Types – Three asset configurations were deployed:
XRP-based, IOU-based, and MPT-based Vaults.
Privacy – All Vaults were flagged as Private, inheriting the domain’s permission rules.
Precision – Asset scales were configured to their spec defaults (scale = 0 for XRP/MPT, scale = 6 for IOU).
Liquidity Initialization – Vault owners funded liquidity pools via VaultDeposit; depositors received MPT share tokens representing proportional ownership.
Cross-Vault Distribution – Depositors diversified across vaults to trigger higher inter-vault transaction frequency and hash-tree activity.

Loan Setup

To exercise all high-cost code paths in the protocol, loans were generated to reflect the most computation-heavy configuration supported by the spec:

Multisign Loan Creation Each loan was established through LoanSet, signed by the LoanBroker (Vault Owner) and Borrower, validating both Credential and domain access permissions.
Sample Complex Loan Terms with overpayment flags
- InterestRate: 6 %
- LateInterestRate: 8 %
- OverpaymentInterestRate: 2 %
- CloseInterestRate: 1 % (prepayment penalty)
- OverpaymentFee: 0.1 %
- ServiceFeeRate: 0.2 %
- ManagementFeeRate: 15 %
- PaymentInterval: 10000000
- PaymentTotal: 1000
Overpayment Coverage
- All loans were configured with both lsfLoanOverpayment (Loan flag) and tfLoanOverpayment (LoanPay flag) set, forcing every payment to execute the overpayment branch of the protocol.
- Each transaction recalculates the overpayment interest, deducts fees, applies the remaining amount to principal, and re-amortizes the remaining loan schedule—representing a computationally intensive path in the Lending Protocol.

Load Modeling

#1 Payment Baseline

A mixed load of standard payment transactions involving both the AMM-based and 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

Scenario	Ledger throughput per second	Mean Ledger Publishing Latency (s)	Response Time (ms)	Over Validation	CPU Utilization (%)	Memory Usage (GB / Total)
Payment Mixload	159.31	3.96	9.79	9 out of 924	12	16/64 GB

#2 Lending Protocol and Single Asset Vault Transactions

This test phase focused on evaluating the end-to-end performance of all core transaction types introduced by the Single Asset Vault (SAV, XLS-65) and Lending Protocol (XLS-66) amendments.

XRP

Transaction Type	Ledger throughput per second	Mean Ledger Publishing Latency (s)	Response Time (ms)	Over Validation	CPU Utilization (%)	Memory Usage (GB / Total)
VaultDeposit	328.35	3.30	4.07	1 out of 925	16	23/64GB
VaultWithdraw	303.56	3.96	4.21	1 out of 924	17	23/64GB
VaultCreate	255.52	3.92	4.56	1 out of 935	14	24/64GB
LoanPay	242.53	3.90	3.67	1 out of 940	16	25/64 GB
LoanSet	210.36	3.98	5.34	3 out of 920	16	26/64 GB
LoanDelete	185.42	4.02	5.67	3 out of 905	17	26/64 GB

IOU

Transaction Type	Ledger throughput per second	Mean Ledger Publishing Latency (s)	Response Time (ms)	Over Validation	CPU Utilization (%)	Memory Usage (GB / Total)
VaultDeposit	268.33	4.08	5.36	9 out of 897	16.5	26/64 GB
VaultWithdraw	238.77	3.95	4.64	4 out of 926	16	27/64 GB
VaultCreate	230.06	3.11	6.51	4 out of 1176	16	27/64 GB
LoanPay	170.70	3.82	3.63	1 out of 957	14	26/64 GB
LoanSet	166.57	3.97	5.59	9 out of 920	16	28/64 GB
LoanDelete	150.64	4.18	5.88	5 out of 900	17	27/64 GB

MPT

Transaction Type	Ledger throughput per second	Mean Ledger Publishing Latency (s)	Response Time (ms)	Over Validation	CPU Utilization (%)	Memory Usage (GB / Total)
VaultDeposit	269.98	4.00	5.28	2 out of 914	16	24/64 GB
VaultWithdraw	205.96	3.83	3.94	2 out of 957	14	25/64GB
VaultCreate	236.68	3.94	4.16	1 out of 928	16	25/64GB
LoanPay	178.12	3.70	3.45	1 out of 987	13	25/64GB
LoanSet	207.51	3.94	5.27	4 out of 928	15	27/64GB
LoanDelete	165.21	4.05	5.45	3 out of 910	16	26/64 GB

#3 Lending + Payment Mixload capacity

Simulated a realistic maximum load scenario combining standard payment and lending protocol transactions.
Replaced 60% of baseline payment throughput with lending-heavy operations (LoanSet and LoanPay) across XRP, IOU, and MPT assets.
Mixed remaining 40% with payment, AMM, and DEX transactions to emulate mainnet traffic diversity.
Conducted 1-hour preliminary testing to benchmark throughput and latency under blended load.
Performed extended longevity testing to monitor system stability, CPU utilization, and memory growth trends.

Transaction Execution Realistic Percentage:

9.72% XRP-XRP Payment
9.72% IOU Direct Payment
9.72% AMM/LOB 1path1step Payment
0.66% AMM/LOB 3path3step Payment
9.89% AMM/LOB 6path8step Payment
12.5% AMM/LOB IOU Direct Payment
10% XRP LoanSet Transaction
10% XRP LoanPay Transaction
10% IOU LoanSet Transaction
10% IOU LoanPay Transaction
10% MPT LoanSet Transaction
10% MPT LoanPay Transaction

Scenario	Ledger throughput per second	Mean Ledger Publishing Latency (s)	Response Time (ms)	Over Validation	CPU Utilization (%)	Memory Usage (GB / Total)
Lending Mixload - 1h	147.99	3.97	14.99	4 out of 921	15	22/64GB
Lending Mixload - 12h	152.83	3.92	12.03	19 out of 11023	15	26/64GB
Lending Mixload - 12h continued	154.92	3.87	10.56	12 out of 11154	15	32/64GB

#4 LoanSet Mixload capacity

Scenario	Ledger throughput per second	Mean Ledger Publishing Latency (s)	Response Time (ms)	Over Validation	CPU Utilization (%)	Memory Usage (GB / Total)	Average Node Memory Growth
LoanSet 1h Target 45 TPS	46.13	3.56	3.45	0 out of 1027	9	19/64GB	4.43GB
LoanSet 1h Target 90 TPS	90.95	3.62	3.62	1 out of 1011	10	21/64GB	4.95GB
LoanSet 1h Target 135 TPS	132.10	3.67	2.19	0 out of 998	11	23/64GB	5.53GB
LoanSet 1h Target 180 TPS	180.83	3.78	4.24	1 out of 968	12	24/64GB	5.61GB
LoanSet 1h Target 200 TPS	193.83	3.90	4.97	1 out of 938	13	24/64GB	5.77GB
LoanSet 1h Target 225 TPS	227.23	4.16	5.84	21 out of 880	18	25/64GB	6.74GB

LoanSet Memory Growth Graph

The figure below illustrates the memory growth trend observed during continuous LoanSet transaction execution at increasing throughput targets.

Lending Mixload System Utilization Graph

CPU Usage

RAM Usage

Conclusion

The performance evaluation of the Lending Protocol (XLS-66) and Single Asset Vault (XLS-65) demonstrates that both amendments deliver high throughput across XRP, IOU, and MPT asset types while consistently maintaining consensus stability within the 5-second ledger target.

However, memory growth remains the primary long-term risk factor under sustained lending workloads. During extended 24-hour Lending Mixload performance tests, RAM utilization exceeded 30 GB, driven by the cumulative expansion of SHAMap nodes from continuous LoanSet transactions. Although this remains below the 64 GB capacity of our test nodes, it raises potential concerns for validators operating with 32 GB RAM, where prolonged high-volume lending activity could approach system limits.

To mitigate these risks, SHAMap node optimization and ledger object pruning should be prioritized in future rippled initiatives. These improvements will curb in-memory state growth and enhance long-term sustainability as new high-complexity features are introduced.

From a deployment perspective, the current Lending Mixload throughput of ~152 TPS is sufficient to support near-term production needs and customer-scale adoption. Continued optimization efforts will further strengthen the ledger’s ability to sustain heavy workloads such as lending, AMM operations, and multi-asset payments.

Batch Transaction Performance Testing Report

Qi Zhao — Tue, 12 Aug 2025 20:44:19 +0000

Author: Qi Zhao, Luc des Trois Maisons

Introduction

Atomic/Batch Transactions is a proposed amendment to the XRPL that enables the atomic execution of multiple transactions as a single unit. By ensuring that complex, multi-step operations either fully succeed or entirely revert, this feature introduces significant usability and flexibility improvements, enabling use-cases such as atomic swaps, conditional token minting, and integrated fee management.

To evaluate the performance implications of Batch transactions, the RippleX performance team conducted targeted benchmarking tests. This report details our testing methodology, results, and observations, highlighting the impact of Batch transactions on ledger throughput, consensus latency, and resource utilization.

Testing Objectives

The primary objectives for Batch transaction performance testing are to:

Assess ledger throughput and response times under varying Batch transaction scenarios, including “All or Nothing”, “Only One”, “Until Failure”, and “Independent” modes.
Identify performance bottlenecks specifically related to Batch transaction processing.
Ensure the network maintains a 5 seconds consensus latency under high load.

Testing Methodology

Capacity Planning

To measure the maximum performance impact of integrating Batch transactions, we establish a deadline for network ledger validation of 5 seconds. This threshold ensures that the network remains in optimal condition while processing transactions. During testing, we monitor both ledger and consensus performance to establish any occurrence of the network failing to meet this deadline. Each discrete occurrence where the network fails to do so is noted, and referred to as an “overvalidation” in the results below.

Test Environment

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

Network Setup
- 5 nodes function as validators.
- 4 nodes operate in P2P mode, serving as non-validating client gateways, enabling our load generators to interface with the network.
Uniform System Specifications: Each system mirrors the hardware specifications found in Ripple’s MainNet rippled infrastructure. Specifically, they are hosted on AWS EC2’s z1d.2xlarge instance type, which provides 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 VPC.
Load Submission: During testing, 4 load servers actively and continuously submit transactions to the 4 P2P nodes.
Account Setup: A total of 250K synthetic accounts were established, built atop a snapshot of the MainNet ledger captured on Aug 22nd, 2024. Provisions were made in the simulation logic to ensure the uniqueness of source and destination accounts for every consensus cycle.
Configuration Consistency: The rippled configuration used for the test network was sourced from a UNL Ripple MainNet validator. For testing purposes, a minimal set of necessary changes are applied to segregate our network and align with the specific needs of our environment.

Test Data Setup

Four primary Batch transaction scenarios are tested:

All or nothing: For each Batch transaction submitted under this mode, either all internal transactions apply successfully, or they all are discarded with no effect on ledger state.
Only one: In this mode, at most one inner transaction may be accepted, and update the ledger state.
Until Failure: Inner transactions are applied in the order submitted in the Batch, and may each be accepted in-turn and update the ledger state. However, should an inner transaction fail to be applied, all subsequent inner transactions must also be discarded.
Independent: All inner transactions are considered independently, and may be accepted or rejected notwithstanding the fate of the others submitted in the Batch.

Load Modeling

Metrics of interest

Each scenario's performance metrics included:

Transaction throughput (TPS)
Response times
Consensus latency (overvalidation rate)
CPU and memory utilization

Transaction Distribution

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

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

Each Batch consisted of the maximum allowed 8 inner transactions. Batches were then submitted to evaluate ledger performance metrics.

Error Case Simulation

To rigorously test the atomicity guarantees provided by Batch transactions, we deliberately introduced an error in the final inner transaction of each Batch. This transaction was crafted to pass preflight validation checks but to fail during the consensus phase, causing the entire Batch to revert and testing the system's ability to correctly handle such atomic failures.

Performance Results

Payment Baseline

Transaction Type	TPS (requests/s)	Ledger throughput per second	Mean Ledger Publish Latency (s)	Response Time (ms)	Over Validation (count)	CPU Utilization (%)	Memory Usage (rippled RES in GB / % of Total Memory)
Payment Mixed load	161.22	161.22	3.91	7.56	2 out of 936 ledgers	10	16 GB / 64 GB

System Statistics

Novel Batch Scenarios

Scenario	Batch TPS (requests/s)	Ledger throughput per second	Mean Ledger Publishing Latency (s)	Response Time (ms)	Over Validation	CPU Utilization (%)	Memory Usage (GB / Total)
All Or Nothing w/ no expected failures	29.45	266.61	4.029	5.81	4 out of 908	9	21 / 64 GB
All Or Nothing w/ trailing erroneous inner transaction	75.63	75.41	3.959	6.26	4 out of 924	9	27.52 / 64GB 43%
Only One	51.46	102.58	3.589	5.57	2 in 1020	8	20.6 / 64 GB
Until Failure w/ no expected failures @ 150 TPS target throughput	51.42	465.07	5.518	7.98	503 out of 663	14	23.7 / 64 GB 37%
Until Failure w/ no expected failures @ 60 TPS target throughput	21.65	195.34	3.741	5.22	3 out of 978	7	16.6 / 64 GB 26%
Until Failure w/ trailing erroneous inner transaction @ 60 TPS target throughput	21.67	174.09	3.532	5.38	2 out of 1036	7	17.9 / 64 GB 28%
Independent @ 150 TPS target throughput	51.42	464.07	5.244	7.05	400 out of 698	11	20.5 / 64 GB 32%
Independent @ 100 TPS target throughput	35.60	321.29	4.522	5.87	60 out of 809	9	18.6 / 64 GB 29%
Independent @ 83 TPS target throughput	29.75	269.12	4.315	6.48	34 out of 848	12	24.3 / 64 GB 38%
Independent @ 60 TPS target throughput	21.65	196.00	3.782	5.40	3 out of 968	7	16.0 / 64 GB 25%

Observations

There appears to be a significant quantity of emergency throughput available at the expense of missing our desired ledger publishing deadlines.
Each systemically successful inner transaction increases ledger throughput by the submission throughput.
Failure scenarios and rejected inner transactions can cause the ledger to incur a significant throughput opportunity cost.

Conclusion

The total ledger throughput does not appear to be impaired or hindered when ledger processing includes Batch transactions. However, it should also be noted that Batch transactions containing the full set of 8 inner transactions apply significant leverage to the XRPL’s ledger throughput. We should be mindful of the potential for increased impact when making on-going performance decisions that involve and/or impact Batch transactions.

Permissioned DEX Performance Test Report

Qi Zhao — Wed, 09 Jul 2025 14:14:25 +0000

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.

XLS-0075d: Permission Delegation Performance Test Report

Qi Zhao — Thu, 29 May 2025 15:20:14 +0000

Introduction

Permission Delegation is a proposed amendment to the XRPL that enables accounts to selectively delegate transaction permissions to other accounts. This mechanism enhances account usability by allowing account holders to distribute specific responsibilities—such as issuing tokens or authorizing trustlines—without relinquishing full control over their accounts.

By supporting fine-grained authorization, Permission Delegation unlocks new possibilities for multi-party workflows, external integrations, and advanced account management strategies, while maintaining a strong security posture.

To evaluate the performance implications of this feature, the RippleX performance team carried out targeted benchmarking to assess the impact of delegated transactions on ledger throughput, validation times, and network stability. This report presents our testing setup, performance results, and key observations, demonstrating that enabling Permission Delegation does not degrade XRPL’s core performance or interfere with other transaction types.

Testing Objectives

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

Assess the network’s capacity to process various transaction types submitted via delegated permissions, with a particular focus on Payment transactions.
Identify potential bottlenecks or performance degradation caused by permission delegation-related operations.
Ensure that the network maintains a 5-second consensus latency threshold, even under the most demanding scenarios.

Testing Methodology

Capacity Planning

To measure the maximum performance impact of integrating permission delegation transactions, 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 permission delegation 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 August 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 comprehensively evaluate the performance of permission delegation transactions, we constructed a large-scale dataset that accurately simulates real-world usage patterns involving a diverse mix of delegating and delegated accounts.

Each of the four load servers was allocated 25,000 accounts, resulting in a total of 100,000 delegating accounts across the entire performance testing environment. Additionally, another 100,000 accounts were generated to serve as delegated accounts, enabling realistic delegation scenarios.

Consistent with the spec, each delegating account pre-created Delegate ledger objects for the maximum allowable 10 distinct permissions. These permissions included both commonly utilized transaction types, such as Payment, and more specialized transactions, such as TrustlineFreeze.

The transaction payload used during testing is provided below:

Example Payload

{
  "method": "submit",
  "params": [
    {
      "tx_json": {
        "TransactionType": "DelegateSet",
        "Account": "${issuer}",
        "Authorize": "${account}",
        "Sequence": "${seqNum}",
        "Permissions": [
          {"Permission": {"PermissionValue": "Payment"}},
          {"Permission": {"PermissionValue": "OfferCreate"}},
          {"Permission": {"PermissionValue": "NFTokenMint"}},
          {"Permission": {"PermissionValue": "AMMDelete"}},
          {"Permission": {"PermissionValue": "MPTokenIssuanceCreate"}},
          {"Permission": {"PermissionValue": "MPTokenIssuanceLock"}},
          {"Permission": {"PermissionValue": "Clawback"}},
          {"Permission": {"PermissionValue": "TrustSet"}},
          {"Permission": {"PermissionValue": "TrustlineAuthorize"}},
          {"Permission": {"PermissionValue": "TrustlineFreeze"}}
        ]
      },
      "fail_hard": false,
      "secret": "${secret}"
    }
  ]
}

Furthermore, each delegating account assigned these 10 permissions to 15 separate delegated accounts. This design effectively models a realistic and highly distributed delegation structure involving numerous actors. The diagram below provides a snapshot illustrating the delegation distribution on each load server.

In addition, to facilitate targeted testing for specific transaction types—particularly those with intricate workflows like multi-path payments—we preconfigured the necessary ledger state for all accounts. This preparation included issuing IOU tokens, establishing trustlines, and setting up requisite Offer and AMM objects in advance. These steps ensured the testing environment authentically represented the conditions required to comprehensively exercise all delegated permissions.

Load Modeling

#1 DelegateSet

Simulate network load by issuing DelegateSet transactions, each assigning the maximum of 10 permissions per call.

System Statistics

#2 Payment Baseline

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

System Statistics

#3 Permission Delegation Payment

Permission Delegation Payment

A mixed load of payment transactions with delegation
XRP-XRP Transaction, IOU-Direct Transaction, AMM/LOB 1path1step transaction, AMM/LOB 3path3step transaction, and AMM/LOB 6path8step transaction

System Statistics

#4 Permission Delegation Mix Capacity

A load consisting exclusively of MPT transactions, including XRP-XRP Payment, AMM/LOB 6path8step Payment, AMM/LOB IOU Direct Payment, Trustset, Trustsetfreeze, OfferCreate, NFTokenMint, and MPTokenIssuanceCreate transactions.
This scenario assesses the network's capacity to handle a high volume of transactions involving permission delegation.

Transaction Execution Realistic Percentage:

12.5% XRP-XRP Payment
12.5% AMM/LOB 6path8step Payment
12.5% AMM/LOB IOU Direct Payment
12.5% Trustset
12.5% Trustsetfreeze
12.5% OfferCreate
12.5% NFTokenMint
12.5% MPTokenIssuanceCreate

Without Permission Delegation

System Statistics

With Permission Delegation

System Statistics

Conclusion

Based on our comprehensive testing and analysis, the introduction of Permission Delegation does not introduce any significant performance overhead to the XRPL. Across all scenarios—including standard payments, delegated payments, and high-capacity mixed transaction loads—key performance metrics such as transaction throughput, response time, CPU usage, and memory consumption remained stable and within expected ranges.

In the delegated payment scenario, throughput was stable around the baseline, with only minimal increases in response time and system resource usage. Even under the most demanding conditions involving a diverse mix of delegated transaction types, the XRPL consistently maintained throughput levels above 158 TPS and met the 5-second consensus latency target, with only a few instances of over-validation.

While the overall TPS remained consistent across transactions involving permission delegation (applicable to both delegated payments and mixed transaction scenarios), we did observe a slight increase in memory usage—averaging around an additional 3 GB. The DelegateSet operations reached approximately 543.21 transactions per second while maintaining a healthy network status.

These results validate that Permission Delegation can be safely integrated into the rippled implementation without compromising network stability or performance. It enables more flexible account management and new use cases—such as role-based permissions and third-party delegation—while preserving the XRPL’s performance guarantees.

We will continue monitoring and optimizing for real-world deployments to ensure XRPL remains robust and scalable for evolving applications.

MPT Performance Test Report

Qi Zhao — Mon, 27 Jan 2025 20:21:21 +0000

Introduction

Multi-Purpose Tokens (MPTs) are a flexible token standard proposed for the XRPL that enable various use cases, including payments, securities, and NFTs, all through a single unified framework. MPTs support a range of operations such as token issuance, authorization, clawback, and destruction, allowing for enhanced functionality in managing and interacting with digital assets. This versatile token structure facilitates the creation, transfer, and control of assets on the XRPL, contributing to improved scalability and efficiency for decentralized financial applications.

To ensure the seamless integration of MPTs into the XRPL, the RippleX performance team conducted extensive testing to evaluate the impact of MPT transactions on the network's consensus performance and overall health. This report outlines our testing methodology, findings, and conclusions, demonstrating that the activation of the MPT amendment will not adversely affect the network's performance or its ability to process other transactions.

For more details, please refer to the official documentation here.

Testing Objectives

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

Evaluate the capacity limits of the XRPL when processing MPT transactions alongside existing payment transactions.
Identify potential bottlenecks or performance degradation caused by MPT-related operations.
Ensure that the network maintains a 5-second consensus latency threshold, even under the most demanding scenarios.

Testing Methodology

Capacity Planning

To measure the maximum performance impact of integrating MPT transactions, 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 a mix of MPT and standard payment 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 July 3rd, 2023. 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 test Multi-Purpose Token (MPT) transactions, we prepared the following:

Accounts:
- Added 50,000 new accounts to the existing 100,000 payment accounts.
- Designated 15 accounts as MPT Token issuers to create and distribute tokens.
Token Issuances:
- Created 100,000 token issuances for MPT destroy transactions.
- Added 280 issuances for MPT operations like authorization, clawback, and issuance updates.

Load Modeling

#1 Payment Baseline

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

#2 Payment + MPT Transaction (3-7)

Payment + MPT Payments

A mixed load of standard payment transactions and MPT payments.
Replacing 20% of the payment transactions load that the current release can support with MPT p2p direct payments transactions.
This scenario evaluates the performance impact of introducing MPT payments into the existing transaction mix.

#3 MPT Only Capacity

A load consisting exclusively of MPT transactions, including MPTokenAuthorize, MPT payments, MPTokenIssuanceCreate, MPTokenIssuanceSet, Clawback, and MPTokenIssuanceDestroy.
This scenario assesses the network's capacity to handle a high volume of MPT-related operations.

Transaction Execution Realistic Percentage:

30% MPTokenAuthorize
50% MPT Payment between testing accounts
25% Payment from MPTokenIssuer to MPTokenHolder
25% Payment from MPTokenHolder to MPTokenHolder
10% MPTokenIssuanceCreate
5% MPTokenIssuanceSet
3% Clawback
2% MPTokenIssuanceDestroy

Conclusion

Based on our comprehensive testing and evaluation, the introduction of Multi-Purpose Tokens (MPT) does not impose a significant load on the XRPL. Performance metrics—including ledger throughput, CPU usage, submission latency, and memory consumption—remained consistent across standard payments, mixed MPT and payment transactions, and fully MPT transactions. Moreover, we determined that MPT transactions can sustain throughput of up to 432 TPS under projected usage scenarios.

These results provide confidence that integrating MPT into rippled will pose no immediate risks to the network. Our commitment to ongoing research and development ensures that we will continue to enhance the performance and resilience of the XRP Ledger, enabling it to support a wide range of innovative use cases.

A security audit was also recently completed. Here is a link to the full report.