Introduction
The MPTVersion2 amendment (XLS-82) extends Multi-Purpose Token (MPT) support to the XRP Ledger's Decentralized Exchange (DEX), enabling MPT assets to participate natively in Automated Market Maker (AMM) pools, order book offers, cross-currency payments, and check-based transfers. This builds directly on the XLS-33 MPT foundation and the existing XRPL DEX infrastructure (XLS-30).
Rather than introducing new on-ledger objects or a separate trading engine, MPTVersion2 extends existing transaction types — AMMCreate, AMMDeposit, AMMWithdraw, AMMClawback, AMMDelete, CheckCreate, CheckCash, OfferCreate, and Payment — to treat MPT as a first-class asset alongside XRP and IOUs. MPT amounts are identified by mpt_issuance_id in transaction JSON in place of the currency/issuer fields used by IOUs.
This report summarizes a comprehensive performance evaluation of the MPTVersion2 amendment under high-load conditions. Tests were executed in RippleX's private performance network to quantify throughput, consensus latency, CPU/memory utilization, and regression impact relative to the 3.1.2 release baseline.
The results demonstrate that MPT DEX integration is performant and stable, with no material regression against baseline IOU-based DEX operations, and that the amendment can be safely activated without compromising the 5-second consensus target.
Executive Summary
The MPTVersion2 amendment introduces no measurable performance regression against the 3.1.2 production release. Under identical conditions, the mpt_dex build matched baseline throughput within 0.4%. Pure MPT path payments outperformed the IOU baseline by 14.2%, while the most complex mixed MPT-IOU paths came within 1.7% of baseline. DEX transaction capacity with MPT token pairs exceeded IOU equivalents by over 36%. All scenarios maintained consensus latency below the 5-second target across both 1-hour and 5-hour endurance runs, with stable CPU and memory utilization throughout. The amendment is safe to activate without compromising MainNet SLOs.
Testing Objectives
The primary objective of this testing was to assess the performance impact of enabling MPT assets in DEX and payment flows, and to validate that no regressions are introduced relative to the 3.1.2 production release. Specifically, we aimed to:
- Establish a clean performance baseline comparing the
mpt_dexbuild against the 3.1.2 release under identical load and database conditions. - Validate that the
mpt_dexbuild performs equivalently when run against both the baseline performance database and the MPT DEX-enriched database, confirming that MPT ledger object population does not degrade existing transaction performance. - Measure the throughput, consensus latency, and resource utilization of MPT-enabled path payments across multiple path complexity tiers.
- Compare MPT path payment performance across three middle path configurations — pure IOU-IOU (baseline), pure MPT-MPT, and alternating MPT-IOU — at increasing path complexity tiers.
- Stress test rippled's DEX transaction processing under a load distribution mirroring the most frequent MainNet operations (
AMMCreate,AMMDeposit,OfferCreate) with MPT/MPT token pairs, validating no regression against the IOU-only baseline. - Ensure that the network consistently maintains a 5-second consensus latency threshold under all test scenarios.
Testing Methodology
Capacity Planning
The 5-second consensus latency limit serves as the benchmark for network capacity across all scenarios. This threshold ensures the network remains in optimal condition while processing a mix of MPT-enabled DEX, AMM, and payment transactions alongside standard payment flows. Instances where the network surpassed this limit are referred to as "overvalidation" in the results below.
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
- Between 1 and 4 load servers transmit transactions to the 4 P2P nodes
Account Setup
A total of 250,000 synthetic accounts were established, built atop a public ledger synchronized from MainNet. 15 accounts were designated as MPT token issuers, distributing MPT balances to the remaining MPT participant accounts.
rippled Configuration
The rippled configuration was sourced from a Ripple MainNet validator, with modifications made only as required for the test environment.
Test Data Setup
Multi-Purpose Token Initialization
To support MPT-backed DEX testing, the environment was pre-initialized with MPT objects following the XLS-33 and XLS-82 specifications.
Three token chains were constructed to support the full range of path payment scenarios:
IOU1 → IOU2 → IOU3 → IOU4 → IOU5 → IOU6 → IOU7 → IOU8
MPT1 → MPT2 → MPT3 → MPT4 → MPT5 → MPT6 → MPT7 → MPT8
MPT1 → IOU1 → MPT2 → IOU2 → MPT3 → IOU3 → MPT4 → IOU4
The pure IOU chain serves as the baseline control. The pure MPT chain exercises MPT-only pathfinding. The alternating MPT-IOU chain represents the most complex cross-type routing scenario, requiring the pathfinding engine to resolve offer crossings between MPTokenIssuance and trust line objects at every hop.
Database creation followed this sequence:
- Issuer accounts created MPT issuances via
MPTokenIssuanceCreate, withlsfMPTCanTradeandlsfMPTCanTransferflags set to enable DEX participation. - All holder accounts were authorized via
MPTokenAuthorize. - Token issuers funded root accounts via
Payment. - All four load servers distributed MPT balances to the full holder population.
- AMM pools and order book offers were pre-created to seed liquidity across the full asset graph.
Load Modeling
Scenario 1 — Baseline: Build Regression (mpt_dex vs. 3.1.2 Release)
Objective: Confirm that the mpt_dex build introduces no performance regression against the current 3.1.2 production release under identical baseline conditions.
Two sub-comparisons were performed:
1a. Baseline DB — 5-Hour Build Comparison
Both builds executed against the standard 250K account baseline performance database (no MPT objects). This isolates code-level regressions introduced by the MPTVersion2 amendment independent of ledger state changes.
- Load: Standard IOU mixed payment load (XRP-XRP, IOU Direct, AMM/LOB 1path1step, 3path3step, 6path8step)
- No MPT transactions included
| Scenario | Ledger throughput per second | Mean Ledger Publishing Latency (s) | P95 Ledger Publishing Latency (s) | Average Response Time (ms) | Over Validation | CPU Utilization (%) | Memory Usage (GB / Total) |
|---|---|---|---|---|---|---|---|
| 3.1.2 Release | 160.84 | 4.03 | 4.72 | 9.25 | 30 out of 4476 | 12.4 | 17.6/64 GB |
| mpt_dex build | 160.29 | 4.07 | 4.80 | 9.59 | 32 out of 4438 | 12.5 | 17.9/64 GB |
1b. mpt_dex Build — 5-Hour DB Comparison (Baseline DB vs. MPT DEX DB)
The mpt_dex build was tested against both the baseline database and the MPT DEX-enriched database (populated with MPT issuances, MPToken objects, new AMM pools, and offers) under the same standard mixed payment load. This validates that MPT ledger object population does not degrade performance for non-MPT transactions.
| Scenario | Ledger throughput per second | Mean Ledger Publishing Latency (s) | P95 Ledger Publishing Latency (s) | Response Time (ms) | Over Validation | CPU Utilization (%) | Memory Usage (GB / Total) |
|---|---|---|---|---|---|---|---|
| Baseline DB | 159.45 | 4.06 | 4.78 | 9.75 | 31 out of 4451 | 11.7 | 18.9/64 GB |
| MPT DEX DB | 159.20 | 4.08 | 4.83 | 10.05 | 44 out of 4423 | 12.3 | 19.8/64 GB |
Scenario 2 — MPT DEX Path Payments
Objective: Measure throughput, latency, and resource impact of MPT-enabled cross-currency path payments at increasing path complexity, compared against an IOU-only baseline.
All three configurations below were tested under a mixed load combining all three path complexity tiers simultaneously:
| Path Complexity | Description |
|---|---|
| 1 path / 1 step | Direct single-hop payment |
| 3 paths / 3 steps | Moderate path fan-out |
| 6 paths / 8 steps | Worst-case routing complexity |
2a. IOU-IOU Middle Path — Baseline (Control)
Pure IOU-to-IOU payments routed through IOU intermediate hops. No MPT involvement. Used as the regression control for all path payment comparisons.
Path structure:
IOU1 → IOU2 → IOU3 → ... → IOU8
| Scenario | Ledger throughput per second | Mean Ledger Publishing Latency (s) | P95 Ledger Publishing Latency (s) | Response Time (ms) | Over Validation | CPU Utilization (%) | Memory Usage (GB / Total) |
|---|---|---|---|---|---|---|---|
| IOU-IOU Middle Path | 142.89 | 3.92 | 4.59 | 9.42 | 4 out of 932 | 11.4 | 16.8/64 GB |
2b. MPT-MPT Middle Path — Pure MPT
MPT-to-MPT payments routed exclusively through MPT intermediate hops. This exercises MPTokenIssuance and MPToken state lookups at every step of the payment path, with no trust line traversal involved.
Path structure:
MPT1 → MPT2 → MPT3 → ... → MPT8
| Scenario | Ledger throughput per second | Mean Ledger Publishing Latency (s) | P95 Ledger Publishing Latency (s) | Response Time (ms) | Over Validation | CPU Utilization (%) | Memory Usage (GB / Total) |
|---|---|---|---|---|---|---|---|
| MPT-MPT Middle Path | 163.24 | 3.99 | 4.59 | 11.79 | 3 out of 918 | 11.7 | 16.9/64 GB |
2c. MPT-IOU Alternating Middle Path
MPT-to-MPT source/destination payments routed through an alternating sequence of MPT and IOU intermediate hops. This is the most complex path payment configuration, requiring the pathfinding engine to resolve cross-type offer crossings at every step, alternating between MPTokenIssuance and trust line state lookups.
Path structure:
MPT1 → IOU1 → MPT2 → IOU2 → MPT3 → ...
| Scenario | Ledger throughput per second | Mean Ledger Publishing Latency (s) | P95 Ledger Publishing Latency (s) | Response Time (ms) | Over Validation | CPU Utilization (%) | Memory Usage (GB / Total) |
|---|---|---|---|---|---|---|---|
| MPT-IOU Middle Path | 140.46 | 3.98 | 4.73 | 12.05 | 3 out of 921 | 11.8 | 17.2/64 GB |
2d. Endurance Testing across three scenarios
To validate stability under sustained load, all three path payment configurations were run continuously for 5 hours. The objective was to confirm consistent throughput, detect any anomalous degradation over time, and observe CPU and memory behavior beyond the initial ramp-up period.
| Scenario | Ledger throughput per second | Mean Ledger Publishing Latency (s) | P95 Ledger Publishing Latency (s) | Response Time (ms) | Over Validation | CPU Utilization (%) | Memory Usage (GB / Total) |
|---|---|---|---|---|---|---|---|
| IOU-IOU Middle Path | 142.56 | 4.03 | 4.75 | 9.72 | 34 out of 4476 | 12.3 | 17.6/64GB |
| MPT-MPT Middle Path | 163.15 | 4.04 | 4.77 | 11.67 | 24 out of 4475 | 12.2 | 17.7/64GB |
| MPT-IOU Middle Path | 140.35 | 4.09 | 4.84 | 12.93 | 24 out of 4416 | 12.4 | 18.9/64GB |
Endurance Testing System Utilization Graph
Ledger Validation Time
Ledger validation time increases with scenario complexity, progressing from IOU-IOU through MPT-MPT to MPT-IOU. All validation times remain below the 5-second target threshold.
 |
 |
