후원 수수료 및 준비금 — 성능 테스트 보고서

By Hitesh Gandhi(@hgandhi) and Qi Zhao

Introduction

The Sponsor amendment (XLS-68: Sponsored Fees and Reserves) introduces a way for one XRPL account to pay transaction fees and owner reserves on behalf of another account without taking custody of that account’s XRP. This lets exchanges, wallets, token issuers, and applications simplify onboarding by covering network costs for their users while those users retain full control of their keys and accounts.

XLS-68 supports two sponsorship modes. In co-signed sponsorship, the sponsor’s signature is attached to each transaction via the Sponsor transaction field. In pre-funded sponsorship, the sponsor creates a Sponsorship ledger object holding a fee pool (FeeAmount) and a per-transaction ceiling (MaxFee), so the sponsee can transact without the sponsor co-signing every time. Two new transaction types are added — SponsorshipSet and SponsorshipTransfer — and sponsorship applies to both account and object reserves.

The performance of XLS-68 was evaluated in a private XRPL performance network running production-representative infrastructure. Testing covered mixed-load simulations, stress testing at 2× baseline capacity, endurance runs of up to 5 hours, 2-signer multisign validation, and complex 6-path/8-step pathfinding under sponsorship load.

Executive Summary

The Sponsor amendment introduces no measurable performance degradation to XRPL consensus processing.

Under the most demanding realistic workload — 12 transaction types including complex 6-path/8-step DEX pathfinding alongside all sponsorship operations — the network sustained 322 TPS aggregate with zero overvalidations in the 60-minute flagship run. Under 2× stress, the network delivered 450 TPS sustained with a peak burst of 655 TPS and zero overvalidations: a 90.9% throughput increase for only a 6.6% increase in close rate, demonstrating sublinear consensus overhead.

Key Performance Metrics at a Glance

Metric Value Significance Peak sustained throughput 450 TPS 2× baseline with zero overvalidations Avg consensus latency 3.54–3.89 s Well within 5-second target P95 consensus latency 3.95–4.27 s No tail-latency concerns Overvalidation rate ≤ 0.4% per run Negligible across all test phases Validator out-of-sync events 0 Perfect consensus alignment P2P node out-of-sync events 0 Full network stability maintained Error rate (sponsorship TXs) ≤ 0.23% Production-grade reliability

The results show that XLS-68 is performant, stable, and ready for MainNet activation from a performance perspective.

Specification reference: XLS-0068: Sponsored Fees and Reserves

Testing Objectives

The primary objective was to validate that sponsored transaction processing does not degrade XRPL consensus health under sustained and burst loads. Specifically, we aimed to:

• Validate that mixed sponsored and non-sponsored workloads maintain sub-5-second consensus latency under sustained load.
• Stress test at 2× baseline to identify capacity headroom and breaking points.
• Measure per-transaction-type throughput, latency, and error rates across all sponsorship modes (pre-funded, co-signed, multisign).
• Validate endurance stability, confirming no memory leaks, CPU drift, or progressive degradation.
• Confirm that sponsorship transactions coexist safely with the most computationally expensive XRPL operations (6-path/8-step DEX pathfinding).

Testing Methodology

Capacity Planning

The 5-second consensus latency limit serves as the benchmark for network capacity. Any ledger whose publishing latency exceeds this threshold is counted as an “overvalidation.” The methodology targets a load level at which the network sustainably maintains sub-5-second close rates, then pushes to 2× that baseline to characterize stress behavior.

Throughout this report, close rate refers to ledger publishing latency (the interval at which validated ledgers are published), and TPS refers to aggregate ledger throughput across all transaction types.

Test Environment

Testing was conducted in a private XRPL environment with 9 nodes, mirroring Ripple’s MainNet hardware specifications.

Network Setup

