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_dex build against the 3.1.2 release under identical load and database conditions.
• Validate that the mpt_dex build 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.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
• 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:

1. Issuer accounts created MPT issuances via MPTokenIssuanceCreate, with lsfMPTCanTrade and lsfMPTCanTransfer flags set to enable DEX participation.
2. All holder accounts were authorized via MPTokenAuthorize.
3. Token issuers funded root accounts via Payment.
4. All four load servers distributed MPT balances to the full holder population.
5. 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

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 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:

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

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

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

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.

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.

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.

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.