|---|
Memory Usage Analysis
This chart displays normal memory behavior, with usage stabilizing after an initial ramp-up and then holding steady.
| IOU-IOU Middle Path | MPT-MPT Middle Path | MPT-IOU Middle Path |
|---|---|---|
 |
 |
 |
CPU Usage Analysis
This chart shows stable and low CPU utilization for validator nodes. The spikes are result from the online delete being triggered during the tests.
| IOU-IOU Middle Path | MPT-MPT Middle Path | MPT-IOU Middle Path |
|---|---|---|
 |
 |
 |
Scenario 3 — OfferCreate & AMM Capacity
Objective: Assess the performance impact of MPT DEX support on high-frequency DEX transaction types. The load distribution is modeled on observed MainNet DEX traffic, where OfferCreate, AMMDeposit, and AMMCreate are among the most common operations. By comparing IOU-only against MPT/MPT token pair configurations under the same transaction mix, this scenario quantifies how MPT asset support affects DEX throughput and consensus stability.
The load mix mostly reflects the observed MainNet DEX distribution: 80% OfferCreate, 18% AMMDeposit, and 2% AMMCreate.
3a. 1-Hour Capacity Run — IOU/IOU vs. MPT/MPT
Both token pair configurations were tested under the same load mix. IOU/IOU serves as the regression control; MPT/MPT exercises all MPT-specific flag and authorization checks on both legs of every OfferCreate, AMMDeposit, and AMMCreate transaction.
| Scenario | Ledger throughput per second | Mean Ledger Publishing Latency (s) | P95 Ledger Publishing Latency (s) | Response Time (ms) | Over Validation | CPU Utilization (%) | Memory Usage (GB / Total) |
|---|---|---|---|---|---|---|---|
| IOU-IOU | 207.43 | 3.89 | 4.18 | 8.33 | 0 out of 940 | 12.1 | 16.3/64GB |
| MPT-MPT | 282.57 | 3.86 | 4.17 | 7.58 | 0 out of 948 | 13.1 | 16.9/64GB |
3b. 5-Hour Endurance Testing
Extended longevity runs were conducted to monitor system stability, CPU utilization, and memory growth trends under sustained DEX load with MPT token pairs.
| Scenario | Ledger throughput per second | Mean Ledger Publishing Latency (s) | P95 Ledger Publishing Latency (s) | Response Time (ms) | Over Validation | CPU Utilization (%) | Memory Usage (GB / Total) |
|---|---|---|---|---|---|---|---|
| IOU-IOU | 206.85 | 4.34 | 4.18 | 8.91 | 12 out of 4589 | 13.3 | 17.1/64GB |
| MPT-MPT | 281.11 | 4.27 | 4.17 | 8.15 | 16 out of 4634 | 14.3 | 18.2/64GB |
Conclusion
The performance evaluation of the MPTVersion2 amendment (XLS-82) demonstrates no material regression against the 3.1.2 production release baseline. The mpt_dex build achieved 160.29 TPS against 160.84 TPS for the 3.1.2 release under identical load and database conditions — a difference of less than 0.4% — confirming that the amendment introduces no measurable code-level overhead. Similarly, running the mpt_dex build against the MPT DEX-enriched database (populated with MPT issuances, MPToken objects, AMM pools, and offers) produced 159.20 TPS compared to 159.45 TPS on the baseline database, confirming that the expanded ledger state from MPT object population does not degrade performance for non-MPT transactions.
For MPT path payments, the pure MPT-MPT middle path outperformed the IOU-IOU baseline at 163.24 TPS vs. 142.89 TPS — a 14.2% improvement — reflecting the lighter per-hop state footprint of MPToken lookups compared to trust line traversal. The alternating MPT-IOU middle path came in at 140.46 TPS, approximately 1.7% below the IOU-IOU baseline, consistent with the additional cross-type offer crossing overhead incurred at every hop. These results held stable across the 5-hour endurance runs, with throughput, latency, and memory utilization remaining consistent between the 1-hour and extended runs across all three configurations. CPU utilization remained low and stable throughout, and memory growth stabilized after an initial ramp-up with no runaway growth observed.
For Offer/AMM transaction mixload capacity, MPT/MPT token pairs demonstrated notably higher throughput than IOU/IOU under the MainNet-modeled load mix, achieving 282.57 TPS vs. 207.43 TPS in the 1-hour run and 281.11 TPS vs. 206.85 TPS over the 5-hour endurance run. Overvalidation rates remained low and well within acceptable bounds across both configurations, and consensus latency stayed comfortably within the 5-second target throughout all test runs.
From a deployment perspective, the MPTVersion2 amendment can be safely activated without compromising MainNet SLOs for throughput, consensus latency, or resource utilization. MPT assets are performant as first-class DEX participants, and the amendment introduces no regressions to existing IOU-based payment and DEX operations.
Top comments (0)