• 5 nodes function as validator nodes
• 4 nodes serve as client P2P nodes, interfacing with load generators
• All nodes are hosted on AWS EC2 z1d.2xlarge instances: 8 CPU cores, 64 GB RAM, 300 GB NVMe SSD
• All nodes operate within the same AWS region, interconnected via a shared LAN
• 4 distributed load generators (ch0–ch3) submit transactions to the 4 P2P nodes

xrpld Configuration

The xrpld configuration was sourced from a Ripple MainNet validator, with modifications made only as required for the test environment.

Test Data Setup

A dedicated data strategy was developed for XLS-68 testing. At a high level:

• Account isolation: Sponsor and sponsee account pools were provisioned separately from the baseline transaction accounts, so the two workloads could not interfere with one another.
• Balance stability: Payment destinations were arranged so that XRP balances remained stable across long-duration runs.
• Scale: Roughly 100,000 sponsor/sponsee account pairs were distributed across the four load generators. Pre-funded sponsorship objects were provisioned with a fee pool and a per-transaction fee ceiling, and multisign scenarios used 8,000 master accounts with a 2-signer quorum, signed client-side.

Test Phases and Progression

Testing followed a progressive strategy designed to systematically validate every dimension of sponsorship performance:

Phase Objective Load Profile Duration Phase 1: Mixed Load Validate sponsored TX processing alongside baseline payments 240 TPS (6 TX types) 3 × 30 min Phase 2: Endurance Confirm stability under sustained load; detect memory leaks 240 TPS constant 2 × 4 hours Phase 3: Stress (2×) Identify breaking points by doubling baseline throughput 480 TPS constant 2 × 30 min Phase 4: Multisign Validate 2-signer multisign overhead and endurance 80 TPS multisign 2 × 30 min + 2 × 5 hr Phase 5: Full Mixed Load + 6-Path/8-Step Production-realistic simulation with complex pathfinding 322 TPS (12 TX types incl. pathfinding) 30 min + 30 min + 60 min Edge Cases 1:N sponsorship, termination flows Variable On-demand

Transaction Scenarios Under Test

The sponsorship mixed-load model distributes transactions across the following types at 240 TPS aggregate:

Transaction Type Sponsorship Mode Target TPS Description Normal XRP Payment None (baseline) 60 Non-sponsored XRP-to-XRP payment Prefund Payment Pre-funded fee 60 Sponsored payment where sponsor pays fee via Sponsorship pool Cosigned Payment Co-signed 40 Sponsored payment with dual signature (sponsor + sponsee) Sponsored OfferCreate Co-signed 40 DEX offer creation with sponsor covering reserve SponsorshipSet + CheckCreate Pre-funded 20 Create sponsorship pool + sponsored check creation SponsorshipTransfer (Account) Transfer 20 Transfer entire account sponsorship to a different sponsor SponsorshipTransfer (Object) Transfer 20 Transfer individual object sponsorship SponsorshipSet (Delete) Termination Variable Terminate sponsorship relationships

The full mixed load with 6-path/8-step pathfinding extends this to 12 transaction types at a ~334 TPS target by adding IOU Direct, 1Path1Step, 3Path3Step, and DEX 6-path/8-step payments.

Detailed Performance Results

Phase 1 — Mixed Load Testing

Three 30-minute mixed load runs were conducted at 240 TPS aggregate, combining sponsored and non-sponsored transactions. All three runs demonstrated highly consistent throughput and latency.

Metric Run 1 Run 2 Run 3 Assessment Ledgers Processed 511 544 545 Consistent ledger production Total Transactions 431,247 437,095 436,915 ~437K per run Avg TPS 236.03 236.54 234.99 Stable at target Max TPS 345.00 296.33 299.56 Healthy burst capacity Avg Close Rate (s) 3.65 3.60 3.59 Well under 5 s target Overvalidations 1 0 0 Negligible Validator out-of-sync 0 0 0 Perfect sync P2P out-of-sync 0 0 0 Perfect sync

Key takeaway: Across the three runs, throughput held steady at approximately 235 TPS and consensus latency remained well below the 5-second target. The core sponsorship transaction mix integrates cleanly with baseline XRPL payment processing.

