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:

1. Select issuer accounts to create new MPT issuances (MPTokenIssuanceCreate).
2. Enable authorization (lsfMPTRequireAuth) to require holder registration.
3. Authorize holders using MPTokenAuthorize transactions.

4. Distribute tokens via standard Payment operations referencing mpt_issuance_id.

5. 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.

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

#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

IOU

MPT

#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

#4 LoanSet Mixload capacity

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.