DEV Community: RippleX Developers

Batch V1.1: What Changed and Why It's Ready

Mayukha Vadari — Mon, 14 Sep 2026 13:52:53 +0000

What is Batch?

Batch (XLS-56) allows multiple XRPL transactions from different accounts to execute atomically in a single ledger close. For example, if any inner transaction fails during the all-or-nothing mode of the feature, the entire batch reverts. This makes various types of atomic operations much easier, and is also foundational infrastructure for multi-party coordination on the XRPL: atomic swaps, coordinated settlements, and any workflow where two or more parties need to move in lockstep without trust assumptions.

What happened with the original Batch (v1.0)

On February 19, 2026, security researchers and Cantina AI identified a critical logic flaw in the signature-validation routine of the original Batch amendment. The function checkBatchSign, which validates that each inner-transaction account has authorized the batch, contained an early-return bug: when it encountered a signer whose account did not yet exist on the ledger, it immediately returned success and skipped validation of all remaining signers. This would have allowed an attacker to essentially execute arbitrary transactions on behalf of any victim accounts without their private keys.

See the full Vulnerability Disclosure Report here.

The amendment was in its voting phase and had not been activated on Mainnet. No funds were at risk. Within hours of receiving the report, UNL validators were advised to vote "No," Ripple's engineering team reproduced the issue with an independent unit test, and an emergency release was published, marking both Batch and fixBatchInnerSigs as "unsupported".

What changed in Batch V1.1

Batch V1.1 is a replacement amendment that ships the corrected implementation in xrpld v3.3.0. The primary focus was on fixing the bug found in February and further hardening the implementation.

We took the following steps to ensure that the new version is secure:

Checkpoint	Status
Root-cause fix (early-return elimination)	Complete, merged via PR #6446
Code review by 4 senior engineers	Complete
Sherlock Batch Attackathon contest	Complete
Halborn Batch re-assessment	Complete
Common Prefix Batch audit	Complete
AI-assisted static analysis pipeline (including a Cantina scan)	Integrated into review and release process
QA Devnet and testnet regression testing	Complete

In addition, we found and fixed the following bugs:

Batch Transaction Bypasses MPT Validation, Crashes Node
Simulate RPC tfInnerBatchTxn Flag Assertion Crash
Path Size Validation Bypass via Batch Transactions
preflight2 tfInnerBatchTxn flag bypasses signature verification in release builds
preflight1 batch parentBatchId invariant — assert-only enforcement with boolean logic error
checkValidity does not return early for valid inner batch transactions
Batch Signatures Miss Outer Account Binding
Batch signer ordering not enforced, allowing attacker to control authorization check order
Node crash via uncaught std::runtime_error from Batch::calculateBaseFee
buildBatchTxnIds hashes full inner array pre-count-cap at deserialization
Protocol bounds follow hashing and signature verification

Why Batch matters for the XRPL

Batch is a prerequisite or accelerant for several high-value XRPL use cases already under contract or in active pipeline, such as:

Atomic multi-party settlements. Institutional workflows (custody transfers, DvP settlement, cross-border payment finalization) require two or more accounts to act simultaneously. Batch removes the need for trust in execution ordering, eliminating a class of race conditions and partial-execution risks.

Developer experience and ecosystem growth. Batch is one of the most requested features by XRPL application developers and the community broadly. It enables patterns common on programmatic chains (such as multi-call, atomic bundles, and flash loans) natively on XRPL without smart contracts, reducing friction for new builders entering the ecosystem. Batch also enables DEXs, Wallets and Marketplaces to monetise on transactions they process by bundling the base transaction (such as a Payment) with a platform fee. There are many members of the XRPL ecosystem eager to use this feature.

Governance context

The original Batch incident demonstrated that the XRPL governance model works. A critical bug was reported, validators responded within hours, and no funds were ever at risk because the amendment had not yet been activated. The v1.1 replacement was given additional scrutiny precisely because of that history: broader code review, AI-assisted auditing, Sherlock contest, a Halborn re-assessment, and a Common Prefix audit on top of the standard internal audit process.

For validators voting on Batch V1.1 in xrpld version 3.3.0:

The root cause is fully understood and publicly documented (vulnerability disclosure report published February 25, 2026).
The fix addresses not just the specific bug but the class of vulnerability (early-return in validation loops, signing payload binding).
The review process has been expanded with additional tooling and reviewers relative to v1.0.
The business case is concrete: named partners, contracted use cases, and protocol-level dependencies are waiting on this capability.

Try it on Devnet today!

Batch Transaction - QA Test Report

Ramkumar SG — Tue, 08 Sep 2026 22:39:39 +0000

Test Report Date: 9/8/2026
Prepared By: sgramkumar
Environment: GitLab CI Runner (nix-debian)
Network: xrpld devnet + private CI network

Overview

This report presents the results of QA testing performed on Batch (XLS-56) Transactions across xrpld servers. Coverage targets the BatchV1_1 amendment, which supersedes the original Batch amendment and tightened BatchSigner authorization and signing semantics.

1. Feature

Feature Name: Batch (Atomic) Transactions

Description: Prior to this feature, an account that needed several operations to succeed or fail together had no way to bind them atomically; each transaction settled independently, leaving the risk of partial completion. Batch allows an account to package up to 8 inner transactions into a single outer Batch transaction that is processed as one atomic unit. Inner transactions execute under one of four modes — AllOrNothing, OnlyOne, UntilFailure, or Independent — and may be authorized across multiple accounts (BatchSigners), via delegated authority, via multi-signing, or sequenced by tickets. This unlocks reliable multi-step and multi-party workflows on the XRP Ledger.

Specification Reference: https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0056-batch

2. Test Scope

