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