Phase 2 — Endurance Testing

Two independent 4-hour endurance runs validated sustained performance and memory stability under continuous sponsorship load.

Metric Endurance Run 1 Endurance Run 2 Delta Duration 4 hours 4 hours n/a Ledgers Processed 4,041 4,042 +0.02% Total Transactions 3,209,083 3,241,171 +1.0% Avg TPS 223.19 224.97 +0.8% Max TPS 436.24 329.83 Run 1 spike during online delete Avg Close Rate (s) 3.61 3.62 +0.3% Overvalidations 0 1 Negligible

Key takeaway: The two endurance runs produced virtually identical results, confirming repeatability. The Max TPS spike in Run 1 (436 TPS) correlates with xrpld’s periodic online deletion cycle, which temporarily frees resources.

Phase 3 — Stress Testing (2× Baseline)

Load was doubled to 480 TPS aggregate to identify the network’s capacity ceiling with sponsored transactions.

Metric Baseline (240 TPS) Stress (480 TPS) Change Ledgers Processed 511 504 −1.4% Total Transactions 431,247 841,494 +95.1% Avg TPS 236.03 450.54 +90.9% Max TPS 345.00 655.45 +90.0% Avg Close Rate (s) 3.65 3.89 +6.6% Overvalidations 1 0 Improved Validator out-of-sync 0 0 Zero P2P out-of-sync 0 0 Zero

Key takeaway: Doubling the transaction load from 240 to 480 TPS resulted in only a 6.6% increase in average close rate (3.65 s → 3.89 s). The network processed 841K transactions in the stress window — nearly double the baseline — without degradation in consensus health.

Phase 4 — Multisign (2-Signer) Testing

Multisign transactions add cryptographic overhead because multiple signatures must be verified. The multisign test used a 2-signer flow with client-side signing.

Metric Run 1 (30 min) Run 2 (30 min) Endurance 1 (5 hr) Endurance 2 (5 hr) Total Transactions 146,880 146,880 1,442,880 1,442,880 Avg TPS 78.98 78.40 80.18 80.17 Max TPS 103.97 116.84 305.43 106.95 Avg Close Rate (s) 3.543 3.570 3.546 3.543 P95 Close Rate (s) 3.959 3.947 3.952 3.954 Overvalidations 0 2 1 0

Key takeaway: 2-signer multisign transactions achieved the targeted 80 TPS with the lowest consensus latency of any phase (avg 3.54 s, P95 3.95 s), sustained across two 5-hour endurance runs.

Phase 5 — Full Mixed Load with Complex Pathfinding

This phase represents the most demanding and production-realistic test scenario, combining all sponsorship transaction types with complex cross-currency pathfinding.

Aggregate Results

Metric Run 1 (30 min) Run 2 (30 min) Run 3 (60 min) Ledgers Processed 504 509 979 Total Transactions 614,366 614,201 1,183,972 Avg TPS 329 330 322 Max TPS 464 419 416 Avg Close Rate (s) 3.894 3.852 3.842 P95 Close Rate (s) 4.272 4.215 4.158 Overvalidations 1 0 0

Per-Transaction Throughput Breakdown (60-Minute Run)

The 60-minute test (Run 3) provides the most comprehensive view of sustained per-transaction performance:

Transaction Type Samples TPS Avg Latency (ms) P95 (ms) P99 (ms) Prefund Payment 218,156 59.60 19.81 79 190 Cosigned Payment 145,440 39.74 20.43 71 186 Sponsored OfferCreate 145,440 39.74 22.21 85 196 SponsorshipSet + CheckCreate 33,332 19.72 32.87 122 297 SponsorshipTransfer (Account) 72,720 19.87 18.79 74 201 SponsorshipTransfer (Object) 72,720 19.87 18.44 74 193 SponsorshipSet (Delete) 9,321 2.59 14.62 76 313 IOU Direct Payment 109,078 29.80 18.30 71 178 1Path1Step 72,720 19.87 18.64 75 186 3Path3Step 72,720 19.87 22.46 82 186 DEX 6-Path/8-Step 14,540 3.97 16.59 53 184

