XLS-0075d: Permission Delegation Performance Test Report

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.