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.2xlargeinstances: 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.
Top comments (0)