This report covers the full Batch surface as it stands under the BatchV1_1 amendment (xrpld PRs #5060, #6446). Testing focused on ensuring that:

All four execution modes (AllOrNothing, OnlyOne, UntilFailure, Independent) behave per the XLS-56 specification, including correct commit/rollback semantics
The 2–8 inner-transaction bounds, fee calculation, and tfInnerBatchTxn rules are enforced
Multi-account and multi-signed BatchSigner authorization is validated, including canonical signer ordering and the hardened BatchV1_1 signing preimage
Batch composes correctly with the full range of inner transaction types (Payments, Offers, Checks, Escrow, MPT, Vault/Loan operations, and more), and with the features that have special interaction rules at the batch authorization/sequencing layer — Permission Delegation (inner Delegate field), Sponsored Fees & Reserves (outer/inner Sponsor rules), Confidential MPT (in-batch proof staleness), and Tickets (inner TicketSequence)
Security-critical properties hold under adversarial input, including malformed BatchSigners, stale-proof inner transactions, replay, and structural/serialization attacks
Inner-transaction metadata (sfParentBatchID) and same-ledger inclusion are correctly reported

3. Types of Testing Conducted

Testing Type	Description
Functional	Verifying each execution mode, inner-transaction type, fee path, and RPC/metadata surface against the XLS-56 specification
Regression	Running the full xrpld test suite to confirm Batch changes did not break existing functionality
Adversarial / Security	Attack-matrix scenarios probing malformed BatchSigners, signature-binding violations, stale-proof inner transactions, replay, over-size batches, and structural/serialization smuggling
Cross-Feature	Interactions between Batch and Permission Delegation (XLS-75), Sponsored Fees & Reserves, Confidential MPT (XLS-96), and Tickets
End-to-End	Full flows spanning batch assembly, multi-party signing, submission, atomic commit/rollback, and downstream metadata validation via xrpld

4. Test Results Summary

Testing Type	Total Tests
Batch — Core Functional (execution modes, multi-account/multi-sign, tickets/replay/metadata, vault/loan/transaction types, signature & structural validation)	106
Batch — Adversarial / Security	56
Batch — Cross-Feature (Delegation, Sponsorship, Confidential MPT)	27
Batch — Total	189
Regression — xrpld (full suite)	5,088

Testcases: https://dev.to/ripplexdev/batch-transaction-testcases-1klf

Feature commit history:

- Introduced as  Batch  in PR #5060 (2a61aee562, merged 2025-05-23)
- Disabled in v3.1.1 due to a critical bug discovered in the original implementation
- Replaced by  BatchV1_1  (hardened BatchSigners + signing preimage) in PR #6446 (86d8b244d6, merged 2026-07-01)

Related xrpld changes covered in this round:

PR #5060 — Initial Batch (XLS-56) feature — four execution modes, parentBatchId propagation
PR #6446 — BatchV1_1 — supersedes Batch/fixBatchInnerSigs, tightens BatchSigner authorization and signing-message construction
PR #7736 — enforces kMaxBatchTxCount (rejects >8 inner transactions at STTx construction)
PR #7279 — delegated Confidential MPT inner-transaction cases inside Batch

Related specification change:

XRPL-Standards updated XLS-0056 to align with the BatchV1_1 implementation (BatchSigners sorting/signing payload, tfInnerBatchTxn common-field semantics)

5. Bugs Reported

All internal bugs are fixed and there are no Critical Open bugs.

6. Conclusion

Batch (XLS-56) Transactions have now been exercised across 189 dedicated tests spanning core functional coverage (four execution modes, multi-account/multi-sign authorization, tickets/replay/metadata, and inner transaction-type coverage), adversarial / security scenarios, and cross-feature interactions with Permission Delegation, Sponsored Fees & Reserves, and Confidential MPT. In addition, the full xrpld (5,088) regression suite has been executed to confirm no downstream breakage.

All security-critical properties documented in XLS-56 have been validated, including:

Correct atomic commit/rollback semantics for every execution mode (AllOrNothing rolls the whole batch back on any inner failure; OnlyOne, UntilFailure, and Independent apply their defined subsets)
Enforcement of the 2–8 inner-transaction bounds and rejection of over-size batches before preflight work (PR #7736)
Correct BatchSigner authorization under the hardened BatchV1_1 signing preimage, including canonical ascending signer ordering and multi-signed BatchSigners
Correct interaction with delegated authority, sponsorship, tickets, and Confidential MPT inner transactions, including stale-proof rollback under AllOrNothing
Accurate inner-transaction metadata (sfParentBatchID) and same-ledger inclusion reporting

The feature is considered ready for production use at the tested commit level. Future updates to this report will follow any material additions to the Batch surface.

Batch Transaction - Testcases

Ramkumar SG — Tue, 08 Sep 2026 21:40:47 +0000

Automated test coverage for the Batch transaction feature (XLS-56), grouped by the invariant or execution mode each test exercises with 189 tests.

Category	Test Count
Execution Modes	42
Multi-Account & Multi-Sign	23
Tickets, Replay & Metadata	7
Vault, Loan & Transaction Types	24
Signature & Structural Validation	10
Security & Adversarial	56
Cross-Feature Interactions	27
Total	189

1. Execution Modes

AllOrNothing

Test Batch allornothing all payments succeed
Test Batch allornothing submit batch multiple times
Test Batch allornothing one payment fails
Test Batch allornothing all payments fail
Test Batch allornothing mixed transaction types
Test Batch allornothing fee calculation
Test Batch allornothing max inner transactions
Test Batch allornothing more than max inner transactions
Test Batch allornothing cash same check multiple times
Test Batch allornothing fail and then succeed
Test Batch allornothing with tickets
Test Batch allornothing deep rollback on late inner failure
Test Batch allornothing value conservation

OnlyOne

Test Batch onlyone first succeeds
Test Batch onlyone first fails second succeeds
Test Batch onlyone all fail
Test Batch onlyone offer priority
Test Batch onlyone max inner transactions
Test Batch onlyone more than max inner transactions
Test Batch onlyone cash same check multiple times
Test Batch onlyone fail and then succeed

UntilFailure

Test Batch untilfailure all succeed
Test Batch untilfailure stops at first
Test Batch untilfailure stops at second
Test Batch untilfailure stops at third
Test Batch untilfailure sequential setup
Test Batch untilfailure progressive payments
Test Batch untilfailure mixed success failure pattern
Test Batch untilfailure max inner transactions
Test Batch untilfailure more than max inner transactions
Test Batch untilfailure cash same check multiple times
Test Batch untilfailure fail and then succeed

Independent

Test Batch independent all succeed
Test Batch independent some fail
Test Batch independent all fail
Test Batch independent parallel operations
Test Batch independent mixed transaction types
Test Batch independent account setup operations
Test Batch independent max transactions
Test Batch independent more than max transactions
Test Batch independent cash same check multiple times
Test Batch independent fail and then succeed

2. Multi-Account & Multi-Sign

Multi-Account

Test Batch multiaccount workflow all payments succeed
Test Batch multiaccount atomic swap xrp for xrp
Test Batch multiaccount atomic swap xrp for token
Test Batch multiaccount circular three way swap
Test Batch multiaccount with submitter not in inner txns
Test Batch multiaccount without signers
Test Batch multiaccount with max signers
Test Batch multiaccount with more than max signers
Test Batch multiaccount txn1 fails txn2 succeeds
Test Batch multiaccount create check succeeds cash check fails
Test Batch multiaccount delete accounts too soon with other account as signer
Test Batch multiaccount delete accounts after flag ledger with other account as signer
Test Batch multiaccount delete submitting account after flag ledger with no signer
Test Batch multiaccount delete submitting account after flag ledger with signer
Test Batch multiaccount alice creates offer bob creates offer
Test Batch multiaccount create nftokenmint nftokenoffercreate fails reverts nftokenmint
Test Batch multiaccount exploit steal funds
Test Batch multiaccount ticket based outer succeeds

Multi-Sign

Test multisigned outer batch succeeds
Test multisigned outer with multisigned batch signer succeeds
Test multisigned outer below quorum rejected tefBAD_QUORUM
Test multisigned batch signer below quorum rejected tefBAD_QUORUM
Test multisigned outer with unauthorized signer rejected tefBAD_SIGNATURE

3. Tickets, Replay & Metadata

Tickets

Test Batch inner txns consume tickets succeeds
Test Batch inner tickets used out of order succeeds
Test Batch inner with sequence and ticket rejected temSEQ_AND_TICKET
Test Batch duplicate ticket same account rejected temREDUNDANT
Test Batch nonexistent ticket rolls back allornothing

Replay

Test Batch resubmission is rejected and pays inner once

Metadata

Test Batch inner txns carry parent batch id and share ledger

4. Vault, Loan & Transaction Types

Single-Asset Vault (SAV)

Test Batch with vault create
Test Batch with vault set
Test Batch with vault deposit
Test Batch with vault withdraw
Test Batch with vault delete
Test Batch with vault clawback

LoanBroker / Loan

Test Batch with loan broker set
Test Batch with loan broker delete
Test Batch with loan broker cover deposit
Test Batch with loan broker cover withdraw
Test Batch with loan broker cover clawback
Test Batch with loan set
Test Batch with loan pay
Test Batch with loan delete
Test Batch with loan manage

Supported Transaction Types

Test Batch transaction type trustset
Test Batch transaction type offercreate
Test Batch transaction type account set
Test Batch transaction type escrow create
Test Batch transaction type check create
Test Batch transaction type nftokenmint
Test Batch with ticket create transaction
Test Batch transaction type signerlistset
Test Batch transaction type depositpreauth

5. Signature & Structural Validation (V1.1 Readiness)

Readiness / Preimage

Test Batch v1.1 preimage matches pr1010 single
Test Batch v1.1 preimage matches pr1010 multi
Test Batch v1.1 preimage layout
Test batchsigners signature binds outer account sequence and signer account
Test Batch signers sorted by account id
Test sdk encode for signing batch natively binds account and sequence

Preflight Error Ordering

Test Batch inner tx with negative fee rejected at preflight
Test Batch inner tx with positive xrp fee rejected at preflight
Test Batch inner tx with iou fee rejected at preflight
Test Batch inner tx with zero fee passes fee preflight

6. Security & Adversarial

Structural / Flag Enforcement

Test Batch empty raw transactions
Test Batch with one raw transaction
Test Batch with all inner transactions having no tfInnerBatchTxn flag
Test Batch with some inner transactions having no tfInnerBatchTxn flag
Test Batch with all inner transactions having incorrect tfInnerBatchTxn flag
Test Batch with tfInnerBatchTxn flag set for outer transaction
Test Batch with no mode set for outer transaction
Test Batch with invalid mode set for outer transaction
Test Batch with inner transactions having no fee field
Test Batch with inner transactions having invalid fee values
Test Batch with inner transactions having bad fee values
Test Batch with inner transactions with SigningPubKey
Test Batch with inner transactions with fee and SigningPubKey
Test Batch with inner transactions with TxnSignature
Test Batch with inner transactions with Signers
Test Batch with inner transactions with SponsorSignature
Test Batch with inner transactions with CounterpartySignature
Test Batch with invalid inner transactions
Test Batch inside non empty batch
Test Batch inside empty batch
Test Batch inner txns with same sequence leaves no state change
Test Batch inner txns with same sequence
Test Batch inner txns with past sequence
Test Batch inner txns with future not incremental sequences
Test Batch with account does not exist
Test Batch with deposit auth on account
Test Batch with master key disabled on account
Test Batch all payments with destination account not funded

Adversarial Attack Matrix

Test Batch with single inner tx returns temARRAY_EMPTY
Test inner tx with non zero fee returns temBAD_FEE
Test inner tx with non empty signing pubkey returns temBAD_REGKEY
Test inner tx missing inner batch flag returns temINVALID_FLAG
Test standalone payment with tfInnerBatchTxn flag rejected
Test Batch with outer account in BatchSigners rejected
Test Batch with duplicate BatchSigners rejected
Test Batch with BatchSigner for unrelated account rejected
Test Batch BatchSigners signature for different batch rejected
Test Batch with single inner transaction rejected temARRAY_EMPTY
Test Batch with nested inner batch rejected
Test Batch with duplicate inner sequences rejected temREDUNDANT
Test Batch inner setregularkey succeeds when outer signed by master
Test Batch innerbatch flag on standalone payment rejected
Test Batch v1.1 oversized inner array rejected as tem
Test Batch v1.1 far oversized inner array survives eager hashing
Test Batch v1.1 far oversized inner array at scale survives eager hashing
Test Batch v1.1 batchsigner sig bound to outer sequence
Test Batch v1.1 batchsigner sig bound to outer account
Test Batch v1.1 unsorted batchsigners rejected
Test Batch v1.1 standalone tx with inner batch flag rejected
Test Batch v1.1 standalone oversized path stays tel
Test Batch v1.1 batchsigners over kmax rejected
Test non batch tx with raw transactions rejected at construction
Test non batch raw transactions rejection does not crash server
Test Batch outer with sfDelegate rejected by notdelegable template
Test Batch inner notdelegable type with sfDelegate inner rejected
Test Batch inner delegated without permission grant returns terNO_DELEGATE_PERMISSION

7. Cross-Feature Interactions

Delegation

Test delegate as outer account executes delegated inner succeeds
Test delegate as batch signer authorizes delegated inner succeeds
Test delegated inner without batch signer rejected temBAD_SIGNER
Test delegated inner signed by account holder rejected temBAD_SIGNER
Test delegate without permission inner fails and batch rolls back

Sponsorship

Test outer batch with reserve sponsorship flag rejected temINVALID_FLAG
Test inner batch txn with fee sponsorship rejected temINVALID_FLAG
Test inner batch txn with sponsor signature material rejected temBAD_SIGNATURE
Test prefunded fee sponsored outer batch succeeds

Confidential MPT

Test Batch confidential mpt two sends with stale proof allornothing
Test Batch confidential mpt independent send with one failing
Test Batch confidential mpt convert then merge inbox allornothing
Test Batch delegated send missing permission allornothing
Test Batch delegated send with delegate as outer needs no batch signer
Test Batch delegated send with delegate as outer with batch signer
Test Batch confidential mpt two chained sends same sender allornothing
Test Batch confidential mpt send then convert back same sender allornothing
Test Batch confidential mpt three chained sends same sender allornothing
Test Batch confidential mpt chained send wrong predicted ciphertext fails
Test Batch only one with two valid chained sends executes first only
Test Batch only one first send to unconverted fails falls through to second
Test Batch until failure first send commits then stale second fails
Test Batch allornothing issuer lock then alice send rolls back both
Test Batch independent three holders converts coa aggregate correct
Test Batch allornothing inner revokes delegate then later inner uses it rolls back
Test Batch two chained delegated sends from same delegator both commit
Test delegated send after delegator loses domain membership fails

Ripple’s Recommendation: Withdraw the XChainBridge Amendment (XLS-38)

David Fuelling — Thu, 27 Aug 2026 15:00:00 +0000

When we set out to bring cross-chain bridging natively to the XRP Ledger, the XChainBridge amendment (XLS-38) was our proposed solution. Today, we're recommending that the XRPL community withdraw XChainBridge along with the related fixXChainRewardRounding amendment.

What XLS-38 Set Out to Do

XLS-38 defined a protocol for native cross-chain bridges on the XRPL to enable custom sidechains. Rather than delegating to third-party bridge operators, it proposed a model where a decentralized network of "witness servers" would observe and attest to transactions across chains, enabling assets to move between XRPL mainnet and any connected sidechain.

The original vision was compelling: give developers the building blocks to create custom sidechains: private chains, permissioned networks, or experimental environments for features not yet available on mainnet. XLS-38 was also intended to bridge the XRPL EVM Sidechain to mainnet, with XRP as the native gas token.

Why We Chose Axelar for the EVM Sidechain

As we prepared to launch the XRPL EVM Sidechain (a collaboration between Peersyst, Ripple, and the broader XRPL community), we conducted a thorough evaluation of bridging options, weighing security, user experience, decentralization, and long-term operational sustainability.

The XLS-38 witness server model presents inherent trade-offs between security and decentralization that become harder to manage as the value locked in a bridge grows. The architecture places significant trust in a set of witness server operators: the larger and more decentralized that set, the better the security; but also the greater the coordination overhead, the harder the governance, and the more diffuse the accountability. For a bridge securing a public chain's native gas token, these tensions don't have easy resolutions, and Ripple concluded that it wasn't an area where we had the operational expertise to do it well at scale. Building and managing bridges between public blockchains is genuinely specialized work.

Axelar, on the other hand, is purpose-built for exactly this problem. Its 75+ validators, threshold signature scheme, and key-rotation discipline reflect the kind of operational maturity that takes years to develop, backed by experience bridging across 55+ blockchains. That expertise isn't easy to replicate, and Ripple's team didn't see a need to when a capable partner already existed.

In June 2024¹, we announced the decision to use the Axelar network alongside the XRPL EVM Sidechain launch. At that time, we committed to leaving the XLS-38 amendment available for a vote while Ripple's UNL validator would continue voting No, and pledged to give the community 12–15 months to demonstrate interest in XLS-38 as a foundation for private sidechain use cases.

What We Observed

That window has now passed. During this time, we actively engaged with developers, monitored community forums, and looked for concrete projects or proposals that would benefit from an activated XLS-38 bridge on mainnet. We didn't find the level of adoption or developer interest that would justify keeping the amendment moving toward activation.

A few observations drove our current thinking:

The EVM Sidechain bridge is well-served by Axelar. The primary use case that motivated XLS-38's development is fully addressed, and we believe better addressed, by the Axelar integration.

Lack of Demand. No significant private sidechain demand materialized for private sidechains that would use XLS-38 specifically. We wanted to see real developer projects that specifically required a native XLS-38 bridge, but that hasn't emerged at the level we hoped.

Maintaining inactive code carries real costs. Keeping the XChainBridge code in xrpld creates an ongoing maintenance burden and a source of confusion for new contributors, with no corresponding benefit to the network today. We estimate that withdrawing this amendment would let us remove more than 10,000 lines of code from xrpld, reducing the surface area we maintain and review.

That said, we want to be clear: this is a recommendation, not a unilateral decision. If there are developers or organizations actively building on XLS-38, or who have concrete plans to do so, we want to hear from you. Ripple controls one vote among many on the XRPL, and we're open to revisiting this assessment if the community presents a strong case.

Different Problems, Different Tools

The Axelar decision was specific to the EVM Sidechain, which is a public chain bridging XRP to a permissionless EVM environment. XLS-38, by contrast, was meant to support a wider range of use cases: private chains, permissioned networks, experimental environments for features not yet on mainnet. The reality for that wider set is that no single mechanism fits every use case.

Axelar and Wormhole represent one class of solution (trust-minimized bridging between mature public chains), but the broader space includes ZK-based approaches, L2-style architectures, and early research directions like consensus-within-consensus. Active work is happening across all of these, and the right tool depends on the problem.

None of these is a drop-in replacement for XLS-38, and none is the right answer for every problem. They're a portfolio. Part of our reason for proposing to withdraw XLS-38 is that, as a single mechanism trying to serve all of these use cases, it was solving too many problems at once.

How the Withdrawal Process Would Work

If the community aligns with this direction, the next steps are deliberate and consensus-driven, which is exactly how it should be. Here's how it would unfold:

Step 1: Mark the amendment as Obsolete. Ripple's intended first step is to open a pull request to the xrpld repository that sets VoteBehavior::Obsolete for the XChainBridge feature. Once this change is merged, xrpld servers running that version will automatically vote against the amendment and will never vote in favor of it, regardless of operator configuration.

Step 2: Network consensus. As validators update their xrpld software to versions that include this change, the amendment will gradually lose support across the network. Once all active validators consider the amendment Obsolete, it can be removed from the codebase entirely.

Step 3: Code removal. A subsequent update will fully remove the XChainBridge and fixXChainRewardRounding code from xrpld.

What This Means for You

If you're building on the XRPL EVM Sidechain: Nothing changes. The Axelar bridge is your path to and from XRPL mainnet, and it will continue to be supported and improved.

If you're a validator: When and if you upgrade to the xrpld version that includes the Obsolete vote behavior, your node will automatically stop voting for XChainBridge. No action required on your part beyond the normal upgrade cycle.

If you were exploring XLS-38 for a private sidechain: This is the most important group we want to hear from. Please reach out on the XRPL developer Discord or engage on GitHub to share your use case. Concrete plans and active projects are exactly the kind of signal that could change our recommendation.

If you're a contributor to xrpld: The PR to mark XChainBridge as Obsolete will go through normal open-source review. We welcome technical feedback and discussion.

Looking Ahead

This recommendation reflects something broader about how we'd like to think about the XRPL: lean, purposeful, and battle-tested. Carrying unused code paths through years of mainnet evolution has real costs, such as maintenance burden, attack surface, and onboarding complexity for new contributors. XLS-38 is unlikely to be the last withdrawal we propose for those reasons.

We're grateful to the developers who built witness server tooling, the community members who debated the design over the years, and the validators who weighed in. That work wasn't wasted, but instead sharpened our understanding of bridging trade-offs and shaped how we now think about cross-chain interoperability more generally.

We'll leave a comment period open before moving forward. If you have feedback, a use case to share, or a reason we should reconsider, please weigh in on GitHub or in the XRPL developer Discord.

[1] For more context, see our June 2024 post on XRPL EVM Sidechain: Enhancing Interoperability with Axelar Bridge.

Account Permission Delegation - QA Test Report

Ramkumar SG — Wed, 26 Aug 2026 19:18:57 +0000

Test Report Date: 8/26/2026
Prepared By: QA Team [sgramkumar, mkunasani, manasip-prog]
Environment: GitLab CI Runner (nix-debian)
Network: xrpld devnet + private CI network

Overview
This report presents the updated results of QA testing performed on Account Permission Delegation across xrpld servers. It supersedes the initial report from May 2025, reflecting the substantial expansion of test coverage that has occurred as the feature evolved through follow-up xrpld changes.

1. Feature

Feature Name: Account Permission Delegation

Description: Prior to this feature, critical issuer actions — such as authorizing trustlines — required direct control by the account's own keys, hindering operational efficiency and complex use cases. Account Permission Delegation empowers account holders to selectively delegate specific permissions to other accounts, enhancing account usability without compromising security. This mechanism unlocks new possibilities for XRPL applications, including multi-party workflows and advanced account management strategies.

Specification Reference: https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0075-permission-delegation

2. Test Scope

This report covers the full delegation surface as it stands after the follow-up xrpld changes (PRs #6126, #7064, #7584, #7640). Testing focused on ensuring that:

All specified functionalities behave per the XLS-0075 specification
The API handles both valid and invalid input gracefully
Delegated transactions interact correctly with adjacent features (Batch, Confidential MPT, transaction queue, multi-signing)
Security-critical properties hold under adversarial input, including permission-escalation attempts via flag/field side-channels
Behavior is consistent across both RPC and WebSocket interfaces

3. Types of Testing Conducted

Testing Type	Description
Functional	Verifying each transaction, permission grant, and RPC path against the feature specification
Regression	Running full xrpld test suites to confirm delegation changes did not break existing functionality
Adversarial / Security	Attack-matrix scenarios probing self-delegation, permission-scope escalation, flag/field smuggling, granular-permission union semantics, and revocation edge cases
Cross-Feature	Interactions between Delegation and Batch (XLS-56), Confidential MPT, the transaction queue, and multi-signing
End-to-End	Full flows spanning delegation setup, delegated submission, revocation, and downstream validation via xrpld

4. Test Results Summary

Testing Type	Total Tests
Permission Delegation — Core Functional	112
Permission Delegation — Adversarial / Security	48
Permission Delegation — Cross-Feature (Batch, Confidential MPT, TxQ)	19
Permission Delegation — Total	179
Regression — xrpld (full suite)	5,088

Testcases: https://dev.to/ripplexdev/account-permission-delegation-testcases-3j0b

Feature commit history:

- Introduced as `PermissionDelegation` in PR #5354 (2db2791805, 2025-05-08)
- Marked unsupported (2ae65d2fdb, 2025-09-18) pending security fix
- Renamed to `PermissionDelegationV1_1` with security fix in PR #5825
  (fa69918124, 2025-10-31)
- Re-supported (`Supported::Yes`) in PR #6613 (772ea80a25, 2026-06-17)

Related xrpld changes covered in this round:

PR #5354 — Initial PermissionDelegation feature
PR #5650 — fixDelegateV1_1 — restrictions on Permission Delegation
PR #5825 — Security vulnerability fix + rename to PermissionDelegationV1_1
PR #6126 — account_tx delegate filter parameter
PR #6729 — Delegation tests for Confidential Transfers
PR #6808 — Confidential delegation tests with tickets

5. Bugs Reported

All Internal bugs are fixed and there are no Critical Open bugs

6. Conclusion

Account Permission Delegation has now been exercised across 179 dedicated tests spanning core functional coverage, adversarial / security scenarios, and cross-feature interactions — a substantial expansion from the 66 tests reported at initial feature landing. In addition, the full xrpld (5,088) regression suites have been executed to confirm no downstream breakage.

All security-critical properties documented in XLS-0075 have been validated, including:

Correct rejection of self-delegation, unknown permissions, and NotDelegable transaction types
Enforcement of granular-permission field/flag restrictions with no side-channel escalation via SetFlag / ClearFlag or restricted-field assignment
Correct interaction with the transaction queue (delegated transactions cannot queue — PR #7640)
Correct account_tx attribution semantics under regular-key and multi-sign paths (PR #6126)
Independence of delegation from asfDisableMaster (delegated payments continue to work after the master key is disabled)
The feature is considered ready for production use at the tested commit level. Future updates to this report will follow any material additions to the delegation surface.

Account Permission Delegation - Testcases

Ramkumar SG — Wed, 26 Aug 2026 19:15:41 +0000

Category	Test Count
Core Functional	112
Adversarial / Security	48
Cross-Feature Interactions	19
Total	179

Core Functional

Test DelegateSet with permissions field
Test DelegateSet skipped before payment
Test DelegateSet without permissions field
Test DelegateSet with empty list
Test DelegateSet with permissions as non-JSON
Test DelegateSet by non-existing account
Test DelegateSet by non-existing authorize account
Test DelegateSet by account with deposit auth enabled
Test DelegateSet and submit different transaction
Test DelegateSet and submit transaction as original account
Test DelegateSet with same permission
Test DelegateSet to self
Test DelegateSet with invalid permission
Test DelegateSet with restricted permission
Test DelegateSet with 10 permissions
Test DelegateSet with more than 10 permissions
Test DelegateSet with multiple permissions
Test DelegateSet and delete delegated account
Test DelegateSet and delete delegating account
Test DelegateSet and make pay self
Test DelegateSet and make pay delegated account without deposit auth
Test DelegateSet and make pay delegated account with deposit auth
Test DelegateSet authorize multiple users
Test DelegateSet and submit AccountSet as original account
Test DelegateSet and make payment
Test DelegateSet and offer create
Test DelegateSet and create and cash check
Test DelegateSet and create and cancel check
Test DelegateSet and create and finish escrow
Test DelegateSet and create and cancel escrow
Test DelegateSet and create and claim paychan
Test DelegateSet and create and fund paychan
Test DelegateSet and payment on ticket
Test DelegateSet and create trustline
Test DelegateSet and clawback
Test DelegateSet and AMM create
Test DelegateSet and AMM deposit
Test DelegateSet multiple times with same permission
Test DelegateSet remove permission add same permission
Test DelegateSet change in permission
Test DelegateSet and update with invalid permission
Test DelegateSet granular permission TrustlineAuthorize
Test DelegateSet granular permission TrustlineFreeze and TrustlineUnfreeze individual freeze
Test DelegateSet granular permission TrustlineFreeze global freeze
Test DelegateSet and payment with deep freeze
Test DelegateSet granular permission AccountDomainSet
Test DelegateSet granular permission AccountEmailHashSet
Test DelegateSet granular permission AccountMessageKeySet
Test DelegateSet granular permission AccountTransferRateSet
Test DelegateSet granular permission AccountTickSizeSet
Test DelegateSet granular permission PaymentMint
Test DelegateSet granular permission PaymentBurn
Test DelegateSet granular permission MPTokenIssuanceLock and MPTokenIssuanceUnlock
Test DelegateSet on account with master key disabled
Test DelegateSet with empty Permissions revokes delegate authority
Test DelegateSet with NotDelegable permission rejected
Test DelegateSet with empty Permissions when no existing Delegate object is rejected
Test Delegate object appears in authorized account's account_objects
Test Delegated payment with basic permission succeeds
Test Delegated unauthorized tx type returns terNO_DELEGATE_PERMISSION
Test Delegated payment consumes delegate fee, not source fee
Test AccountDelete on authorized account removes Delegate from both directories
Test Token escrow — delegate create and finish escrow (IOU)
Test Token escrow — delegate create and finish escrow (MPT)
Test Circular delegation — positive scenario
Test Circular delegation — negative scenario
Test Chain delegation — positive scenario
Test Chain delegation — negative scenario
Test Delegated account with multiple signers and master key disabled
Test Delegated account with multiple signers and master key not disabled
Test Authorized account with multiple signers and master key disabled
Test Authorized account with multiple signers and master key not disabled
Test DelegateSet with base reserve on delegating account
Test DelegateSet with base reserve on delegated account
Test DelegateSet with no funds for fee on delegated account
Test Delegation to Batch tfAllOrNothing — all payments (outer transaction)
Test Delegation to Batch tfAllOrNothing — all payments (inner transaction)
Test Delegate AccountSet WalletLocator granular permission
Test Delegate AccountSet NFTokenMinter granular permission
Test Delegate AccountSet combined field and flag
Test Delegate AccountSet ClearFlag granular permission
Test Delegate AccountSet SetFlag with granular permission
Test Delegate granular permission exceeds scope
Test Delegate multiple granular permissions with no full AccountSet
Test Delegate AccountSet restricted field returns correct error code
Test Delegate transaction with fee greater than account balance
Test Delegate payment amount exceeds balance
Test Delegate reserve manipulation via trustline creation
Test Delegate using regular key instead of master
Test Delegator regular key change during active delegation
Test Batch tfAllOrNothing with payment and DelegateSet
Test DelegateSet with Delegate field set
Test Delegate trustline freeze without permission
Test Delegate bypass RequireAuth flag
Test Delegate permission change removes old permission
Test Delegate payment with deposit auth bypass attempt
Test Delegate offer crossing with unauthorized account
Test Delegate conflicting granular permissions
Test Delegate all granular AccountSet permissions — no flag access
Test Delegate with zero-amount payment
Test Delegate multi-signed transaction
Test Delegate with multi-signers on delegated and authorized account
Test Payment offline signing
Test Delegate payment with offline signing
Test Delegate payment by third party with offline signing
Test account_tx delegate_filter=actor returns delegated txns
Test account_tx delegate_filter=authorizer returns delegated txns
Test account_tx counter_party narrows results
Test account_tx delegate_filter=actor returns empty for authorizer
Test account_tx counter_party no-match returns empty
Test account_tx with malformed delegate returns invalidParams
Test account_tx with malformed counter_party returns actMalformed

Adversarial / Security

Test DelegateSet replaces existing permissions (silently revoking dropped)
Test DelegateSet to self rejected with temMALFORMED
Test DelegateSet with duplicate PermissionValues rejected
Test DelegateSet with eleven permissions rejected
Test 3.2.0 Vault and Batch tx types are not delegable
Test 3.2.0 Loan tx types are not delegable
Test Delegated Batch outer returns terNO_DELEGATE_PERMISSION
Test Account SignerList cannot authorize delegated tx (returns tefNOT_MULTI_SIGNING)
Test Delegate SignerList can authorize delegated tx
Test Delegated tx signed by delegate's master key succeeds
Test PR #7064 — delegate sign_for on own delegated tx returns invalidParams
Test PR #7064 — delegator can be signer when in delegate's SignerList
Test Delegate to self rejected with temMALFORMED
Test DelegateSet with duplicate permission rejected
Test DelegateSet with unknown PermissionValue rejected
Test DelegateSet to non-existent account returns tecNO_TARGET
Test Batch transaction type is not delegable
Test Delegated tx after revocation returns terNO_DELEGATE_PERMISSION
Test Delegated payment works after master key disabled
Test Delegate field set to own account rejected with temBAD_SIGNER
Test Delegated no-op AccountSet rejected
Test Delegated no-op TrustSet rejected
Test Delegated SignerListSet rejected at preflight
Test Delegated SetRegularKey rejected at preflight
Test AccountSet WalletSize field rejected under granular AccountDomainSet delegate
Test TrustlineFreeze rejects disallowed flag tfSetNoRipple
Test TrustlineFreeze rejects disallowed field QualityIn
Test PaymentBurn rejects disallowed flag tfPartialPayment
Test PaymentBurn rejects disallowed field Paths
Test Union of two granular permissions still forbids fields ungranted by either
Test Union of Freeze and Unfreeze widens allowed flags but not fields
Test AccountDomainSet delegate cannot smuggle SetFlag asfRequireAuth
Test AccountDomainSet delegate cannot smuggle SetFlag asfDisableMaster
Test AccountDomainSet delegate cannot smuggle NFTokenMinter via WalletSize
Test MPTokenIssuanceLock rejects disallowed field DomainID
Test MPTokenIssuanceLock rejects unlock flag
Test PaymentBurn delegate cannot flip issuer to mint
Test PaymentMint delegate cannot flip issuer to burn
Test PaymentBurn delegate rejected when holder balance is zero
Test PaymentMint delegate rejected when destination lacks trustline
Test Granular Mint/Burn do not authorize XRP payment
Test DelegateSet rejects truncating PermissionValue
Test PR #6126 — actor filter ignores regular-key-signed payment
Test PR #6126 — actor filter ignores multi-sig-signed non-delegated payment
Test PR #6126 — delegate marker without delegate param rejected
Test PR #6126 — non-delegate marker with delegate param rejected
Test PR #6126 — delegated tx with multi-signed delegatee matches both filters
Test PR #6126 — delegate actor filter paginates all delegated txns

Cross-Feature Interactions

Test Delegate as outer account executes delegated inner (succeeds)
Test Delegate as BatchSigner authorizes delegated inner (succeeds)
Test Delegated inner without BatchSigner rejected with temBAD_SIGNER
Test Delegated inner signed by account holder rejected with temBAD_SIGNER
Test Delegate without permission — inner fails and Batch rolls back
Test Delegate ConfidentialMPTSend — basic
Test Delegate ConfidentialMPTSend — missing permission
Test Delegate ConfidentialMPTConvert
Test Delegate ConfidentialMPTMergeInbox
Test Delegate ConfidentialMPTConvertBack
Test Delegate ConfidentialMPTClawback by issuer
Test Delegate — send permission only cannot ConvertBack
Test Delegate — ConvertBack permission only cannot send
Test Delegate ConfidentialMPTClawback with non-issuer account rejected at preflight
Test Delegate — revoked permission blocks subsequent use
Test Delegate — self-delegation rejected
Test Delegate — ConfidentialMPTSend with proof over delegate keys rejected
Test PR #7640 — delegated payment rejected with telCAN_NOT_QUEUE when ledger full
Test PR #7640 — delegated payment succeeds when paying open ledger fee

UBRI Student Builder Residency Cohort 3.0: A New Frontier for High-Impact XRPL Innovation

Emma Nasseri — Mon, 29 Jun 2026 14:48:06 +0000

This spring marked Cohort 3.0 of the XRPL Student Builder Residency (SBR), a program run by Ripple's University Blockchain Research Initiative (UBRI) that supports the development of the next generation of blockchain developers through global university partnerships.

SBR 3.0 brought together an elite cohort of student builders from universities around the world to imagine, build, and ship new use cases on the XRP Ledger.

The 14 selected students built leveraging Smart Escrows (XLS-100), Ripple’s RLUSD stablecoin, interoperability primitives, the new Lending Protocol (XLS-66), and more.

Project Focus

From lending protocols to cross-border payment rails, here's what the cohort shipped:

Atlas (Sankara Wigneswaran, ESILV Paris): An overcollateralized lending protocol built on the XRP Ledger.

Cascrow (Paul Wagner & Jan-Niklas Möller, EBS University): An AI-powered verification and escrow platform on XRPL that automates RLUSD payouts once milestone proof is validated.

ShipSure (Hassene Ezzeddine, ETH Zurich): A trustless cross-chain escrow platform that automatically releases XRP payments to sellers only when real-world FedEx delivery is cryptographically verified on-chain via Flare's Data Connector.

Returnee (Sejal Jain, Cornell Tech): A smart package drop-off box for apartment buildings that gives residents an instant refund the moment the courier verifies their return.

Zipp (Antonio Meneses, IE Madrid): Automates cross-border supplier payments for Latin American importers using AI invoice extraction and XRPL settlement.

TerraSwap (Youssef Jeddi, EPFL-ETHZ): A stablecoin DEX on XRPL where compliance is enforced at the protocol level through credential-gated Permissioned Domains.

Verix (Sumit Shinde, National University of Singapore): A trustless task settlement for AI agents.

Sidiq - صِدِّيق (Madiha Zafar, University of Birmingham): A decentralized interest-free lending protocol on the XRP Ledger, giving underserved communities access to Qard Hasan microloans.

UniPay (Junaid Oozeerally, NYU Abu Dhabi): A blockchain-based payment and escrow platform on XRPL that enables students across the world to securely and instantly access international educational services.

PayTrace (Ranjana K. Kodandaraman, University of Birmingham): A real-time cross-border payment intelligence layer for SMEs that provides end-to-end settlement visibility and invoice matching powered by the XRP Ledger.

DropIn (Aaron Zheng, University of Pittsburgh): A per-article micropayment platform where readers pay cents to unlock individual articles instead of committing to monthly subscriptions. Publishers set their own prices and receive instant payments directly via the XRPL.

SafiPoints (Enock Mecheo, NYU Abu Dhabi): A blockchain-powered loyalty platform where restaurants issue and redeem verifiable loyalty tokens on the XRP Ledger, and customers earn and claim rewards via SMS with no app download and no crypto knowledge required.

Freeway (Irene del Carmen Gracia Perez, IE University): A turnkey API gateway that lets developers monetize their endpoints using XRP prepaid credits.

Beyond the Code: What Four Weeks can Do

Most students came in as XRPL beginners. Four weeks later, nearly all were shipping independently on-chain. According to self-assessments, the students’ developer skills increased by an average of 52% and their knowledge of blockchain technology grew 98%.

Beyond the numbers, the students shared deeper wins and takeaways. In their own words:

"Made my first (and not last) project on XRPL." — Youssef

"Built a much stronger introduction to blockchain through a real end-to-end product." — Sejal

"Met with incredibly successful and driven people. It motivated me to work harder and become a better developer." — Junaid

92% of participants said they were proud of what they accomplished throughout the residency, and almost all are sure they’ll continue building. Nearly every student noted they hope to support the program in the future through peer mentorship as it continues to grow and create new opportunities for others.

Beyond generating creative XRPL projects or new use cases, the Student Builder Residency is about supporting young builders developing cutting-edge technology while paving the paths for others to follow them.

Looking To The Future

Across three cohorts, the Student Builder Residency has produced 40+ high-quality projects built on the XRP Ledger, shipped by students from 28 universities across the globe.

The next generation of developers is already building solutions for the future of financial technology. Between classes and exams, they’ve been hard at work ideating, innovating, and iterating infrastructure for the internet of value.

This program could not have been possible without the dedicated mentors Tushar Pardhe (WellArrive), Modupe Diyaolu (meCash), Ashley Rho (Ripple), Sree Sanakkayala (CoverMax), Dhruv Shah (Flare), Filip Koprivec (Flare), and Satyam Singh.

We are especially grateful for the support of this year’s peer mentors and program alumni Stan Stelcher (SBR 1.0), Alex Salsali (SBR 2.0), and Nischay Rawal (SBR 2.0) who have been integral in shaping the culture and community of the Student Builder Residency across all three cohorts.

Follow Ripple (LinkedIn, X) on social media for future updates!

The Road Toward Mainnet: A Security-First Approach to XRPL Lending Protocol

J. Ayo Akinyele — Thu, 18 Jun 2026 15:15:00 +0000

Over the last several months, XRP Ledger (XRPL) has fundamentally shifted in how amendments move from concept to mainnet. Historically, amendment development was largely focused on functional correctness, performance testing, traditional security audits, bug bounties and independent validator testing as the last line of defense to catch security vulnerabilities.

As XRPL continues to grow in complexity and the value secured by the network increases, we recognized that the previous model was no longer sufficient. Advances in AI are also rapidly reducing the cost of vulnerability discovery, making it increasingly important to identify issues as early as possible in the development lifecycle. With that in mind, we set out to establish a stronger, repeatable, defense-in-depth model that makes it increasingly difficult for critical vulnerabilities, consensus risks, and feature interaction bugs to reach mainnet.

The result is a significantly higher bar for amendment activation that combines specification rigor, adversarial testing, multiple independent audits, attackathons with expert security researchers, AI-assisted security reviews and phased deployments.

The Lending Protocol (XLS-66) and Single Asset Vault (SAV) - XLS-65 are among the first major amendments to undergo this full review process, making them some of the most rigorously tested amendments in XRPL's history.

They also represent some of the most significant new financial capabilities added to the XRP Ledger since 2012, introducing native primitives for lending and borrowing built around Single Asset Vaults. Together, the Lending Protocol and Single Asset Vault bring lending and borrowing capabilities directly into the core XRPL protocol, advancing XRPL's capabilities for Institutional DeFi.

Lending Protocol Security and Quality Gates

This report provides transparency into the development and security process behind one of the most financially complex features XRPL has ever shipped.

As context, the Lending Protocol combines loan lifecycle state management, multi-party fee routing, interest rate arithmetic, credential-gated permissioning, and tight coupling with the Single Asset Vault (SAV). Each of these components introduces unique security and correctness requirements.

Moreover, Single Asset Vault is a foundational primitive that looks simple on the surface (deposit, withdraw, get shares) but is deeply complex in practice because it introduces a share price model that creates new economic attack surfaces everywhere it touches another feature.

The following sections outline the ten phases of review, testing, internal and external validation that these two amendments underwent before reaching the mainnet proposal. In addition, we provide details on what we have done since beginning to leverage AI-assisted reviews and formal methods as a fundamental part of our day-to-day development at the beginning of the year.

Phase 0: Internal Quality & Performance Testing (Early 2025)

Before any external auditor touched the code, RippleX's core engineering team put both the Lending and SAV amendments through extensive internal quality assurance and performance testing. This included unit tests, integration tests, fuzzing, and load testing to validate correctness, stability, and performance under stress.

Next, the Lending Protocol and SAV were submitted to Halborn (end-to-end security firm covering services from smart contract auditing to independent security assessments).

Phase 1: Initial SAV Audit by Halborn (February–April 2025)

Security review began with the Single Asset Vault. Halborn conducted a dedicated smart contract assessment from February 17 to March 13, 2025, covering all core vault transaction types (VaultCreate, VaultDeposit, VaultWithdraw, VaultSet, VaultDelete, and VaultClawback) along with share token management, asset handling, and access controls.

Halborn identified 7 findings across the SAV codebase: 2 Critical, 1 High, 2 Medium, 1 Low, and 1 Informational. The critical findings addressed insufficient amount validation in vault operations and a flaw where the vault failed to account for IOU transfer fees.

100% of all reported findings were addressed before the SAV moved forward.

For a detailed look at how Halborn collaborated with RippleX's engineering team across these audits, see their published case study.

Phase 3: Immunefi Attackathon - $200K Public Bug Bounty (October–November 2025)

Rather than stop at private audits, Ripple partnered with Immunefi to run a public Attackathon - opening both the Lending Protocol and SAV to adversarial testing by the global security research community. This was the first public program of its kind and yielded significant results.

The Attackathon launched on October 27, 2025 with a $200,000 prize pool (paid in RLUSD). A two-week learning period preceded the live window, giving researchers access to educational resources and full scope documentation covering 35,498 lines of C/C++ code.

The results were:

455 total submissions from 131 unique researchers
94 unique valid findings out of 183 valid submissions after triage
Final severity breakdown: 15 Critical · 19 High · 17 Medium · 20 Low · 23 Insights
54 eligible researchers paid out after KYC, with the full $200K distributed

The triage period closed January 7, 2026, and all findings were reviewed by RippleX's core engineering team, which addressed every identified issue and prepared the codebase for re-audit. Immunefi report is published here.

Building on the findings from v1.0, we are planning a v1.1 enhancement amendment to incorporate partner feedback and operational learnings. The release includes both user-facing improvements and targeted protocol enhancements and is scheduled for Q3 this year.

Phase 4: Halborn Re-Audit Post-Attackathon (December 2025–January 2026)

With all critical/high and medium Attackathon findings fixed, we submitted the updated Lending Protocol codebase to Halborn for a second audit starting December 15, 2025. This was a full month engagement covering the entire protocol after incorporating fixes from both the original audits and the Attackathon.

Halborn delivered the re-audit in January 2026. RippleX's engineering team finalized all remaining fixes before the mainnet release.

Phase 5: Mainnet Release & Validator Voting (January 2026)

On January 28–29, 2026, the Lending Protocol and Single Asset Vault shipped in rippled v3.1.0 and went live for initial validator voting and independent community testing by validators and core developers.

Phase 6: Independent Community Testing (March 2026)

The XRPL Commons independently tested the Single Asset Vault, running 257 test cases across 10 categories covering every transaction type, edge case, and adversarial scenario they could identify. 257 out of 257 tests passed, representing a 100% pass rate. Squid UNL validator performed extensive testing in April 2026 (here).

Phase 7: Red Team Activities and Bug Bounty (March - May 2026)

Between March and May 2026, the Lending Protocol and SAV went through the most rigorous pre-launch security process of any XRPL feature to date, across three parallel tracks on top of community testing:

AI Red Team: The AI-assisted red team filed 20 Lending Protocol-specific tickets. Seven confirmed bugs were fixed including an inverted invariant that would have allowed phantom collateral to go undetected, a fee-free network spam vector in LoanPay, and a node deadlock via integer overflow.
Bug Bounty: Multiple researchers submitted reports during the review period. One report identified a confirmed first-depositor vault attack that could result in fund loss and has since been remediated. Other submissions related to known issues for which mitigations were already planned or underway.
Fuzz Testing: We also completed extensive fuzz testing for the Lending Protocol and SAV, including multi-hour runs through the fuzz testing framework. This helped identify and address a vault deposit issue, adding another layer of validation and strengthening the overall security posture for Lending.

The fixes from these efforts were split between the recent 3.1.3 release and the new 3.2.0 release on June 15th.

Phase 8: Formal Verification in Collaboration with Common Prefix

We began with an exploratory phase focused on formally specifying critical components of the Lending Protocol in Lean 4. Over eight weeks (Feb - April 2026), Common Prefix modeled key protocol components and defined the properties they must satisfy.

These formal modeling efforts exposed subtle edge cases that might otherwise have gone undetected, including vault invariant violations, loan payment assertion failures, arithmetic rounding errors, and discrepancies between the XLS specification and the implementation. The identified issues have since been addressed in the latest 3.1.3 and 3.2.0 releases.

Phase 9: Partner Adoption and additional testing

Institutional-grade players like Evernorth, SOIL and VS1.Finance have already lined up to leverage and build on the Single Asset Vault and Lending Protocol - a signal that the security rigor behind these features is translating directly into business confidence. This list is not exhaustive: more partners are in flight and will be covered in dedicated posts as they become public.

Looking Ahead

The most important takeaway is that preparing the Lending Protocol and Single Asset Vault for production through the phases described above has helped establish a new security and quality baseline for XRPL amendments.

This baseline is backed by multiple independent layers of validation, including multiple independent audits, attackathons / bug bounties, AI-assisted security reviews, red team activities, formal modeling, UNL validator review, and community testing. Collectively, these efforts uncovered issues that other approaches would have missed.

Together, this defense-in-depth approach has significantly raised the bar for production readiness and will help shape how future XRPL amendments are developed, reviewed, and deployed.

A Formal Verification of the XRP Ledger: Part II

Vito Tumas — Mon, 08 Jun 2026 14:06:57 +0000

This is a second article in the XRP Ledger Formal Verification Series. If you’d like to start at the beginning you can find the first article: here.

1. Introduction: Building the Standard of Security

We are shifting formal verification work with Common Prefix from the established Payment Engine to the novel protocols, Single Asset Vault and the Lending Protocol. While the Payment Engine has run reliably for more than a decade, these protocols are new. They introduce complex logic that brings real economic exposure, presenting a novel risk profile.

After completing our exploratory phase earlier this year to define our technical scope and strategies, we are ready to proceed. For more technical details, please see Common Prefix’s companion post: Formal Verification of XRPL: Foundations and first Proofs.

This pivot represents a change in how we approach protocol-native feature development. Rather than a safety net, we will embed formal verification practices from day one, specifying and verifying complex new features. We are making provable protocol correctness a design property.

2. The Pivot: Securing High-Stakes Native DeFi

Unlike other blockchain networks, where DeFi logic is fragmented across smart contracts, the XRP Ledger embeds its DeFi primitives directly into its core C++ architecture.

This is a core architectural distinction with security implications: a vulnerability in an external smart contract can be contained or replaced. A vulnerability in core Layer-1 C++ code can propagate across the entire ledger. The elevated risk profile demands features whose correctness is guaranteed.

The complexity of the Single Asset Vault and the Lending Protocol does not arise from the volume of logic, but from the need to preserve numerical precision across multiple sequential operations, where rounding errors cannot be allowed to compound.

Formal verification is the natural tool for this class of problem, mathematically proving the correctness of these mechanisms and setting the standard for every native DeFi primitive that follows.

3. The Problem: Anatomy of Software Correctness

What defines software as “correct”? To answer this, consider software as a target with three distinct zones:

Red Zone: The outer area represents the near-infinite range of actions the code could perform, most catastrophic. For example, minting XRP or enabling unauthorised withdrawals.
Blue Zone: This smaller inner set includes all theoretically correct behaviours, as defined by the protocol’s mathematical design.
Green Zone: These are the actual, implementable behaviours. Since protocols are embedded in a C++ system with strict constraints and a unique architecture, the software must remain inside this zone.

Software is correct when the Green Zone sits entirely within the Blue, with every behaviour the implementation can produce being permitted by the mathematical design, with no path into the Red.

The Limits of Testing

Software remains in the Green Zone through testing, unit, integration, and system tests designed to anticipate user and adversarial interactions. The ceiling of this approach is human imagination and expertise: engineers can only write tests for scenarios they can conceive. For a DeFi protocol with near-infinite state space, that ceiling is low. Testing confirms the system behaves correctly in the scenarios it was asked about; it cannot speak to the ones it wasn't.

4. The Solution: Formal Verification in Practice

Formal verification constructs an abstract model of the Green Zone to represent the protocol's intended behaviour. This model is written in a precise language that computers can analyse. While standard testing asks, "Does this input produce the correct output?", formal verification asks, "Can this model behave incorrectly?" and provides a proof rather than a test result.

Developing the abstract model requires domain expertise and significant initial effort from specialised engineers. Once established, the model changes only with core protocol updates and serves as the authoritative reference for system behaviour. Formal verification ensures the model behaves correctly under all expressible conditions. Extending this guarantee to the C++ implementation is a separate challenge.

From Model to Implementation

An oracle is an artefact derived from the formally proven model, for example, the model directly compiled to C++. It serves as the source of truth against which the implementation is continuously checked: identical inputs are provided to both the Oracle and the xrpld implementation, and any deviation in output is immediately flagged.

In collaboration with Common Prefix, we are applying this methodology to the Single Asset Vault and the Lending Protocol. The modelling phase has already surfaced edge cases that standard tests missed, not as a sign of weakness, but as evidence that formal verification is working exactly as intended. These are early results, but they reflect a methodology with decades of proof behind it, now within reach of mainstream engineering.

5. From Aerospace to Everyday Engineering

Formal verification has its roots in domains where failure could be catastrophic, such as aviation, nuclear power, and other critical infrastructure. Such an approach descends from that tradition, but what once demanded the resources of a space programme is now within reach of mainstream software engineering. For blockchain protocols managing real economic value, the threshold for adopting it is no longer cost, it's ambition.

The broader industry is beginning to recognise what was once a niche conviction: together, AI and formal verification are effective for securing the next generation of blockchain protocols. AI has begun accelerating code analysis and identification of novel attack patterns; formal verification mathematically proves conformance to specification, eliminating entire classes of design flaws at the architectural level. While no security approach is exhaustive, these two disciplines are complementary. One navigates a shifting threat landscape, the other anchors the protocol in provable correctness.

The Future: Spec-Driven Development and Network Governance

The XRPL engineering roadmap is moving in this direction: we are integrating formal verification into our workflows and building toward a development process where protocols are specified and verified before being built and shipped.

The value of this work reaches beyond engineering. Formal verification will become a key factor for network governance: we expect proofs to create a clear, objective baseline for amendment maturity, giving validators the technical assurance needed to evaluate and activate new features with confidence.

By embedding this standard into our engineering lifecycle from the outset, we ensure that as the XRP Ledger expands its native DeFi capabilities, it remains a protocol whose security properties are proven and not just claimed.

Inside the XRPL AI Red Team: What We've Found and Fixed

Mayukha Vadari — Fri, 29 May 2026 17:30:07 +0000

Back in March, we announced that Ripple was standing up a dedicated AI-assisted red team to continuously hunt for vulnerabilities in the XRP Ledger. Two months in, we want to give the community a real look under the hood: how the effort is structured, what kinds of bugs we've found, and what we've learned along the way.

The Challenge: Security at Scale

The XRPL has been running continuously since 2012 and has processed over three billion transactions. That track record is something to be proud of, but it also means the codebase carries the weight of a decade of engineering evolution - design decisions made at a different scale, assumptions that predate modern tooling, and legacy patterns that interact in non-obvious ways with newer features.

New features ship regularly, each adding complexity across the core protocol, client SDKs, and the Clio API server. A codebase that has evolved over a decade accumulates subtle interactions between subsystems that no single person can hold entirely in their head.

AI models allow us to go both deeper and broader in larger codebases, at a speed and scale that would otherwise be near-impossible. Teams can thoroughly explore large codebases at a depth and breadth that would be impractical with manual review alone, finding edge cases where subsystems intersect and in sections of the codebase that haven’t been closely scrutinized in years.

Our Multi-Layered Pipeline

The red team combines several complementary techniques, each catching different classes of bugs.

AI bug-finding agents. The core of our approach is custom AI pipelines that analyze the rippled codebase, XRPL client SDKs (xrpl.js, xrpl-py, xrpl4j, xrpl-rust, xrpl-go), and Clio. We run these agents against feature branches, release candidates, and the main codebase on a continuous basis, including scheduled weekly runs against the develop branch to catch bugs introduced by new code.

DepthFirst. We use DepthFirst, an AI-powered vulnerability discovery platform, for deep scans of our repositories. While our custom pipelines are purpose-built around XRPL-specific semantics, DepthFirst brings broader coverage: it traces data flows, business logic, and cross-service interactions across the codebase to find attack paths that span module boundaries. We specifically use their low-level C/C++ model, which is tuned for the memory safety and type-confusion bugs that dominate systems-level code.

Antithesis (fault-injection testing). We use Antithesis, a continuous fault-injection platform, to run rippled under adversarial conditions - exploring behaviors that only emerge under concurrent load, partial failures, or unusual transaction ordering. This catches a different class of bug than static analysis: timing-dependent crashes and assertion failures that only appear when the system is under stress. Antithesis has already caught real bugs that we have shipped fixes for in production releases.

External security research intake. We actively receive and triage reports from external researchers, whether through our bug bounty program or via other channels. These flow through the same triage pipeline as our internal findings.

PR review bots. We run GitHub Copilot and a Ripple-managed Claude-based bot on rippled PRs. Both post inline comments directly on the PRs, catching issues before they can become bugs in the codebase.

From Bug to Fix: The Full Lifecycle

Discovery is only the first step. As Mozilla observed in their similar work hardening Firefox with AI:

"A discovery subsystem is necessary but not sufficient. In order to scale the effort, we needed to integrate it with our full security bug lifecycle: determining what to look for, where to look, and how to handle what it produces."

We've built the same thing for the XRPL. Our lifecycle looks like this:

Discovery: AI pipelines, DepthFirst scans, Antithesis, and external researchers report candidate bugs.
Deduplication: Before filing, we cross-check against existing boards to avoid duplicate tickets across our various pipelines.
AI-assisted triage: An automated triage pass does the first cut: root cause analysis, false positive detection, reproduction test generation, and severity scoring using the OWASP Risk Rating Methodology. This substantially reduces the manual burden on engineers.
Human expert review: Domain experts validate triage results. AI triage is powerful but imperfect, and human review is essential, particularly for subtle invariant bugs where the AI can misread the intended semantics.
Escalation and routing: Confirmed bugs are routed to the right engineering team with full triage reports and reproduction tests already attached.
Fix and release: Fixes are shipped via the amendment system for on-ledger changes, or as direct patches for off-ledger issues.

Coverage spans nearly every major subsystem: the transaction engine, the RPC layer, the peer/overlay protocol, AMM, MPT, Vault, Lending, Permission Delegation, NFTs, and more.

What We've Found So Far

To date, the team has publicly disclosed 287 xrpld issues on GitHub (231 open, 49 closed), with more issues regularly created as triage continues. These issues are mainly code-quality improvements and defense-in-depth enhancements, and none affect system stability, availability, or the safety of funds. The full list is on Github.

What Shipped in 3.1.3

The 3.1.3 release was dedicated entirely to security and bug fixes. No new features, just hardening. It included 20 red-team findings across several categories:

Permissioned Domain + Tickets crash (Critical). A specific combination of a Ticket-based transaction with the PermissionedDomain feature could trigger a keylet collision that would crash the validator. This bug was initially caught by the XRPL Commons team back in March, and an initial fix that fixed the crash but not the root cause (since that required an amendment) was released in 3.1.2. However, during our release testing for 3.1.3 with Antithesis, we caught a second crashing issue with the same root cause. This is exactly the class of issue the red team was built to find, and exactly why we run fault injection against staging before release. The initial PR from 3.1.2 is #6540, and the full fix in 3.1.3 is #7129.

Ledger RPC API v2 crash (High). The Ledger RPC API v2 endpoint had a crash path reachable from any public connection (no authentication required). A malformed request would bring down the node. This is the kind of bug that's easy to miss in code review because the crash condition is a few layers removed from the input handling, yet straightforward to find with systematic adversarial input generation. The fix PR is #7109.

The remaining findings are summarized in the table below:

Bug	Category	Severity	PR
HTTP Forwarded Header Out-of-Bounds Heap Read	Core / RPC	High	#7126
SHAMap Leaf Node Size Validation Denial of Service	Core	High	#7130
STArray JSON Parsing Lacks Bounds Checking	Core	High	#7112
STIssue Deserialization Crash via noAccount() Issuer	Core	High	#7110
strUnHex Signed Char Out-of-Bounds Array Access	Core	High	#7104
removeEmptyHolding / authorizeMPToken Delete MPToken With Active Escrow (sfLockedAmount > 0)	MPT / Escrow	High	#6635
Stale Read in rippleSendMultiMPT Allows Exceeding MaximumAmount	MPT / Payments	High	#6644
VaultWithdraw Trustline Limit Bypass via Share-Denominated Withdrawal	Vault	Medium	#6645
Zero-Amount ("Clawback All") Fails When Vault Has Outstanding Loans	Vault	Medium	#6646
associateAsset calls skipped for all flag-bearing LoanManage operations	Lending	Medium	#6678
ValidLoanBroker CoverAvailable invariant check is inverted	Lending	Medium	#6678
LoanPay::calculateBaseFee uncapped fee estimation overcharges users	Lending	Medium	#6970
Dry-run transactions can be queued in the real TxQ during fee escalation	Transaction Queue	Medium	#7131
`removeExpired` Silently Ignores `deleteSLE` Failure	Core	Low	#6962
ValidLoan invariant emits identical error message for opposite conditions	Lending	Low	#6668
ValidPermissionedDEX invariant does not check for empty AdditionalBooks array on hybrid offers	Permissioned DEX	Low	#6716

There were also several assorted smaller fixes included, some of which were found by AI.

Note: this is not an exhaustive list of all bugs fixed in 3.1.3 - only those found by AI red team efforts.

Beyond rippled

The team has also been scanning Clio and several widely-used client libraries (xrpl.js, xrpl-py, xrpl4j, xrpl-go, xrpl-rust). The SDK scan found many issues across multiple language implementations, several of which have already been patched.

We have also publicly disclosed 44 issues in xrpl-py, 48 issues in xrpl.js, and 126 issues in xrpl-rust.

What We've Learned

AI is a force multiplier, but cannot fully replace humans. Our pipelines find real bugs (including Critical and High severity issues), but also produce false positives. Human review of AI verdicts, especially for false positives, is a crucial part of the process. The combination of AI discovery + AI triage + human expert validation is what makes the system work.

A full pipeline beats a great tool. Having a strong bug-finding AI model is necessary but not sufficient. The real value is in how you use it (the prompts and harnesses you use to guide the model to find bugs) and the surrounding infrastructure (issue tracking integration, deduplication, severity standardization, routing to the right teams, and tracking through to the fix).

Cross-feature interactions are the hardest bugs to find. The most significant findings were in the intersections between features that individually worked correctly, rather than in any one single feature. This is where AI-assisted analysis has the clearest advantage: it can explore the full range of possible feature interactions much more exhaustively.

Security transparency requires responsible coordination. Fixing critical bugs while protecting the network and users requires close coordination with validators and ecosystem participants before public disclosure.

What's Next

The 3.1.3 release was the first dedicated security release to come out of this effort. Future planned releases, including 3.2.0, will include more fixes from the backlog of confirmed findings.

We're expanding our analysis to cover cross-feature interactions better, and continuing to run Antithesis fault-injection tests on new release branches. We're also working to run more comprehensive attackathons on new amendments before they're activated on mainnet - the security bar for new amendments is going up.

We also plan on open-sourcing our pipelines as soon as we have fixed all the exploitable bugs.

Responsible Disclosure

If you find a potential vulnerability in the XRP Ledger, please report it through our responsible disclosure process. The red team reviews all incoming reports.

Security at this scale requires the whole ecosystem. We'll continue to keep you posted on what we find.

MPT DEX Performance Test Report

Qi Zhao — Thu, 21 May 2026 02:07:19 +0000

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:

Issuer accounts created MPT issuances via MPTokenIssuanceCreate, with lsfMPTCanTrade and lsfMPTCanTransfer flags 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.

Permissioned DEX: Building the Next Layer of Liquidity on XRPL

Antonio Kaplan — Wed, 11 Feb 2026 15:48:49 +0000

The XRP Ledger has always stood apart for its simplicity and resilience. Since 2012, its built-in decentralized exchange (DEX) has processed trades continuously proving that low-cost, on-ledger markets can operate at scale. Over time, features like AMMs and Multi-Purpose Tokens (MPTs) have expanded its toolkit, opening new possibilities without sacrificing efficiency or decentralization.

Now the next major evolution is here: the Permissioned DEX.

Why Permissioned DEX Matters

This feature introduces a permissioned DEX system for the XRPL. By integrating permissioning features directly into the DEX protocol, regulated financial institutions can participate in the XRPL's DEX while still adhering to their compliance requirements. This approach avoids the drawbacks of isolated, permissioned tokens or private blockchains, ensuring a vibrant, liquid marketplace that facilitates seamless arbitrage. Ultimately, this permissioned DEX system paves the way for wider institutional adoption of XRPL, fostering a more accessible and efficient financial landscape.

The open DEX isn’t going anywhere. It will continue to function exactly as it does today, enabling anyone to place and fill offers. Permissioned DEX builds alongside it giving developers and institutions an option to create permissioned order books tied to verified credentials.

This is key to unlocking real-world financial flows. Most regulated institutions can’t engage on open systems without counterparties being verified. By enabling credential-gated liquidity on the same ledger as open markets, XRPL becomes far more suitable for institutional-grade payments, FX, and settlement use cases.

Permissioned DEX as a Hybrid Innovation

The true novelty of XLS-81 lies in its implementation as the industry’s first permissioned and permissionless hybrid system. Previous institutional DeFi attempts struggled to gain traction because pools of capital were disconnected from the broader market. These walled gardens often suffered from thin liquidity and inefficient pricing, ultimately failing to provide the depth that institutional players require.

The Permissioned DEX avoids this pitfall by building regulated order books directly into the existing, battle-tested DEX protocol. This creates a symbiotic liquidity engine: because both open and permissioned markets live on the same ledger, market participants can perform seamless arbitrage between them.

The hybrid model is key to unlocking institutional-grade cross-border payments:

Shared Institutional Liquidity: Regulated entities can tap into deep, shared pools of liquidity to move value without fragmenting capital.
Instant Local Payout: Institutions achieve near-instant settlement by connecting payment corridors through a unified ledger.
Full Policy Control: Issuers maintain the ability to enforce jurisdiction-specific compliance and KYC requirements at the protocol level.

When an institutional order book moves out of sync with the global market, the open DEX provides the necessary liquidity to correct it instantly. This relationship ensures that regulated financial flows aren't just compliant. They are efficient, liquid, and deeply integrated into the entire XRPL ecosystem.

How It Works at the Protocol Level

Delivering an onchain FX and settlement network with shared institutional liquidity, instant local payout, and full policy control on XRPL depends on a small set of core building blocks working together. To understand how this vision comes together, it helps to look at how the individual pieces fit together using the familiar experience of international travel.

Credentials (XLS-70): The Digital Passport: This acts like your travel documents. These are verifiable proofs of identity or compliance issued by trusted authorities. Just as a passport proves who you are to a foreign official, these credentials allow participants to prove their status on-ledger without revealing sensitive private data.
Permissioned Domains (XLS-80): The Visa Process: Each country sets its own requirements for who may enter its borders. Similarly, Permissioned Domains define the specific entry requirements for a regulated environment on XRPL. This is where an issuer or institution decides which specific credentials (visas) are required for a participant to access their liquidity.
Permissioned DEX (XLS-81): The Transportation Network: International travel does not end at the border. Once admitted, travelers use connecting routes and local transportation to reach their final destination. The Permissioned DEX provides these high-speed "routes" via native order books that only accept trades from verified participants. These routes are built into the XRPL itself, ensuring that trades are instant, secure, and fully compliant.

Together, these tools create a flexible system: open markets remain fully open, while permissioned markets can operate with credential-based gating. Liquidity isn’t siloed across external venues. It remains on ledger in a trusted, policy-controlled environment designed for financial institutions.

Real-World Applications

For developers and market makers, Permissioned DEX is not about replacing what exists today, it’s about unlocking new flows that currently bypass XRPL altogether.

Foreign Exchange: Onchain FX and settlement network that uses shared institutional liquidity to power cross-border payments with instant local payout and full policy control on XRPL.
B2B and Treasury Payments: Corporates converting between stablecoins and fiat-backed assets across regions with compliance features built in.
Stablecoin Issuers: Opportunities to increase liquidity and the adoption of their relevant stablecoin.

In short: Permissioned DEX brings fresh liquidity into XRPL, benefiting the open DEX as well as new permissioned venues.

Why It Strengthens the XRPL Ecosystem

Permissioned DEX enables regulated payment and treasury flows to take place directly on the Ledger, rather than being limited to bilateral or externally constrained venues. Compliance-focused order books at the protocol level allow the XRPL to support regulated participation across both fiat-backed and blockchain-native assets.
Instead of pre-funding accounts in every corridor, institutions access shared institutional liquidity on the XRPL where FX and settlement occur atomically. Local payouts are executed via domestic rails only after value has been exchanged on-ledger which reduces settlement and counterparty risk.

Value is created and captured by:

Transparent Pricing: Institutions benefit from the competitive, transparent FX pricing generated by shared liquidity pools.
Capital Efficiency: Lower capital requirements by reducing the need for pre-funding (nostro/vostra accounts).
Risk Mitigation: Atomic settlement removes the timing and counterparty risks inherent in traditional multi-day settlement cycles.
Native Compliance: Policy enforcement and transparency are handled by protocol logic, ensuring every trade meets regulatory standards.

As more regulated flows are executed on-ledger, they contribute to deeper liquidity, broader participation, and increased network usage. This shared liquidity model supports both open DeFi and regulated financial activity on the same ledger, without fragmenting markets across separate systems.
Over time, this dynamic reinforces a positive feedback loop: greater transaction volume attracts more liquidity providers and developers, which in turn improves market depth and utility. This further strengthens the XRPL’s relevance as a global settlement layer, and is a key step towards bringing the financial system onchain.

How Ripple Plans to Utilize The Permissioned DEX

The permissioned DEX provides a compliance-focused on-ledger marketplace for FX and liquidity, enabling institutions to route payments efficiently across currencies. By combining shared liquidity with policy enforcement it delivers lower costs, instant local payout and reduced settlement risk.
Ripple plans to utilize Permissioned DEX as an on-ledger mechanism for asset conversion within payment and treasury workflows, including cross-border payments, B2B transfers, and stablecoin-based settlement.
At a high level, Ripple routes the conversion step of these flows through a permissioned order book, where only verified liquidity providers can participate. Depending on available liquidity and pricing, conversions may execute directly between assets or route across intermediate pairs, settling atomically on XRPL.
For example, in a USD–Colombia corridor, a payment funded in RLUSD can convert on-ledger into a COP-denominated asset via permissioned liquidity, after which the payout partner redeems locally through existing rails. If the pricing were more favorable via an alternative trade route, that path would be executed instead.