DEV Community: RippleX Developers

LendingProtocolV1_1: Closed-Ended Vaults and Cash-Basis Accounting

Shota Natenadze — Wed, 30 Sep 2026 15:39:48 +0000

The Single Asset Vault has two modes: open-ended and closed-ended. Both use the same Vault ledger object and the same transaction types (VaultCreate, VaultDeposit, VaultWithdraw, VaultSet). The difference is when capital can move in and out.

Open-ended vaults accept deposits and process withdrawals at any time. When a depositor sends assets, they receive shares (MPTs) at the current price per share (PPS = AssetsTotal / SharesTotal). When they withdraw, shares are burned and assets returned at whatever PPS is at that moment. Capital flows are continuous. Open-ended vaults are fully usable for non-lending purposes (e.g., pooled custody, shared treasury), but loan brokers cannot be attached to them.

Closed-ended vaults (up for validator voting under the LendingProtocolV1_1 amendment) have a fixed lifecycle with three phases:

1. Subscription. The vault is open for deposits. Shares are minted. The vault owner sets the subscription window via SubscriptionDate.

2. Investment. The vault closes to new deposits (the protocol enforces this automatically). The vault owner deploys capital into loans. Interest is returned to the vault via VaultDeposit with the tfVaultDonation flag, which increases AssetsTotal without minting new shares, raising PPS for all existing holders.

3. Redemption. After RedemptionDate, the vault reopens for withdrawals. Depositors redeem shares at the final PPS (principal plus earned yield).

Closed-ended vaults are created by setting VaultKind = 1 on VaultCreatealong with SubscriptionDate and RedemptionDate. This field is immutable after creation.

Under LendingProtocolV1_1, LoanBrokerSet requires the vault to be closed-ended and returns tecNO_PERMISSION on an open-ended vault. Nothing else about open-ended vaults changes: they still exist and still accept deposits and withdrawals at any time. The only thing blocked is setting up a loan broker on them.

What LendingProtocolV1_1 introduces

The LendingProtocolV1_1 amendment extends the LendingProtocol and SingleAssetVault amendments with two changes:

First, it introduces the closed-ended vault as a new vault type that users can create. Users can still create both open-ended and closed-ended vaults, but after this amendment is enabled, new loan brokers can only be created against closed-ended vaults.

Second, it introduces cash-basis accounting. Under the original LendingProtocol amendment, all scheduled interest on a loan was recognized at the time of loan origination: the moment the loan was created, the full expected interest was recorded as income in the vault's accounting. LendingProtocolV1_1 changes this so that interest is only recognized as income when payments are actually made. This is a more conservative and accurate accounting model, and it means the vault's AssetsTotal only reflects interest that has actually been received, not interest that is expected in the future.

Why the Closed and Open-Ended Vaults ship together

Lending is restricted to closed-ended vaults because of how share pricing works. In an open-ended vault, anyone can enter or exit at any time, so a depositor could time their entry and exit around a change in price per share and capture yield they did not earn. Closed-ended vaults avoid this by design: once the subscription window closes, no new shares can be minted, so there is no way to enter mid-term.

Enabling lending on open-ended vaults would require a mechanism that prevents this kind of timing capture under continuous entry and exit. That is open design work, to be scheduled for an upcoming release.

The decision was to ship the closed-ended vault first and require it to activate together with the original Lending Protocol and the Single Asset Vault.

What this means for the amendment vote

Three amendments need to activate for lending to go live on mainnet:
LendingProtocolV1_1 goes together with the LendingProtocol and SingleAssetVault. LendingProtocol is the base lending engine: loan brokers, loan origination, repayment, default handling, and first-loss capital. SingleAssetVault is the base vault primitive that both open-ended and closed-ended vaults build on.

Confidential Transfer - QA Test Report

Ramkumar SG — Tue, 22 Sep 2026 21:19:23 +0000

Test Report Date: 9/22/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 Confidential Transfer (XLS-0096) across xrpld servers. Coverage targets the Confidential MPT feature, which layers ElGamal-encrypted balances and zero-knowledge proofs on top of Multi-Purpose Tokens so that token amounts can be held and transferred confidentially while remaining verifiable on-ledger.

1. Feature

Feature Name: Confidential Transfer (Confidential MPT)