Key takeaway: The 60-minute mixed load run processed transactions at 322 TPS aggregate with zero overvalidations. Even the 6-path/8-step DEX payments — the most computationally expensive operation in the mix — held an average latency of 16.59 ms with a P99 of 184 ms.

Edge Case Testing

One-to-Many (1:N) Sponsorship

Validated a single sponsor account funding multiple sponsees concurrently:

Metric Value Pattern Single sponsor → multiple sponsees Total Transactions 367,200 Avg TPS 198.11 Max TPS 250.40 Avg Close Rate 3.61 s Overvalidations 0

Sponsorship Termination

Bulk deletion of sponsorship relationships:

Metric Value Sponsorships Deleted 40,000 TPS 229.05 Observed Errors tefPAST_SEQ, tecNO_ENTRY (expected under concurrent deletion)

System Resource Utilization

System-level metrics were monitored continuously via Grafana dashboards across all test phases. The following analysis covers CPU, memory, disk I/O, and network utilization patterns.

CPU Utilization

CPU utilization on validator nodes tracked linearly with TPS load across all test phases. During the 2× stress test (450 TPS achieved), CPU utilization increased proportionally without approaching saturation. Refer to the Grafana charts below for detailed CPU utilization trends.

Memory Utilization

Memory utilization remained flat throughout all test phases, with no indication of memory leaks or unbounded growth in the xrpld process. This was confirmed across both endurance rounds. Memory growth correlated with expected ledger object expansion (new Sponsorship objects, accounts, and offers) and was consistent with patterns observed in prior XRPL feature performance tests. Refer to the Grafana charts below for detailed memory utilization trends.

Disk I/O

Disk I/O patterns showed normal activity with periodic spikes correlating to xrpld’s online delete cycles and log rotation. One notable observation from the endurance tests: a transient CPU spike was traced to logrotate compressing xrpld logs, which momentarily saturated disk I/O. This is an operational artifact rather than a feature concern, and is mitigated by scheduling log rotation during off-peak hours.

Network I/O

Network utilization remained stable throughout all test phases, with no congestion or packet-loss events. Transaction propagation between P2P nodes and validators showed consistent sub-millisecond latency within the same-region LAN topology.

System Utilization Charts (60-Minute Mixed Load)

CPU

Memory

Disk I/O

Network

Conclusion

The comprehensive performance evaluation of Sponsored Fees and Reserves (XLS-68) demonstrates that the amendment is ready, delivering high throughput, stable consensus, and efficient resource utilization across all tested scenarios.

Summary of Findings

Throughput. Sponsored transactions achieved 235–450 TPS in mixed load configurations, with a peak burst of 655 TPS under 2× stress.

Consensus stability. Average consensus latency ranged from 3.54 s to 3.89 s across all test phases, consistently below the 5-second target. Overvalidations never exceeded 2 ledgers in any single run.

Endurance. Extended runs of 4 and 5 hours confirmed sustained performance with zero validator or P2P sync issues and predictable, bounded memory growth.

Complex pathfinding coexistence. The full mixed load with 6-path/8-step pathfinding — the most computationally demanding realistic scenario — achieved 322 TPS with zero overvalidations in the 60-minute run.

Multisign viability. 2-signer multisign transactions sustained 80 TPS with sub-4-second consensus latency across two 5-hour endurance runs, processing 2.88 million transactions in total.

Resource efficiency. CPU utilization remained well within capacity across all test phases including 2× stress, memory growth was bounded with no leaks detected, and no disk or network bottlenecks were observed.

Recommendation

Based on the results of this comprehensive performance evaluation, the Sponsored Fees and Reserves (XLS-68) amendment is recommended for MainNet activation. All test phases achieved PASS status, with the network demonstrating ample capacity, stable consensus, and production-grade reliability under diverse and demanding workload conditions.