Description: Standard Multi-Purpose Tokens expose every balance and transfer amount in clear on the ledger, which is unacceptable for many payment and settlement use cases. Confidential MPT introduces a confidential balance model in which amounts are stored as ElGamal ciphertexts and every state transition is accompanied by a zero-knowledge proof that the transition is valid without revealing the underlying value. The feature adds five transactors — ConfidentialMPTConvert (move a public MPT balance into the confidential spending balance), ConfidentialMPTSend (transfer a confidential amount into a destination's inbox), ConfidentialMPTMergeInbox (fold received inbox ciphertexts into the spending balance), ConfidentialMPTConvertBack (move a confidential balance back to public), and ConfidentialMPTClawback (issuer clawback of confidential balances). An optional Auditor may be configured on the issuance so a designated party can decrypt amounts for compliance, and the confidential surface composes with the existing issuance-control flags (lock, freeze, require-auth, clawback).

Specification Reference: https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0096-confidential-mpt

2. Test Scope

This report covers the full Confidential Transfer surface as it stands under the Confidential MPT amendment. Testing focused on ensuring that:

All five transactors (Convert, Send, MergeInbox, ConvertBack, Clawback) behave per the XLS-0096 specification, including correct balance conservation and commit/rollback semantics
ElGamal ciphertext handling, zero-knowledge proof verification, per-send re-randomization, and the caller-specified discrete-log decrypt range behave correctly and reject malformed or stale material
Issuance lifecycle and control flags (privacy flag, can-lock/lock, global lock, require-auth, clawback, auditor configuration) are enforced across every transactor
The auditor mirror is maintained and re-randomized correctly so that a configured auditor can always decrypt while confidentiality is preserved against everyone else
Balance and supply invariants hold — encrypted balance deltas match public balance deltas, inbox and spending balances reconcile, and no value is created or destroyed
Security-critical properties hold under adversarial input, including bad proofs, mismatched ciphertexts, stale-proof replay, crafted randomness, and structural/serialization attacks
Confidential MPT composes correctly with Batch, Permission Delegation, Sponsored Fees & Reserves, Deposit Authorization / Preauth, and Permissioned Domains

3. Types of Testing Conducted

Testing Type	Description
Functional	Verifying each transactor, issuance lifecycle step, control flag, and RPC/metadata surface against the XLS-0096 specification
Cryptographic	ElGamal ciphertext validation, zero-knowledge proof verification, per-send re-randomization, auditor-mirror correctness, and the discrete-log decrypt-range API
Regression	Running the full xrpld test suite to confirm Confidential MPT changes did not break existing functionality
Adversarial / Security	Attack-matrix scenarios probing bad proofs, mismatched/stale ciphertexts, crafted randomness, key rotation, and structural/serialization smuggling
Cross-Feature	Interactions between Confidential MPT and Batch (XLS-56), Permission Delegation (XLS-75), Sponsored Fees & Reserves, Deposit Authorization / Preauth, and Permissioned Domains
End-to-End	Full flows spanning convert, confidential send, inbox merge, convert-back, and clawback, with downstream balance and metadata validation

4. Test Results Summary

Testing Type	Total Tests
Confidential Transfer — Core Functional (five transactors, issuance lifecycle, crypto, invariants)	358
Confidential Transfer — Adversarial / Security (adversarial, hardening, bug hunt)	110
Confidential Transfer — Cross-Feature (Batch/Composition, Delegation, Sponsor, Deposit Preauth, Permissioned Domain)	93
Confidential Transfer — Total	561
Regression — xrpld (full suite)	5,088

Testcases: https://dev.to/ripplexdev/confidential-transfer-testcases-1pee

Feature commit history:

- Introduced as the ConfidentialTransfer amendment in PR #5860 (768d7603b1, merged 2026-06-27) 
- Specification standardized as XLS-0096 (XRPL-Standards discussion #372, spec created 2026-01-15) and tracked through spec rc2 (#303)

Related xrpld changes covered in this round:

PR #7279 — Add Batch + Delegation + Confidential tests
PR #7535 — per-send re-randomization of zero-knowledge proof scalars (independent re-randomization scalar per send)
PR #7612 — auditor-mirror re-randomization and the MergeInbox defense against crafted-randomness attacks
PR #6988 — DestinationTag handling on confidential sends
mpt-crypto PR #127 — caller-specified discrete-log decrypt range and the shared-secret zero-exclusion guard

5. Bugs Reported

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

6. Conclusion

Confidential Transfer (XLS-0096) has now been exercised across 561 dedicated tests spanning core functional coverage (the five transactors, issuance lifecycle, cryptographic verification, and ledger invariants), adversarial / security scenarios, and cross-feature interactions with Batch, Permission Delegation, Sponsored Fees & Reserves, Deposit Authorization / Preauth, and Permissioned Domains. In addition, the full xrpld regression suite has been executed to confirm no downstream breakage.

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

Correct balance conservation across every transactor — encrypted balance deltas match the corresponding public balance deltas, and inbox/spending balances reconcile with no value created or destroyed
Rejection of malformed, mismatched, and stale ciphertexts and zero-knowledge proofs, and of crafted-randomness attacks against the auditor mirror and MergeInbox (PR #7612)
Correct per-send re-randomization of proof scalars so that confidentiality holds across repeated and chained sends (PR #7535)
Correct enforcement of issuance control flags (privacy, lock/global-lock, require-auth, clawback) and auditor configuration across all five transactors
Correct interaction with delegated authority, sponsorship, tickets, deposit authorization, permissioned domains, and Batch composition, including atomic rollback of stale-proof inner transactions

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 Confidential Transfer surface.

Confidential Transfer - Testcases

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

Automated test coverage for the Confidential Transfer feature (XLS-0096), grouped by the transactor, invariant, or cross-feature interaction each test exercises with 561 tests.

Category	Test Count
Transactor — Convert	72
Transactor — Send	69
Transactor — MergeInbox	31
Transactor — ConvertBack	30
Transactor — Clawback	30
Issuance Lifecycle	41
Crypto	44
Hardening	36
Adversarial / Security	45
Invariants	41
Batch / Composition	18
Delegation	12
Cross-Feature	63
Bug Hunt	29
Total	561

Transactor — Convert

Test Confidential MPT convert basic
Test Confidential MPT convert without tfMPTCanPrivacy flag
Test Confidential MPT convert partial amount
Test Confidential MPT convert multiple times with available balance
Test Confidential MPT convert multiple times without ignoring holder elgamal public key
Test Confidential MPT convert multiple times with insufficient balance
Test Confidential MPT convert account is individual account locked
Test Confidential MPT convert account is globally locked
Test Confidential MPT convert with auditor enabled and auditor encrypted amount
Test Confidential MPT convert with auditor same as issuer
Test Confidential MPT convert with auditor enabled separately after issuer
Test Confidential MPT convert with different issuer elgamal public key
Test Confidential MPT convert holder and issuer encrypted amounts different
Test Confidential MPT convert with auditor enabled but no auditor encrypted amount
Test Confidential MPT convert with auditor not enabled but with auditor encrypted amount
Test Confidential MPT convert with auditor enabled and using issuer for auditor encrypted amount
Test Confidential MPT convert with auditor enabled and using holder for auditor encrypted amount
Test Confidential MPT convert with no issuer elgamal public key
Test Confidential MPT convert set privacy flag and issuer elgamal public key separately after MPT Issuance create
Test Confidential MPT convert set privacy flag and issuer elgamal public key in same transaction after MPT Issuance create
Test Confidential MPT convert existing account set privacy flag when oa greater than zero
Test Confidential MPT convert new account after set privacy flag when oa greater than zero
Test Confidential MPT convert set privacy flag when oa equals zero
Test Confidential MPT convert set privacy flag by holder when oa greater than zero
Test Confidential MPT convert set privacy flag by holder when oa equals zero
Test Confidential MPT convert with cannot mutate privacy flag
Test Confidential MPT convert with cannot mutate privacy flag and set privacy flag
Test Confidential MPT convert with cannot mutate privacy flag and set privacy flag again
Test Confidential MPT convert holder without elgamal public key
Test Confidential MPT convert non existent account
Test Confidential MPT convert account with no MPT balance
Test Confidential MPT convert account with no MPT object
Test Confidential MPT convert with MPT lock flag set
Test Confidential MPT convert with can lock flag but not locked
Test Confidential MPT convert without tfMPTCanTransfer flag
Test Confidential MPT convert with clawback flag
Test Confidential MPT convert from issuer account
Test Confidential MPT convert from account who is another issuer
Test Confidential MPT convert zero amount account as issuer with balance
Test Confidential MPT convert zero amount account as issuer with no balance
Test Confidential MPT convert account as third party without MPT object
Test Confidential MPT convert MPT amount more than holder balance
Test Confidential MPT convert MPT amount in fraction
Test Confidential MPT convert MPT amount zero
Test Confidential MPT convert MPT amount negative
Test Confidential MPT convert negative MPT amount
Test Confidential MPT convert no holder encrypted amount
Test Confidential MPT convert no issuer encrypted amount
Test Confidential MPT convert no auditor encrypted amount when auditor set
Test Confidential MPT convert with auditor encrypted amount but auditor not set
Test Confidential MPT convert with receiver field
Test Confidential MPT convert with destination field
Test Confidential MPT convert with invalid MPT Issuance id
Test Confidential MPT convert MPT amount missing
Test Confidential MPT convert maximum amount
Test Confidential MPT convert auditor key mismatch
Test Confidential MPT convert invalid ciphertext format
Test Confidential MPT convert invalid zkp
Test Confidential MPT convert multiple accounts
Test Confidential MPT convert change auditor
Test Confidential MPT convert and delete holder
Test Confidential MPT convert with multisign with disabling master key
Test Confidential MPT convert with multisign without disabling master key
Test Confidential MPT convert minimum amount
Test Confidential MPT convert invalid elgamal key format
Test Confidential MPT convert elgamal key wrong length
Test Confidential MPT convert auditor encrypted amount encrypts wrong value
Test Confidential MPT convert issuer key rotation impact when coa is non zero
Test Confidential MPT convert issuer key rotation impact when coa is zero
Test Confidential MPT convert identity point elgamal key
Test Confidential MPT convert blinding factor wrong length
Test Confidential MPT convert zero amount on existing confidential balance

Transactor — Send

Test Confidential MPT send to destination account basic
Test Confidential MPT send partial amount
Test Confidential MPT send multiple times
Test Confidential MPT send source destination swap
Test Confidential MPT send with one drop in inbox
Test Confidential MPT send without source account merging inbox
Test Confidential MPT send without bob having mptoken
Test Confidential MPT send with bob having zero mpt
Test Confidential MPT send with bob having nonzero MPT but no coa
Test Confidential MPT send to destination account having zero confidential balance
Test Confidential MPT send zero amount to bob
Test Confidential MPT send source confidential balance is zero after convert
Test Confidential MPT send to self
Test Confidential MPT send source does not exist
Test Confidential MPT send source does not have mptoken
Test Confidential MPT send source is locked
Test Confidential MPT send destination is nonexistent account
Test Confidential MPT send destination is locked
Test Confidential MPT send with globally locked
Test Confidential MPT send more than available coa
Test Confidential MPT send invalid MPT Issuance id
Test Confidential MPT send issuer sends to holder
Test Confidential MPT send holder sends to issuer
Test Confidential MPT send sender encrypted amount missing
Test Confidential MPT send sender encrypted amount invalid
Test Confidential MPT send destination encrypted amount missing
Test Confidential MPT send destination encrypted amount invalid
Test Confidential MPT send issuer encrypted amount missing
Test Confidential MPT send with auditor basic success
Test Confidential MPT send with auditor missing auditor encrypted amount
Test Confidential MPT send with auditor invalid auditor encrypted amount
Test Confidential MPT send without auditor but with auditor encrypted amount
Test Confidential MPT send without auditor unexpected auditor amount
Test Confidential MPT send with auditor verify decryption
Test Confidential MPT send with auditor multiple sends
Test Confidential MPT send from multiple accounts
Test Confidential MPT send with zkproof missing
Test Confidential MPT send with invalid zkproof value
Test Confidential MPT send with amount commitment missing
Test Confidential MPT send with invalid amount commitment value
Test Confidential MPT send with balance commitment missing
Test Confidential MPT send with invalid balance commitment value
Test Confidential MPT send multiple times in sequence
Test Confidential MPT send version increment
Test Confidential MPT send incorrect version
Test Confidential MPT send stale proof rejection
Test Confidential MPT send mismatched ciphertexts
Test Confidential MPT send and MPT Issuance destroy source account having zero confidential balance
Test Confidential MPT send and delete mptoken on destination account before merging inbox
Test Confidential MPT send second account as sender
Test Confidential MPT send to different accounts with same version
Test Confidential MPT send first merge after convert merge convert
Test Confidential MPT send with multisign without disabling master key
Test Confidential MPT send with multisign with disabling master key
Test Confidential MPT send with multisign insufficient signatures
Test Confidential MPT send with regular key master enabled
Test Confidential MPT send with regular key disabled master
Test Confidential MPT send fractional amount
Test Confidential MPT send negative amount
Test Confidential MPT send and public payment to same destination
Test Confidential MPT send and public payment to different destinations
Test Confidential MPT send without merge
Test Confidential MPT send with require auth and destination unauthorized
Test Confidential MPT send to destination with deposit auth
Test Confidential MPT send to destination with deposit auth and preauth
Test Confidential MPT send to destination requiring credential without providing
Test Confidential MPT send with nonexistent credential
Test Confidential MPT send with expired credential
Test Confidential MPT send without tfMPTCanTransfer flag

Transactor — MergeInbox

Test Confidential MPT merge inbox basic
Test Confidential MPT merge inbox after partial convert
Test Confidential MPT merge inbox account does not exist
Test Confidential MPT merge inbox account does not have mptoken
Test Confidential MPT merge inbox with no confidential balance
Test Confidential MPT merge inbox with various token balance
Test Confidential MPT merge inbox account is issuer
Test Confidential MPT merge inbox convert twice then merge
Test Confidential MPT merge inbox account is individual account locked
Test Confidential MPT merge inbox account is globally locked
Test Confidential MPT merge inbox invalid MPT Issuance id
Test Confidential MPT merge inbox missing MPT Issuance id
Test Confidential MPT merge inbox by third party
Test Confidential MPT merge inbox empty
Test Confidential MPT merge inbox conver and merge multiple times
Test Confidential MPT merge inbox enczero determinism
Test Confidential MPT merge inbox enczero validation
Test Confidential MPT merge inbox and destroy mptoken without merge inbox
Test Confidential MPT merge inbox and destroy mptoken after merge inbox
Test Confidential MPT merge inbox with maximum value
Test Confidential MPT merge inbox rapid state changes
Test Confidential MPT merge inbox with mixed public confidential balance
Test Confidential MPT merge inbox at minimum xrp reserve
Test Confidential MPT merge inbox with require auth flag
Test Confidential MPT merge inbox idempotency empty inbox
Test Confidential MPT merge inbox determinism across accounts
Test Confidential MPT merge inbox balance conservation
Test Confidential MPT merge inbox decrypt verification
Test Confidential MPT merge inbox with multisign with disabled master key
Test Confidential MPT merge inbox version increments by one
Test Confidential MPT merge inbox cb in amount field mismatch adversarial

Transactor — ConvertBack

Test Confidential MPT convert back entire confidential balance
Test Confidential MPT convert back partial confidential balance
Test Confidential MPT convert back without merging inbox
Test Confidential MPT convert back with balance in inbox and spending
Test Confidential MPT convert back with balance only in inbox
Test Confidential MPT convert back with no balance in both inbox and spending
Test Confidential MPT convert back account does not exist
Test Confidential MPT convert back account does not have mptoken
Test Confidential MPT convert back account is issuer
Test Confidential MPT convert back invalid mptokenissuanceid
Test Confidential MPT convert back mptamount greater than spending balance
Test Confidential MPT convert back mptamount invalid values
Test Confidential MPT convert back zero amount
Test Confidential MPT convert back mptamount missing
Test Confidential MPT convert back holder encrypted amount missing
Test Confidential MPT convert back holder encrypted amount invalid
Test Confidential MPT convert back issuer encrypted amount missing
Test Confidential MPT convert back issuer encrypted amount invalid
Test Confidential MPT convert back blinding factor missing
Test Confidential MPT convert back blinding factor invalid
Test Confidential MPT convert back zkproof missing
Test Confidential MPT convert back zkproof invalid
Test Confidential MPT convert back balance commitment missing
Test Confidential MPT convert back balance commitment invalid
Test Confidential MPT convert back with auditor encrypted amount no auditor set
Test Confidential MPT convert back no auditor encrypted amount with auditor set
Test Confidential MPT convert back with auditor encrypted amount and auditor set
Test Confidential MPT convert back account locked
Test Confidential MPT convert back and destroy mptoken and delete accounts
Test Confidential MPT convert back encrypted balance delta equals public balance delta

Transactor — Clawback

Test Confidential MPT clawback with tfMPTCanClawback set
Test Confidential MPT clawback after partial convert
Test Confidential MPT clawback public mpt
Test Confidential MPT clawback without tfMPTCanClawback flag
Test Confidential MPT clawback non issuer
Test Confidential MPT clawback holder missing
Test Confidential MPT clawback holder nonexistent
Test Confidential MPT clawback third party holder
Test Confidential MPT clawback MPT amount zero
Test Confidential MPT clawback from holder with zero confidential balance
Test Confidential MPT clawback MPT amount exceeds balance
Test Confidential MPT clawback MPT amount less than balance
Test Confidential MPT clawback zkproof missing
Test Confidential MPT clawback zkproof invalid
Test Confidential MPT clawback MPT Issuance id missing
Test Confidential MPT clawback MPT Issuance id invalid
Test Confidential MPT clawback without privacy flag
Test Confidential MPT clawback without issuer encryption key
Test Confidential MPT clawback multiple holders
Test Confidential MPT clawback holder equals issuer
Test Confidential MPT clawback with inbox and spending
Test Confidential MPT clawback from source after send
Test Confidential MPT clawback from destination after send
Test Confidential MPT clawback public balance with regular clawback while confidential setup exists
Test Confidential MPT clawback dual public and confidential workflow
Test Confidential MPT clawback and delete account
Test Confidential MPT clawback with auditor
Test Confidential MPT clawback holder account individually locked before clawback
Test Confidential MPT clawback tokens globally locked before clawback
Test Confidential MPT clawback invariant coa decreases

Issuance Lifecycle

Test Issuance set set confidential when coa gt zero is tecNO PERMISSION
Test Issuance set clear confidential bit is unrecognized returns temINVALID FLAG
Test Issuance set set confidential when cannot mutate is tecNO PERMISSION
Test Issuance set replace issuer key is tecNO PERMISSION
Test Issuance set replace auditor key surfaces as temMALFORMED
Test Issuance set keys when confidential not enabled is tecNO PERMISSION
Test Issuance set keys with enable in same tx succeeds
Test Issuance set keys with unrecognized clear bit is temINVALID FLAG
Test Issuance set re register issuer key after coa gt zero is tecNO PERMISSION
Test Issuance set set confidential via mutable flag sets lsf flag
Test Issuance set confidential mutate with holder field is temMALFORMED
Test Issuance set keys with holder field is temMALFORMED
Test Issuance set confidential with nonzero transfer fee is tecNO PERMISSION
Test Issuance set enable privacy and nonzero transfer fee same tx temBAD TRANSFER FEE
Test MPT Issuance create privacy flag without issuer key
Test MPT Issuance create issuer key without privacy flag
Test MPT Issuance create auditor key without privacy flag
Test MPT Issuance create invalid issuer elgamal key
Test MPT Issuance create invalid auditor elgamal key
Test MPT Issuance create coa initialized to zero
Test MPT Issuance set remove auditor key with active supply
Test MPT Issuance set non issuer privacy settings
Test MPT Issuance create privacy flag with nonzero transfer fee
Test MPT Issuance set auditor key without issuer key
Test MPT Issuance destroy with nonzero confidential outstanding amount
Test Privacy enabled at creation cannot be disabled by any clear bit
Test Privacy enabled via mutable flag post creation then clear attempt returns temINVALID FLAG
Test Privacy frozen off via tfMPTCannotMutatePrivacy blocks all later enables
Test Re enable privacy on already enabled Issuance is idempotent
Test All six capability flags one way under confidential issuance
Test Enabling privacy post creation via mutableflags enables all confidential transactors
Test Authorize lifecycle failed unauthorize does not decrement coa
Test Authorize lifecycle unauthorize after full round trip succeeds
Test Authorize lifecycle unauthorize when other holder has cb succeeds
Test Authorize lifecycle reauthorize after unauthorize yields fresh mptoken
Test Authorize lifecycle issuer unauthorize blocks subsequent sends
Test Authorize lifecycle authorize destroyed Issuance returns object not found
Test Issuer can create confidential MPT with canclawback without account flag
Test Issuer can confidential clawback without account flag
Test Setting asfAllowTrustLineClawback after MPT Issuance returns tecOWNERS
Test Issuance without tfMPTCanClawback rejects confidential clawback even with account flag

Crypto

Test Crypto wrapper generate keypair returns correctly sized hex
Test Crypto wrapper generate keypair is non deterministic
Test Crypto wrapper generate blinding factor is correctly sized and nondeterministic
Test Crypto wrapper encrypt decrypt round trip
Test Crypto wrapper decrypt with wrong privkey does not silently succeed
Test Crypto wrapper decrypt amount outside range returns rc minus 1
Test Crypto wrapper decrypt at exact range bounds inclusive
Test Crypto wrapper elgamal round trip is homomorphic consistent
Test Crypto wrapper same plaintext distinct blinding yields distinct ciphertexts
Test Crypto wrapper encrypt with explicit blinding factor is deterministic
Test Crypto wrapper pedersen commitment is deterministic in inputs
Test Crypto wrapper pedersen commitment differs on different amount
Test Crypto wrapper encrypt with wrong sized pubkey raises valueerror
Test Crypto wrapper decrypt with wrong sized privkey raises valueerror
Test Crypto wrapper encrypt with wrong sized blinding factor raises valueerror
Test Crypto wrapper pedersen commitment with wrong sized bf raises valueerror
Test Default range decrypts small amount
Test Narrow range decrypts value within range
Test Below range returns failure
Test Above range returns failure
Test Boundary low and high both decrypt
Test Inverted range returns failure
Test Zero excluded when range low gt zero
Test Auditor decrypts real ciphertext with explicit range end to end
Test Auditor decrypts initial convert balance to actual amount
Test Auditor view decreases correctly after sender sends
Test Auditor view increases correctly after receiver merges
Test Auditor aggregate view equals Issuance confidential outstanding
Test Auditor view unchanged across repeated rerandomization sends
Test Auditor view zeros after full convert back
Test Rerand destination inbox differs from tx ciphertext
Test Rerand destination issuer mirror differs from tx ciphertext
Test Rerand destination auditor mirror behavior
Test Rerand sender spending balance is not rerandomized
Test Rerand sender issuer mirror is not rerandomized
Test Rerand multiple sends end to end decryption
Test Rerand two consecutive sends produce different inbox deltas
Test Rerand destination inbox changes under zero value send
Test Rerand version counter increments once per send
Test Rerand destination inbox and issuer mirror stay in lockstep per send
Test Rerand send to self is rejected at preflight and does not mutate state
Test Rerand two different senders to same destination compose correctly
Test Rerand does not break issuer clawback path after send
Test Rerand auditor mirror differs between two identical sends

Hardening

Test Send to destination requiring dest tag fails
Test Send to destination requiring dest tag with tag succeeds
Test Send with dest tag and auditor succeeds
Test Send when destination authorized but never converted fails
Test Send when sender authorized but never converted fails
Test Send receiver confidential version unchanged
Test Convert zero amount from individually frozen account fails
Test Convert zero amount from globally frozen Issuance fails
Test Convert zero amount from unauthorized account fails
Test Holder unauthorize with nonzero confidential balance fails
Test Issuance set rotate existing issuer encryption key fails
Test Issuance set add auditor after holders have confidential balance fails
Test Create with privacy locked off then enable attempt fails
Test Create with invalid mutable flag bit fails
Test Midflight auditor cannot be retrofitted after issuer key already set
Test Midflight set require auth after holders have cb freezes unallowlisted
Test Midflight change domain id strands holder not in new domain
Test Midflight per holder lock blocks holder unauthorize
Test Crash send all zero zkproof
Test Crash send all ones zkproof
Test Crash send random garbage zkproof
Test Crash send bit flipped zkproof
Test Crash send zero amount commitment
Test Crash send zero balance commitment
Test Crash send zero sender encrypted amount
Test Crash send swapped sender dest ciphertexts
Test Crash convert all zero zkproof
Test Crash convert back all zero zkproof
Test Crash clawback all zero zkproof
Test Crash send rapid fire garbage proofs no corruption
Test Acctdel holder with active cb s blocks account delete
Test Acctdel holder with unmerged inbox blocks account delete
Test Acctdel issuer with active confidential outstanding blocks
Test Acctdel orphan mptoken after Issuance destroy full cleanup chain
Test Acctdel issuer after destroy with outstanding orphan holders succeeds
Test Acctdel stuck holder after issuer unauthorize with cb present

Adversarial / Security

Test Adversarial duplicate send txn
Test Adversarial stale send proof after merge
Test Adversarial reuse convert proof after state change
Test Adversarial reuse convert back proof after state change
Test Adversarial two sends exceed balance same ledger
Test Adversarial send and convert back same balance same ledger
Test Adversarial send vs clawback race same ledger
Test Adversarial valid ec point wrong value
Test Adversarial send amount commitment aliased to balance commitment
Test Adversarial swap holder and issuer encrypted amounts
Test Adversarial zero byte zkproof
Test Adversarial proof for different statement
Test Adversarial point on wrong curve
Test Adversarial identity element as ciphertext
Test Adversarial all zero blinding factor
Test Adversarial range proof negative modular
Test Adversarial nonce reuse across sends
Test Adversarial wrong holder key in send
Test Adversarial holder amount encrypted under issuer key
Test Adversarial issuer amount encrypted under holder key
Test Adversarial valid proof wrong account signature
Test Adversarial key hijacking first convert
Test Adversarial auditor amount wrong key
Test Adversarial auditor amount different value
Test Adversarial stale auditor key after rotation
Test Adversarial range proof near uint64 overflow
Test Adversarial cb in amount tampered
Test Adversarial convert back tampered amount exceeds proof
Test Adversarial send from inbox without merge
Test Adversarial convert then immediate convert back same ledger
Test Adversarial clawback from destroyed mptoken
Test Adversarial clawback after holder converts back to zero
Test Adversarial send with extra unknown fields
Test Adversarial send all required fields missing
Test Adversarial holder encrypted amount wrong byte length
Test Adversarial issuer encrypted amount truncated
Test Adversarial zkproof truncated
Test Adversarial zkproof padded with extra bytes
Test Adversarial confidential state persists across operations
Test Adversarial two sends canonical order
Test Adversarial replay with new sequence
Test Adversarial cross type zkp replay
Test Adversarial non issuer clawback valid zkp
Test Adversarial third party merge inbox valid zkp
Test Adversarial enable privacy on existing transfer fee Issuance reverse mutex

Invariants

Test Inv send increments version when spending changes
Test Inv convert creates consistent encrypted fields
Test Inv send preserves encrypted field coexistence
Test Inv convert token conservation holder and issuer side
Test Inv send does not modify public mptamount at either end
Test Inv send does not modify Issuance outstandingamount
Test Inv clawback decreases coa and oa by identical amount
Test Clawback under global lock no invariant
Test Convert back under global lock returns teclocked
Test Inv coa never exceeds oa through chain
Test Inv send with tampered amount commitment rejected leaves coa unchanged
Test Inv full clawback zeros holder cb and removes their coa contribution
Test Inv full convert back chain leaves no orphan confidential state
Test Convert with zero amount asymmetric behavior probe
Test Convert back with zero amount returns temBAD AMOUNT
Test Clawback with zero amount returns temBAD AMOUNT
Test Send to self returns temMALFORMED
Test Convert with amount exceeding public balance returns tecINSUFFICIENT FUNDS
Test Two issuances independent version counters
Test Two issuances independent coa accounting
Test Two issuances independent auditor decryption
Test Account delete blocked when alice has cb on one of two issuances
Test Convert back on Issuance a does not affect balance on b
Test Clawback on Issuance a does not affect balance on b
Test scenario A send with auditor all zero zkproof rejected
Test scenario A send with auditor random garbage zkproof rejected
Test scenario A send with auditor bit flipped zkproof rejected
Test scenario A send with auditor truncated zkproof rejected
Test scenario B convert MPT amount as string above 2 pow 32 succeeds
Test scenario B convert MPT amount as int above 2 pow 32 is rejected
Test scenario B convert two holders summing above 2 pow 32 keeps coa correct
Test scenario B Issuance create with maximum amount at 2 pow 63 minus 1
Test scenario B Issuance create with maximum amount above 2 pow 63 is rejected
Test scenario C convert back from inbox only no spending is rejected
Test scenario C send from inbox only no spending is rejected
Test scenario C merge inbox after inbox only state promotes value to spending
Test scenario D send after issuer unauthorizes sender fails
Test scenario E clawback after issuer unauthorizes holder succeeds
Test scenario F three holder full chain conserves total value
Test scenario F two Issuance concurrent chains remain isolated
Test scenario H zero amount convert registers holder key and enables inbound send

Batch / Composition

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

Delegation

Test Delegate confidential MPT send basic
Test Delegate confidential MPT send missing permission
Test Delegate confidential MPT convert
Test Delegate confidential MPT merge inbox
Test Delegate confidential MPT convert back
Test Delegate confidential MPT clawback by issuer
Test Delegate neg send perm only cannot convert back
Test Delegate neg convert back perm only cannot send
Test Delegate neg clawback with non issuer account rejected at preflight
Test Delegate neg revoked permission blocks subsequent use
Test Delegate neg self delegation rejected
Test Delegate neg send with proof over delegate keys rejected

Cross-Feature

Test Ticket based first convert succeeds when proof binds to ticket seq
Test Ticket based send succeeds when proof binds to ticket seq
Test Ticket based send with wrong seq in proof returns tecBAD PROOF
Test Ticket based convert back succeeds when proof binds to ticket seq
Test Ticket based send with nonzero sequence returns temSEQ AND TICKET
Test Ticket based send with nonexistent ticket is rejected
Test Ticket based send consumes ticket even on tecBAD PROOF
Test Ticket based send with matching credential succeeds
Test Escrow create with MPT locks only public balance
Test Escrow finish credits destination public not CB
Test Confidential send succeeds with active outgoing escrow
Test Escrow create amount exceeding unlocked public returns tecINSUFFICIENT FUNDS
Test Check create then cash on privacy MPT does not touch either side CB
Test Convert amount capped by unlocked public not total owned
Test Vault create with confidential enabled MPT succeeds
Test Vault deposit preserves holder confidential state
Test Vault deposit fails when holder has no public balance
Test Vault withdraw preserves destination confidential state
Test Vault pseudo mptoken has no confidential fields after deposit
Test Vault confidential clawback independent of vault holdings
Test Send at exactly 10x base fee succeeds
Test Send at one drop below 10x base fee returns telINSUF FEE P
Test First convert does not change holder owner count
Test Issuance create then key register bumps issuer owner count by exactly 1
Test Five confidential sends drain alice xrp by exactly 5x send fee
Test Memo on confidential send does not affect proof
Test Multi sig confidential send at exactly required fee succeeds
Test Multi sig confidential send at one drop below required returns telINSUF FEE P
Test Convert does not update sfOutstandingAmount
Test Convert fee multiplier 10x bounds
Test Merge inbox fee multiplier 10x bounds
Test Convert back fee multiplier 10x bounds
Test Clawback fee multiplier 10x bounds
Test Send to deposit auth destination without preauth fails
Test Send to deposit auth destination after direct preauth succeeds
Test Send to deposit auth destination after unauth fails again
Test Send to deposit auth destination with matching credential succeeds
Test Send after credential deleted fails with nonexistent credential
Test Send with third party credential id fails
Test Send with unaccepted credential fails
Test Send with duplicate credential ids fails
Test Send with credential ids when destination has no deposit auth succeeds
Test Credential based send with frozen destination fails with lock
Test Failed credential based send does not credit destination inbox
Test Credential based send credits all encrypted amounts when auditor present
Test Issuance set domain id on Issuance without require auth fails
Test Issuance set nonexistent domain id fails
Test Confidential send in permissioned domain succeeds
Test Pd payment to uncredentialed holder blocks funding
Test Pd send when destination credential revoked blocks send
Test Pd send when sender credential revoked blocks send
Test Pd send after domain id added post convert succeeds for credentialed
Test Pd clear domain id via zero sentinel revokes holder authorization
Test Pd send with unaccepted destination credential blocks send
Test Convert with reserve sponsor returns temINVALID FLAG
Test Merge inbox with reserve sponsor returns temINVALID FLAG
Test Send with reserve sponsor returns temINVALID FLAG
Test Convert back with reserve sponsor returns temINVALID FLAG
Test Clawback with reserve sponsor returns temINVALID FLAG
Test Send with fee plus reserve flags returns temINVALID FLAG
Test Send with zero sponsor flags returns temINVALID FLAG
Test Send with sponsor equal account returns temMALFORMED
Test Prefunded fee sponsorship for confidential send succeeds

Bug Hunt

Test sum IssuerEncryptedBalance equals coa after multi hop
Test IssuerEncryptedBalance zero after full clawback
Test IssuerEncryptedBalance decrypts to expected after partial send
Test stale version send rejected after intervening send
Test convertback tampered MPT amount field rejected
Test send balance commitment all zero bytes rejected
Test send amount commitment all zero bytes rejected
Test holder key immutable second convert with new key rejected
Test convert with holder key equal to issuer key rejected
Test first convert initializes spending to enczero and version zero
Test second convert does not mutate spending or version
Test issuer can re encrypt holder balance under new auditor key off chain
Test enable auditor after convert send should not tefinternal
Test mergeinbox on encrypted zero inbox version semantics
Test stale send proof after clawback rejected
Test zero amount convert registers key and accepts inbound
Test send ciphertext under wrong key reaches bad proof not internal
Test send swap ciphertexts from different amount proof rejected
Test send to authorized but unconverted holder clean reject
Test batch ct sends allornothing rolls back version on final failure
Test freeze and send same ledger ordering is clean
Test iss enc key reset after full clawback blocked pre reset
Test convert with holder key not owned by account silent loss
Test convert at coa boundary rejects cleanly not internal
Test Add auditor after zero amount convert does not crash next convert
Test Add auditor after convert convertback roundtrip blocked by gates
Test Convert back amount within cb s plus cb in but exceeding cb s rejected
Test Recipient merge between two sender sends does not break sender
Test Clawback when holder has only unmerged inbox state reset correctly

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

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

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

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

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

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

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

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

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

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

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

The XRP Ledger AI Starter Kit, v1.1: Open Standards, Not an Island

Ajit Kulkarni — Tue, 15 Sep 2026 19:12:13 +0000

TL;DR

In mid-June, we launched the XRPL AI Starter Kit to help developers build agentic payment applications on the XRP Ledger.
Today we're shipping v1.1, adding support for two emerging cross-chain agent standards: the Open Wallet Standard (OWS) and Tempo and Stripe's Machine Payments Protocol (MPP), a new CLI, xrpl-up, for fast local testing, and a Skill for XRPL DEX trading.
The throughline: XRPL isn't building agentic payments in isolation. It's showing up in the standards the rest of the agent ecosystem is converging on, and giving developers reference implementations for each.

When we introduced the XRPL AI Starter Kit in June, the goal was narrow and deliberate: give developers the fastest path from zero to a confirmed agent payment on the XRP Ledger, starting with X402 support for XRP and RLUSD. The XRPL has seen 5.6M X402 transactions since its inception.

Since then, the agentic payments landscape has continued to evolve, and a few standards have emerged as genuine points of convergence rather than one-off frameworks. Wallet management is consolidating around shared, local-first interfaces instead of every tool reinventing its own keystore. And machine-to-machine settlement is consolidating around HTTP 402-based protocols that let any agent pay any service without an account or a checkout flow.

XRPL AI Starter Kit v1.1 is about showing up in both of those places, not just the one we started with.

What's New in v1.1

1. XRPL support for the Open Wallet Standard (OWS)

OWS is an open specification for local-first, multi-chain wallet storage and agent access to a single encrypted vault and a single interface (CLI, MCP, SDK, or REST) for every chain and every tool an agent might use. Instead of an agent's keys scattered across a dozen tool-specific config files and environment variables, OWS keeps them in a single vault at ~/.ows/, decrypted only long enough to sign, then wiped from memory.

With v1.1, XRPL is supported as a chain in OWS. A single ows wallet create command now derives an XRPL address alongside addresses for every other chain OWS supports, and agents can request XRPL signatures through the same policy-gated ows_sign interface they'd use for any other chain with no XRPL-specific key handling required.

We're also shipping docs that walk through creating an OWS-backed XRPL wallet, wiring it to an agent, and sending a signed payment, all without the agent ever touching a raw private key.

Why this matters: Agent frameworks don't want to write custom key management code for each chain. By supporting OWS, XRPL becomes accessible through the same wallet layer that developers are already adopting across other ecosystems.

2. XRPL support for Tempo's Machine Payments Protocol (MPP)

MPP, co-authored by Tempo and Stripe, is an open standard for HTTP-native agent payments: a service returns a 402 status with a price, the agent authorizes payment, and the resource is delivered. No accounts, no checkout flows.

XRPL is now a supported settlement rail for MPP, live today for two payment modes:

Single (charge) payments in XRP, IOU, and MPT. An agent hits a 402 challenge, the XRPL payment settles in 3–5 seconds with sub-cent fees, and the resource is delivered. Deterministic finality means the transaction either confirms or it doesn't, with no ambiguous pending state for the agent to poll or retry.
Session payments via XRPL Payment Channels for XRP. This is MPP's most powerful primitive: instead of settling every API call individually, an agent opens a payment channel once, streams cumulative signed vouchers off-chain as it consumes a service, and the provider settles the total in a single on-chain transaction at the end. XRPL Payment Channels were built for exactly this pattern, where vouchers can be signed at rates exceeding 100,000 per second, verified locally by the provider with no blockchain call required, and the whole session costs just two on-chain transactions: open and close.

Stablecoin support for session payments is next. XRPL is adding IOU and MPT support to payment channels (tracked as XLS-93d), so RLUSD-denominated single payments and streaming sessions will follow the same lock-stream-settle mechanics as XRP today.

For developers, the new xrpl-mpp-sdk handles the full 402 challenge-response flow, credential signing, and session management for both charge and channel modes, namely, XRP, IOUs, and MPTs are all supported today, with demos covering everything from a basic XRP charge to a Claude agent paying per-prompt over a payment channel.

The npm package can be found here, and the MPP documentation also shows XRPL support. The npm package is in beta, so we welcome your feedback.

3. `xrpl-up`: a local CLI for fast developer iteration

Testing agentic payment flows against the public Testnet or Devnet means facing faucet rate limits, ~4-second consensus times, and a shared state you don't control. xrpl-up fixes that with a local sandbox: a one-command xrpld node with instant ledger closes, pre-funded accounts, and a full CLI surface for payments, trust lines, escrows, channels, AMM pools, MPTs, and more.

It also ships a Claude Code plugin, so a developer can spin up a sandbox, create an AMM pool, or check a balance by describing what they want in plain language rather than having to remember flag syntax.

xrpl-up isn't specific to agentic payments; it's a general local testing tool and the fastest way to iterate on any of the flows above (OWS wallets, MPP charges and channels, X402) without touching a public network.

4. An XRPL DEX trading Skill

This skill enables autonomous permissionless DEX trading on the XRPL.

Why This Matters: XRPL Is Not on an Island

The OWS and MPP additions are XRPL showing up within a standard someone else is driving, rather than asking developers to adopt something XRPL-specific. OWS is a chain-agnostic wallet infrastructure with contributors spanning PayPal, Circle, the Solana Foundation, and others. XRPL is one of the chains it now speaks natively. MPP is a rail-agnostic settlement standard co-authored by Tempo and Stripe, and XRPL is one of the rails. X402, which we launched in June, works the same way.

That pattern matters more than any single integration. The agentic payments ecosystem is still deciding which standards win, and XRPL's bet is to be a first-class citizen in the ones that do by bringing deterministic finality, predictable low fees, and native primitives like Payment Channels that map cleanly onto what these protocols actually need, rather than requiring a smart contract to bolt the behavior on.

Start Building

Wallets: Follow the new OWS tutorial to create an XRPL-backed wallet and wire it into an agent.
Payments: Try the xrpl-mpp-sdk demos. Start with the basic XRP charge, then the payment-channel session demo to see the streaming pattern end-to-end.
Local testing: Install xrpl-up, run xrpl-up start, and point your scripts at ws://localhost:6006 instead of a public faucet.
Still on X402? Nothing here changes it, and X402 support for XRP and RLUSD from the original launch is unaffected.

As with V1, this is a milestone in the journey, and not the finish line. Tell us what you're building, what's working, and what standard we should be looking at next.

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!

DEV Community: RippleX Developers

LendingProtocolV1_1: Closed-Ended Vaults and Cash-Basis Accounting

Confidential Transfer - QA Test Report

Overview

1. Feature

2. Test Scope

3. Types of Testing Conducted

4. Test Results Summary

5. Bugs Reported

6. Conclusion

Confidential Transfer - Testcases

Transactor — Convert

Transactor — Send

Transactor — MergeInbox

Transactor — ConvertBack

Transactor — Clawback

Issuance Lifecycle

Crypto

Hardening

Adversarial / Security

Invariants

Batch / Composition

Delegation

Cross-Feature

Bug Hunt

Sponsored Fees and Reserves — Performance Test Report

Introduction

Executive Summary

Key Performance Metrics at a Glance

Testing Objectives

Testing Methodology

Capacity Planning

Test Environment

Test Data Setup

Test Phases and Progression

Transaction Scenarios Under Test

Detailed Performance Results

Phase 1 — Mixed Load Testing

Phase 2 — Endurance Testing

Phase 3 — Stress Testing (2× Baseline)

Phase 4 — Multisign (2-Signer) Testing

Phase 5 — Full Mixed Load with Complex Pathfinding

Aggregate Results

Per-Transaction Throughput Breakdown (60-Minute Run)

Edge Case Testing

One-to-Many (1:N) Sponsorship

Sponsorship Termination

System Resource Utilization

CPU Utilization

Memory Utilization

Disk I/O

Network I/O

System Utilization Charts (60-Minute Mixed Load)

CPU

Memory

Disk I/O

Network

Conclusion

Summary of Findings

Recommendation

The XRP Ledger AI Starter Kit, v1.1: Open Standards, Not an Island

What's New in v1.1

1. XRPL support for the Open Wallet Standard (OWS)

2. XRPL support for Tempo's Machine Payments Protocol (MPP)

3. xrpl-up: a local CLI for fast developer iteration

4. An XRPL DEX trading Skill

Why This Matters: XRPL Is Not on an Island

Start Building

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

What is Batch?

What happened with the original Batch (v1.0)

What changed in Batch V1.1

Why Batch matters for the XRPL

Governance context

Batch Transaction - QA Test Report

Overview

1. Feature

2. Test Scope

3. Types of Testing Conducted

4. Test Results Summary

3. `xrpl-up`: a local CLI for fast developer iteration