XLS-0096: Confidential Transfers for Multi-Purpose Tokens

XLS-0096

Final

    title:  Confidential Transfers for Multi-Purpose Tokens
    description: This amendment introduces Confidential Transfers for Multi-Purpose Tokens (MPTs) on the XRP Ledger.
    implementation: https://github.com/XRPLF/rippled/pull/5860
    author: Murat Cenk , Aanchal Malhotra , Ayo Akinyele , Peter Chen , Shawn Xie , Yinyi Qian 
    proposal-from: https://github.com/XRPLF/XRPL-Standards/discussions/372
    status: Final
    category: Amendment
    requires: XLS-33
    created: 2026-01-15

Confidential Transfers for Multi-Purpose Tokens¶

1. Abstract¶

This specification introduces Confidential Transfers for Multi-Purpose Tokens (Confidential MPTs) on the XRP Ledger as an extension of XLS-33 (Multi-Purpose Token). Confidential MPTs enable confidential balances and transfers using EC-ElGamal encryption and zero-knowledge proofs (ZKPs), while preserving the core accounting semantics and supply invariants of XLS-33.

The design provides the following properties:

Confidentiality: Individual balances and transfer amounts are encrypted and are not revealed to validators or external observers.
Public auditability: Issuance limits remain publicly enforceable through the existing invariant OutstandingAmount ≤ MaximumAmount, without requiring decryption of confidential balances.
Selective disclosure / view keys: The protocol supports flexible auditability through two models: (i) a trust-minimized, on-chain auditor model based on encrypted balance mirroring and zero-knowledge consistency proofs, which is extensible to additional auditors via re-encryption; and (ii) a simpler, trust-based alternative using issuer-controlled view keys for on-demand disclosure.
Compatibility: Public and confidential balances may coexist for the same token. The issuer account itself cannot hold confidential balances; issuers who wish to participate in confidential circulation must use a separate dedicated holder account, which is treated identically to other non-issuer holders, preserving XLS-33 issuance semantics.
Issuer control: Existing issuer controls are preserved and extended to confidential balances, including issuer-initiated freezing and clawback that burns the clawed-back funds.

Confidential MPTs align directly with XLS-33 by maintaining OutstandingAmount as the sum of all non-issuer balances. Supply consistency is enforced deterministically by validators using plaintext ledger fields, while confidentiality is achieved at the transaction level through AND-composed compact sigma proofs and range proofs.

2. Motivation¶

XLS-33 enables flexible tokenization on the XRP Ledger, but all balances and transfers remain publicly visible. This transparency limits adoption in institutional and privacy-sensitive contexts. Confidential MPTs address this gap by introducing encrypted balances and confidential transfers while preserving XLS-33 semantics.

The design maintains the standard definition of OutstandingAmount (OA) as the sum of all non-issuer balances. A complementary value, ConfidentialOutstandingAmount (COA), tracks the confidential portion of circulation, ensuring that while individual balances are encrypted, the global supply remains auditable. MaximumAmount (MA) continues to cap the total supply, allowing validators to enforce consistency with the existing invariant OA ≤ MA.

2.1 Benefits¶

Confidentiality: Hides individual balances and transfer amounts using EC-ElGamal encryption and ZKPs.
Auditability: Public auditability is preserved via XLS-33’s existing OA semantics.
Flexible Compliance: Enables selective disclosure through multiple mechanisms, including a trust-minimized on-chain model and a simpler issuer-controlled view key model.
Compatibility: Maintains backward compatibility with XLS-33. The issuer account cannot hold confidential balances; any issuer-controlled dedicated holder account is treated as a standard holder.
Enhanced Issuer Control: Provides optional Freeze and a Clawback transaction, giving issuers the tools needed to manage assets and enforce compliance. Clawback burns the holder’s confidential balance.

3. Definitions & Terminology¶

MPT (Multi-Purpose Token): A token standard defined by XLS-33, extended here to support confidential balances and transfers.
MPTokenIssuance (Object): Ledger object storing metadata for an MPT, including MPTokenIssuanceID, MaximumAmount (MA), OutstandingAmount (OA) and etc.
MPToken (Object): Ledger object representing a holder’s balance of a given MPT. Extended to include confidential balance fields.
Dedicated Account (Issuer-as-Holder): An optional account controlled by the issuer but treated by the ledger as a standard non-issuer holder. The issuer account itself cannot hold confidential balances for it's own issuance; an issuer that wishes to participate in confidential circulation must use a dedicated account. This account is sometimes called the "Confidential Vault."
OutstandingAmount (OA): The total of all non-issuer balances (public and confidential), including any issuer-controlled dedicated account.
ConfidentialOutstandingAmount (COA): The total amount of an MPT currently held in confidential balances by non-issuers, including any issuer-controlled dedicated account.
MaximumAmount (MA): The maximum allowed token supply. Invariant: OA ≤ MA.
EC-ElGamal Encryption: A public-key encryption scheme with additive homomorphism, used for encrypted balances and homomorphic balance updates.
Zero-Knowledge Proofs (ZKPs): Cryptographic proofs used to validate confidential transactions without revealing amounts, including:
AND-composed compact sigma proofs (referred to as compact sigma proofs throughout this document): proofs that AND-compose multiple ZK statements under a single Fiat–Shamir challenge into a single fixed-size proof per transaction type, bundling ciphertext consistency, amount linkage, and balance linkage checks.
Range proofs, ensuring confidential amounts and post-transfer balances are non-negative and lie within a valid range.
Split-Balance Model: Confidential balances are divided into:
Spending (CB_S): Stable balance used for spending and proofs.
Inbox (CB_IN): Receives incoming transfers and must be explicitly merged into CB_S, preventing stale-proof rejection.
Auditor Policy: An optional issuance-level configuration that enables selective disclosure by encrypting balances under an auditor’s public key.
Clawback: A privileged issuer-only operation performed via a ConfidentialMPTClawback transaction, which forcibly burns a holder’s entire confidential balance (decreasing both COA and OA) while preserving ledger accounting consistency through ZKPs. The burned funds are permanently removed from circulation.

4. Scope¶

This XLS specifies the protocol changes required to support confidential MPTs, including:

4.1 New Transaction Types¶

ConfidentialMPTConvert: Converts public MPT balances into encrypted form for a holder.
ConfidentialMPTSend: Confidential transfer of tokens between accounts, with encrypted amounts validated by ZKPs.
ConfidentialMPTMergeInbox: Merges a holder’s inbox balance into their spending balance, preventing stale-proof issues.
ConfidentialMPTConvertBack: Converts confidential balances back into public form, restoring visible balances.
ConfidentialMPTClawback: An issuer-only transaction to forcibly burn a holder’s entire confidential balance, permanently removing those tokens from circulation.

5. Protocol Overview¶

The Confidential MPT protocol is built on three core design principles: the Dedicated Account model, the Split-Balance model for reliable transfers, and a Multi-Ciphertext architecture for privacy and compliance.

5.1 The Dedicated Account Model¶

The issuer account itself cannot hold or convert to it's own token to confidential balances. To participate in confidential circulation, the issuer may optionally use an issuer-controlled Dedicated Account (also known as a "Confidential Vault"). While this account remains under the control of the issuer, it is treated by the ledger as a standard Holder with no special privileges.

The operational setup, when the issuer wishes to seed confidential circulation, follows these steps:

The Issuer creates an MPTokenIssuance object.
The Issuer optionally creates a Dedicated Account to act as the "Confidential Vault."
The Issuer sends a public MPT amount to the Dedicated Account.
The Dedicated Account converts the public balance to a confidential balance.
Preserving invariants: Because the dedicated account is a non-issuer, its balance is included in OutstandingAmount (OA). This preserves the existing OA ≤ MaximumAmount invariant and allows validators to enforce the supply cap without decrypting confidential balances. All subsequent confidential transfers between non-issuer holders are redistributions that do not modify OA.

5.2 The Split-Balance Model¶

To prevent stale-proof failures—where an incoming transfer could invalidate a proof generated for an outgoing transfer—each account’s confidential balance is split into two components:

Spending balance (CB_S): A stable balance used for generating proofs in outgoing ConfidentialMPTSend transactions.
Inbox balance (CB_IN): A separate balance that receives all incoming confidential transfers.
Merging: Holders explicitly merge CB_IN into CB_S using the proof-free ConfidentialMPTMergeInbox transaction. Each merge increments a monotonically increasing version number (CB_S_Version), which is bound to newly generated proofs to prevent replay and ensure proofs reference a stable balance.

5.3 The Multi-Ciphertext Architecture¶

A single confidential balance is represented by multiple parallel ciphertexts, each serving a distinct purpose. Compact sigma proofs ensure that all ciphertexts correspond to the same hidden amount.

Holder encryption: The primary balance is encrypted under the holder’s public key, granting exclusive spending authority.
Issuer encryption: The same balance is also encrypted under the issuer’s public key (sfIssuerEncryptedBalance). This encrypted mirror supports supply consistency checks and issuer-level auditing without granting spending capability.
Optional auditor encryption: If an auditor is set, balances are additionally encrypted under an auditor’s public key (AuditorEncryptedBalance), enabling on-chain selective disclosure. The issuer may also re-encrypt balances for newly authorized auditors using its encrypted mirror, supporting forward-looking compliance.

5.4. Proof System¶

The protocol relies on a set of ZKPs to validate confidential transactions without revealing balances or transfer amounts. The following proof types are used:

Schnorr Proof of Knowledge (64 bytes): Used in ConfidentialMPTConvert when registering a new holder key. Proves ownership of the private key associated with the ElGamal public key.
compact sigma proofs: Cryptographic proofs that bundle multiple ZK statements into a single fixed-size blob verified in one pass. Each transaction uses a dedicated sigma proof optimized for its specific set of hidden values.
Compact Send sigma proof (192 bytes): Used in ConfidentialMPTSend. Simultaneously proves:
- Ciphertext consistency: All encrypted copies of the transfer amount (sender, receiver, issuer, optional auditor) encrypt the same value using shared randomness.
- Amount linkage: The AmountCommitment commits to that same transfer amount. Critically, it intentionally reuses the ElGamal ciphertext randomness as its blinding factor rather than introducing an independent scalar, which means the relationship between the commitment and the ciphertexts is captured directly within the compact sigma proof, eliminating the need for a separate amount-linkage proof.
- Balance linkage: The BalanceCommitment encodes the same spending balance as the sender's on-ledger encrypted balance, verified via knowledge of the sender's secret key.
Compact ConvertBack sigma proof (128 bytes): Used in ConfidentialMPTConvertBack. Proves the holder owns the spending balance and that their balance commitment is correctly derived from it.
Compact Clawback sigma proof (64 bytes): Used in ConfidentialMPTClawback. Proves the issuer's on-ledger encrypted balance mirror contains the plaintext amount being claimed.
Plaintext–ciphertext equality (deterministic): In ConfidentialMPTConvert and ConfidentialMPTConvertBack, the disclosed blinding factor allows validators to verify ciphertexts deterministically without a ZKP.
Range proofs (Bulletproofs): Prove that confidential amounts and post-transfer balances lie within a valid range, enforcing non-negativity and preventing overspending.
Aggregated Bulletproof (754 bytes): Used in ConfidentialMPTSend. Proves both the transfer amount and the remaining balance are in [0, 2^64). Note that, while the Bulletproof covers the full 64-bit range, transactors independently reject any amount exceeding the protocol cap maxMPTokenAmount (2^63 − 1), so accepted values lie in [0, 2^63 − 1].
Single Bulletproof (688 bytes): Used in ConfidentialMPTConvertBack. Proves the remaining balance after withdrawal is non-negative.

5.5. Delegate Accounts¶

The issuer may designate one or more delegate accounts to act on its behalf, for example, to submit ConfidentialMPTClawback transactions or to manage the dedicated account (Confidential Vault). Delegate accounts must be considered fully trusted by the issuer. A delegate account has complete operational authority within the scope delegated to it, and the protocol does not impose additional on-chain restrictions on delegate actions beyond those that apply to the issuer itself. Issuers should apply the same key-management standards to delegate accounts as to their primary issuer account.

ConfidentialMPTSend, ConfidentialMPTMergeInbox, ConfidentialMPTConvertBack, and ConfidentialMPTClawback are delegable. ConfidentialMPTConvert is NOT delegable. It is the transaction that registers an account's HolderEncryptionKey, and that key carries exclusive spending authority over the account's confidential balance — delegating it would let the delegate register a key whose secret it alone controls, and thereby take over the account's confidential funds.

6. Ledger Entry: `MPTokenIssuance`¶

To support confidential MPTs, the existing MPTokenIssuance ledger object is extended. These new fields and flags serve as the global configuration and control settings for the token's confidential features.

6.1. Fields¶

FieldName	Required?	JSON Type	Internal Type	Description
`IssuerEncryptionKey`		`string`	`Blob`	A 33-byte compressed ElGamal public key for the issuer. Required to use the confidential transfer feature.
`AuditorEncryptionKey`		`string`	`Blob`	A 33-byte compressed ElGamal public key for an optional on-chain auditor.
`ConfidentialOutstandingAmount`	(default)	`number`	`UINT64`	The total amount of this token that is currently held in confidential balances. This value is adjusted with every `ConfidentialMPTConvert`, `ConfidentialMPTConvertBack`, and `ConfidentialMPTClawback` transaction. Required to use the confidential transfer feature.

6.2. Flags¶

Two new flags are introduced for the MPTokenIssuance ledger object. Note that lsfMPTCanHoldConfidentialBalance is stored in the standard sfFlags field, while lsifMPTCanHoldConfidentialBalance is stored in the sfImmutableFlags field.

Flag Name	Field	Hex Value	Description
`lsfMPTCanHoldConfidentialBalance`	`sfFlags`	`0x00000080`	Indicates that confidential transfers are enabled for this token issuance.
`lsifMPTCanHoldConfidentialBalance`	`sfImmutableFlags`	`0x00000080`	If set, the `lsfMPTCanHoldConfidentialBalance` flag can never be changed after the token is issued.

Note: sfImmutableFlags is introduced in the amendment DynamicMPT. To use this field,the DynamicMPT amendment must be enabled.

6.3. Managing Confidentiality Settings¶

The lsfMPTCanHoldConfidentialBalance flag enables the use of confidential transactions for an MPTokenIssuance. Only when this flag is enabled can the token support confidential transfers.

6.3.1. Mutability & Defaults¶

Note on Terminology:

sfFlags: The prefix lsf refers to ledger state flags, while tf refers to the transaction flags.
sfImmutableFlags: The prefix lsif refers to the immutable ledger state flags.
Default Behavior (Mutable): By default, without setting tifMPTCanHoldConfidentialBalance, the issuer retains the ability to enable the confidential balance setting (lsfMPTCanHoldConfidentialBalance) via MPTokenIssuanceSet transactions. Enabling is one-way; the flag cannot be cleared once set.
Permanent Lock (Immutable): If the issuer sets the immutable flag tifMPTCanHoldConfidentialBalance through MPTokenIssuanceCreate transaction, the lsfMPTCanHoldConfidentialBalance can never be changed after issuance.

6.3.2. Enabling Confidentiality¶

There are two ways to enable the lsfMPTCanHoldConfidentialBalance flag:

At Creation: The issuer can enable the tfMPTCanHoldConfidentialBalance flag directly within the MPTokenIssuanceCreate transaction at the time the token is issued.
Post-Creation (Update): If the issuance was created with confidential mutability allowed (that is, lsifMPTCanHoldConfidentialBalance was not set — which is the default behavior), the issuer may later submit an MPTokenIssuanceSet transaction to activate the lsfMPTCanHoldConfidentialBalance flag.

6.3.3. Disabling Confidentiality¶

Enabling confidentiality is one-way. Once lsfMPTCanHoldConfidentialBalance is set it cannot be cleared — there is no transaction flag to disable confidential balance on an existing issuance. This guarantees that funds already converted to a confidential state can never be stranded by the capability being turned off underneath them.

6.4. Transfer Fee Compatibility¶

Confidential MPTs are incompatible with non-zero TransferFee. An MPTokenIssuance MUST NOT have both a non-zero TransferFee and lsfMPTCanHoldConfidentialBalance enabled.

This restriction exists because XLS-33 transfer fees are percentage-based while ConfidentialMPTSend hides the transferred amount; see §14.4.

The following cases are invalid:

MPTokenIssuanceCreate with both a non-zero TransferFee and tfMPTCanHoldConfidentialBalance. (temBAD_TRANSFER_FEE)
MPTokenIssuanceSet that sets tfMPTSetCanHoldConfidentialBalance while the issuance already has a non-zero TransferFee. (tecNO_PERMISSION)
MPTokenIssuanceSet that sets a non-zero TransferFee while the issuance already has lsfMPTCanHoldConfidentialBalance. (tecNO_PERMISSION)
MPTokenIssuanceSet that sets a non-zero TransferFee and tfMPTSetCanHoldConfidentialBalance in the same transaction. (temBAD_TRANSFER_FEE)

ConfidentialMPTSend will fail with tecNO_PERMISSION if the issuance has a non-zero TransferFee.

6.5. Deletion¶

Deletion Transactions: MPTokenIssuanceDestroy.

Deletion Conditions:

All XLS-33 conditions continue to apply unchanged, in particular OutstandingAmount == 0.
The issuance can only be destroyed while ConfidentialOutstandingAmount is 0, but this requires no confidential-specific condition on MPTokenIssuanceDestroy. Because ConfidentialOutstandingAmount <= OutstandingAmount holds at all times (§6.6), the existing XLS-33 requirement already implies it.
Registered encryption keys (IssuerEncryptionKey, AuditorEncryptionKey) do not block destruction; they are removed with the issuance.

Account Deletion Blocker: Yes. This is unchanged from XLS-33: an MPTokenIssuance must be deleted before its issuer account can be deleted, and this amendment adds no new exemption.

6.6. Invariants¶

In the rules below, ΔCOA and ΔOA denote a transaction's net change to this issuance's ConfidentialOutstandingAmount and OutstandingAmount, and ΔMPTAmount denotes its net change to MPTAmount summed over every MPToken of this issuance rather than that of any single holder.

ConfidentialOutstandingAmount <= OutstandingAmount. Since ConfidentialOutstandingAmount is an unsigned 64-bit field, this also catches any underflow: a subtraction below zero wraps to a value that necessarily exceeds OutstandingAmount.
Whenever ΔCOA != 0, the identity ΔMPTAmount + ΔCOA = ΔOA MUST hold.
Whenever ΔCOA = 0 and the transaction is one of the five confidential MPT transaction types, both ΔMPTAmount = 0 and ΔOA = 0 MUST hold. Besides ConfidentialMPTSend and ConfidentialMPTMergeInbox, this case also covers a zero-amount ConfidentialMPTConvert submitted purely to register a HolderEncryptionKey.

6.7. Example JSON¶

{
  "LedgerEntryType": "MPTokenIssuance",
  "Flags": 128,
  "Issuer": "rf1BiGeXwwQoi8Z2ueOMErvmAzyxw",
  "OutstandingAmount": "1000000",
  "MaximumAmount": "5000000",
  "ConfidentialOutstandingAmount": "500000",
  "IssuerEncryptionKey": "028d...",
  "AuditorEncryptionKey": "037c...",
  "PreviousTxnID": "5DFD494A15AED58DE4335DAEDD3E1EEFECE...",
  "PreviousTxnLgrSeq": 1234567,
  "index": "610F33B8EBF7EC795F822A454FB852156AEFE50BE0CB8326338A81CD74801864"
}

7. Ledger Entry: `MPToken`¶

To support confidential MPTs, the existing MPToken ledger object is extended with the fields that hold a holder's confidential balance. All of these fields are absent until the holder opts in by submitting their first ConfidentialMPTConvert, and the issuer's own account never carries them, since the issuer cannot hold a confidential balance of its own issuance.

7.1. Fields¶

FieldName	Required?	JSON Type	Internal Type	Description
`HolderEncryptionKey`		`string`	`Blob`	A 33-byte compressed ElGamal public key belonging to the holder. Registered by the holder's first `ConfidentialMPTConvert` and immutable thereafter. Possession of the matching secret key is what grants authority to spend the balance.
`ConfidentialBalanceSpending`		`string`	`Blob`	A 66-byte ElGamal ciphertext (`CB_S`) encrypting the holder's spendable confidential balance under `HolderEncryptionKey`. Initialized to the canonical encrypted zero. Only this balance may be spent or converted back.
`ConfidentialBalanceInbox`		`string`	`Blob`	A 66-byte ElGamal ciphertext (`CB_IN`) encrypting incoming confidential value under `HolderEncryptionKey`. Credited by `ConfidentialMPTConvert` and `ConfidentialMPTSend`, and folded into `CB_S` by `ConfidentialMPTMergeInbox` (§10).
`ConfidentialBalanceVersion`	(default)	`number`	`UINT32`	A counter bound into the holder's proofs to prevent stale-proof replay. Incremented whenever `ConfidentialBalanceSpending` changes; wraps to 0 after reaching the maximum 32-bit value.
`IssuerEncryptedBalance`		`string`	`Blob`	A 66-byte ElGamal ciphertext encrypting the holder's total confidential balance (`CB_S` + `CB_IN`) under the issuance's `IssuerEncryptionKey`. The issuer's mirror, used for supply reconciliation and as the basis for clawback (§12).
`AuditorEncryptedBalance`		`string`	`Blob`	A 66-byte ElGamal ciphertext encrypting the same total balance under the issuance's `AuditorEncryptionKey`. Present only when the issuance has an auditor configured.

7.2. Deletion¶

Deletion Transactions: MPTokenAuthorize (with tfMPTUnauthorize), and implicitly by transactions that reclaim an empty holding on the holder's behalf — VaultDelete, VaultWithdraw, VaultClawback, and LoanBrokerDelete.

Deletion Conditions:

All XLS-33 conditions continue to apply unchanged, including a zero public MPTAmount.
Holder-initiated deletion: An MPToken that carries confidential balance fields cannot be deleted while the issuance's ConfidentialOutstandingAmount is non-zero, because the ledger cannot tell from the ciphertexts alone whether that particular holder's balance is zero. The attempt fails with tecHAS_OBLIGATIONS. Once ConfidentialOutstandingAmount reaches 0, every holder's confidential balance is necessarily zero and the MPToken may be deleted normally, even if the confidential fields are still present on it.
Implicit deletion: Deletion performed implicitly by one of the vault or loan-broker transactions above is blocked whenever the MPToken still carries any confidential balance field (ConfidentialBalanceSpending, ConfidentialBalanceInbox, IssuerEncryptedBalance, or AuditorEncryptedBalance), irrespective of ConfidentialOutstandingAmount, and fails with tecHAS_OBLIGATIONS. This is deliberately stricter than the holder-initiated rule, as defense in depth: objects reachable through those paths cannot acquire confidential fields in the first place — vault share issuances are created without lsfMPTCanHoldConfidentialBalance, and a vault or loan-broker pseudo-account cannot submit the ConfidentialMPTConvert that would register the fields — so the two rules never disagree on a state the protocol can actually produce.

Account Deletion Blocker: This is unchanged from XLS-33: an MPToken must be deleted before its owner account can be deleted, and this amendment adds no new exemption.

7.3. Invariants¶

ConfidentialBalanceSpending, ConfidentialBalanceInbox, and IssuerEncryptedBalance are all present or all absent. A single ConfidentialMPTConvert creates all three at once.
AuditorEncryptedBalance may be present only if the three core fields are present.
If a transaction creates or modifies any of ConfidentialBalanceSpending, ConfidentialBalanceInbox, IssuerEncryptedBalance, or AuditorEncryptedBalance, then the corresponding MPTokenIssuance MUST have the lsfMPTCanHoldConfidentialBalance flag enabled. The converse is deliberately not required: these fields may remain on an MPToken after all confidential balances have returned to zero, so merely carrying them is not constrained — only changing them is.
If a transaction changes the value of ConfidentialBalanceSpending on an existing MPToken, then ConfidentialBalanceVersion MUST also change. Initial creation of ConfidentialBalanceSpending by the holder's first ConfidentialMPTConvert is exempt, since there is no prior value to invalidate.
While the issuance's ConfidentialOutstandingAmount is greater than 0, no MPToken may be removed from the ledger if, immediately before removal, it had a non-zero MPTAmount or carried any of ConfidentialBalanceSpending, ConfidentialBalanceInbox, IssuerEncryptedBalance, or AuditorEncryptedBalance. This holds regardless of which transaction attempts the removal (§7.2).

7.4. Example JSON¶

{
  "LedgerEntryType": "MPToken",
  "Account": "rHolderAccountAddress",
  "MPTokenIssuanceID": "610F33B8EBF7EC795F822A454FB852156AEFE50BE0CB8326338A81CD74801864",
  "MPTAmount": "500000",
  "Flags": 0,
  "HolderEncryptionKey": "038d...",
  "ConfidentialBalanceSpending": "02a1...",
  "ConfidentialBalanceInbox": "03b2...",
  "ConfidentialBalanceVersion": 7,
  "IssuerEncryptedBalance": "02c3...",
  "AuditorEncryptedBalance": "03d4...",
  "OwnerNode": "0000000000000000",
  "PreviousTxnID": "5DFD494A15AED58DE4335DAEDD3E1EEFECE...",
  "PreviousTxnLgrSeq": 1234567,
  "index": "36D91DEE5EFE4A93119A8B84C944A528F2B444B3F3EC6D64C1F9D2FE9F1E5EB4"
}

8. Transaction: `ConfidentialMPTConvert`¶

Purpose: Converts a holder’s own visible (public) MPT balance into confidential form. The converted amount is credited to the holder’s confidential inbox balance (CB_IN) to avoid immediate proof staleness, requiring an explicit merge into the spending balance (CB_S) before use. This transaction also serves as the opt-in mechanism for confidential MPT participation: by executing it (including a zero-amount conversion), a holder’s HolderEncryptionKey is recorded on their MPToken object, enabling the holder to receive and manage confidential funds.

This transaction is a self-conversion only. The issuer account itself cannot execute this transaction; only non-issuer holders may convert public balances to confidential form of its own MPT issuance. Issuers introduce supply exclusively through existing XLS-33 public issuance mechanisms. An issuer-controlled dedicated account participates in confidential MPTs by executing ConfidentialMPTConvert as a regular holder, with no special privileges. In all cases, OutstandingAmount (OA) and ConfidentialOutstandingAmount (COA) are maintained in plaintext according to existing invariants.

8.1 Use Cases¶

Holder → self (public → confidential): Public balance decreases and confidential balance increases; OA unchanged, COA increases (both in plaintext).
Issuer dedicated account → self (public → confidential): After being funded publicly via XLS-33 issuance, the dedicated account converts its own balance like any holder; OA unchanged, COA increases.
Hybrid circulation: Tokens may coexist in public and confidential form.

8.2 Fields¶

Field Name	Required?	JSON Type	Internal Type	Default Value	Description
`TransactionType`	Yes	`string`	`UINT16`	N/A	Identifies this as a `ConfidentialMPTConvert`, which is 85.
`Account`	Yes	`string`	`ACCOUNTID`	N/A	The account initiating the conversion.
`MPTokenIssuanceID`	Yes	`string`	`UINT192`	N/A	The unique identifier for the MPT issuance.
`MPTAmount`	Yes	`number`	`UINT64`	N/A	The public plaintext amount \(inline\)m\(inline\) to convert.
`HolderEncryptionKey`	No	`string`	`BLOB`	N/A	The holder's ElGamal public key (\(inline\)pk_A\(inline\)). Required if initializing (no key registered). Forbidden if key already registered.
`HolderEncryptedAmount`	Yes	`string`	`BLOB`	N/A	A 66-byte ElGamal ciphertext credited to the holder's \(inline\)CB_{IN}\(inline\).
`IssuerEncryptedAmount`	Yes	`string`	`BLOB`	N/A	A 66-byte ElGamal ciphertext credited to the issuer's mirror balance.
`AuditorEncryptedAmount`	No	`string`	`BLOB`	N/A	A 66-byte ElGamal Ciphertext for the auditor. Required if `sfAuditorEncryptionKey` is present on the issuance.
`BlindingFactor`	Yes	`string`	`UINT256`	N/A	The scalar value used to encrypt the amount. Used by validators to verify the ciphertexts match the plaintext `MPTAmount`. Its length is fixed at 32 bytes by the `UINT256` encoding, so no separate length check applies.
`ZKProof`	No	`string`	`BLOB`	N/A	A Schnorr Proof of Knowledge (PoK). Required only when `HolderEncryptionKey` is present. MUST be absent when `HolderEncryptionKey` is absent.

Notes:

This transaction performs self-conversion only; there is no Receiver field.
Issuers introduce supply via existing XLS-33 public issuance. An issuer-controlled dedicated account executes this transaction as a regular holder.

8.3. Transaction Fee¶

Fee Structure: Custom

This transaction requires 10 times the standard base fee because zero-knowledge proof verification costs validators significantly more than processing a public MPT transaction.

8.4. Failure Conditions¶

8.4.1. Data Verification¶

The ConfidentialTransfer feature is not enabled on the ledger. (temDISABLED)
sfAccount is the Issuer. (temMALFORMED)
sfHolderEncryptionKey is present but sfZKProof is missing. (temMALFORMED)
sfHolderEncryptionKey is absent but sfZKProof is present. (temMALFORMED)
The length of sfHolderEncryptionKey is not exactly 33 bytes. (temMALFORMED)
The length of sfZKProof is not exactly 64 bytes. (temMALFORMED)
Any provided ciphertext (Holder, Issuer, or Auditor) has an invalid length or represents an invalid elliptic curve point. (temBAD_CIPHERTEXT)
MPTAmount is less than zero or exceeds the maximum allowable MPT amount. (temBAD_AMOUNT)

8.4.2. Protocol-Level Failures¶

The MPTokenIssuance or the holder's MPToken object does not exist. (tecOBJECT_NOT_FOUND)
The issuance does not have the lsfMPTCanHoldConfidentialBalance flag set, or has no registered sfIssuerEncryptionKey. (tecNO_PERMISSION)
The issuance has sfAuditorEncryptionKey set but the transaction does not include sfAuditorEncryptedAmount, or the issuance has no auditor key but the transaction includes sfAuditorEncryptedAmount. (tecNO_PERMISSION)
The holder's MPToken is locked, or the entire issuance is locked. (tecLOCKED)
The issuance requires authorization (lsfMPTRequireAuth) and the holder's MPToken is not authorized (lsfMPTAuthorized is not set). (tecNO_AUTH)
The holder does not have sufficient public MPT balance to cover the MPTAmount. (tecINSUFFICIENT_FUNDS)
No HolderEncryptionKey is provided in the transaction and the account does not have a registered sfHolderEncryptionKey on ledger. (tecNO_PERMISSION)
A public key is provided in the transaction, but the account already has a registered key. (tecDUPLICATE)
The BlindingFactor fails to reconstruct the provided ciphertexts given the plaintext MPTAmount. (tecBAD_PROOF)
The Schnorr ZKProof fails to verify the holder's knowledge of the secret key. (tecBAD_PROOF)

8.5. State Changes¶

If the transaction is successful:

The holder's public sfMPTAmount is decreased by the converted amount.
The sfConfidentialOutstandingAmount on the MPTokenIssuance object is increased by the converted amount.
The holder's sfHolderEncryptionKey is registered on their MPToken object if it was not already present.
The sfConfidentialBalanceInbox and sfIssuerEncryptedBalance are updated by homomorphically adding the provided ciphertexts.
If the issuance has an auditor configured (sfAuditorEncryptionKey present), sfAuditorEncryptedBalance is likewise updated by homomorphically adding AuditorEncryptedAmount.
If initializing confidential state for the first time, sfConfidentialBalanceSpending is initialized with an encrypted zero and the version counter is set to 0.

8.6 Example JSON¶

{
  "Account": "rBob...",
  "TransactionType": "ConfidentialMPTConvert",
  "MPTokenIssuanceID": "610F33...",
  "MPTAmount": 1000,
  "HolderEncryptionKey": "038d...",
  "HolderEncryptedAmount": "AD3F...",
  "IssuerEncryptedAmount": "BC2E...",
  "BlindingFactor": "EE21...",
  "ZKProof": "ABCD..."
}

9. Transaction: `ConfidentialMPTSend`¶

Purpose: Performs a confidential transfer of MPT value between accounts while keeping the transfer amount hidden. The transferred amount is credited to the receiver’s confidential inbox balance (CB_IN) to avoid proof staleness; the receiver may later merge these funds into the spending balance (CB_S) via ConfidentialMPTMergeInbox.

This transaction honors Deposit Authorization and Credentials (XLS-70), ensuring that confidential transfers respect the same authorization requirements as standard MPT payments.

9.1 Use Cases¶

Holder → holder (including any issuer-controlled dedicated account): Confidential redistribution of value with the transfer amount hidden.
Dedicated account ↔ holder: Confidential redistribution among non-issuer holders under identical rules.

9.2. Fields¶

Field Name	Required?	JSON Type	Internal Type	Default Value	Description
`TransactionType`	Yes	`string`	`UINT16`	N/A	Identifies this as a `ConfidentialMPTSend`, which is 88.
`Account`	Yes	`string`	`ACCOUNTID`	N/A	The sender's XRPL account.
`Destination`	Yes	`string`	`ACCOUNTID`	N/A	The receiver's XRPL account.
`DestinationTag`	No	`number`	`UINT32`	N/A	Arbitrary tag identifying the reason for the transfer, or a hosted recipient at the destination. Required if the destination account has `lsfRequireDestTag` set.
`MPTokenIssuanceID`	Yes	`string`	`UINT192`	N/A	Identifier of the MPT issuance being transferred.
`SenderEncryptedAmount`	Yes	`string`	`BLOB`	N/A	Ciphertext used to homomorphically debit the sender's spending balance.
`DestinationEncryptedAmount`	Yes	`string`	`BLOB`	N/A	Ciphertext credited to the receiver's inbox balance.
`IssuerEncryptedAmount`	Yes	`string`	`BLOB`	N/A	Ciphertext used to update the issuer mirror balance.
`ZKProof`	Yes	`string`	`BLOB`	N/A	A 946-byte bundle containing a compact sigma proof (192 bytes, proving ciphertext consistency across all recipients, amount linkage to `AmountCommitment`, and balance linkage to `BalanceCommitment`) and an aggregated Bulletproof range proof (754 bytes, proving both the transfer amount and remaining balance are non-negative).
`BalanceCommitment`	Yes	`string`	`BLOB`	N/A	A cryptographic commitment to the user's confidential spending balance.
`AmountCommitment`	Yes	`string`	`BLOB`	N/A	A cryptographic commitment to the amount being transferred.
`AuditorEncryptedAmount`	No	`string`	`BLOB`	N/A	Ciphertext for the auditor. Required if `sfAuditorEncryptionKey` is present on the issuance.
`CredentialIDs`	No	`array`	`Vector256`	N/A	Credential(s) to attach to the transaction for authorization purposes (XLS-70).

9.3. Transaction Fee¶

Fee Structure: Custom

This transaction requires 10 times the standard base fee because zero-knowledge proof verification costs validators significantly more than processing a public MPT transaction.

9.4. Failure Conditions¶

9.4.1. Data Verification¶

The ConfidentialTransfer feature is not enabled on the ledger. (temDISABLED)
The sender is the issuer of the MPT. (temMALFORMED)
The destination is the issuer of the MPT. (temMALFORMED)
The sender and destination accounts are the same. (temMALFORMED)
The ZKProof is not exactly 946 bytes. (temMALFORMED)
The BalanceCommitment or AmountCommitment is not a valid 33-byte compressed elliptic curve point. (temMALFORMED)
Any required encrypted amount (SenderEncryptedAmount, DestinationEncryptedAmount, or IssuerEncryptedAmount) has an invalid length or represents an invalid elliptic curve point. (temBAD_CIPHERTEXT)
The AuditorEncryptedAmount (if present) has an invalid length or represents an invalid elliptic curve point. (temBAD_CIPHERTEXT)

9.4.2. Protocol-Level Failures¶

The destination account does not exist. (tecNO_TARGET)
The destination account has lsfRequireDestTag set, but the transaction does not include a DestinationTag. (tecDST_TAG_NEEDED)
The MPTokenIssuance, or the sender's or destination's MPToken object, does not exist. (tecOBJECT_NOT_FOUND)
The issuance does not have the lsfMPTCanTransfer flag set. (tecNO_AUTH)
The issuance does not support confidential balance (lsfMPTCanHoldConfidentialBalance is not set). (tecNO_PERMISSION)
The issuance has a non-zero sfTransferFee. (tecNO_PERMISSION)
The issuance has no registered sfIssuerEncryptionKey. (tecNO_PERMISSION)
The issuance has sfAuditorEncryptionKey set but the transaction does not include sfAuditorEncryptedAmount, or the issuance has no auditor key but the transaction includes sfAuditorEncryptedAmount. (tecNO_PERMISSION)
One of the participating accounts lacks a registered ElGamal public key or the confidential fields required for its role: the sender needs sfHolderEncryptionKey, sfConfidentialBalanceSpending, and sfIssuerEncryptedBalance; the destination needs sfHolderEncryptionKey, sfConfidentialBalanceInbox, and sfIssuerEncryptedBalance. (tecNO_PERMISSION)
Either the sender's or receiver's balance is currently locked. (tecLOCKED)
The issuance requires authorization (lsfMPTRequireAuth) and either the sender's or the destination's MPToken is not authorized (lsfMPTAuthorized is not set). (tecNO_AUTH)
The provided Zero-Knowledge Proof fails to verify equality or range constraints. (tecBAD_PROOF)

9.3.2.1. Authorization Failures¶

The destination account has Deposit Authorization enabled (lsfDepositAuth), and the sender is not preauthorized. (tecNO_PERMISSION)
The destination account requires credentials (via DepositPreauth with AuthorizeCredentials), but the transaction does not include valid matching credentials in the CredentialIDs field. (tecNO_PERMISSION)
A credential ID specified in CredentialIDs does not exist, does not belong to the sender, or is not accepted: (tecBAD_CREDENTIALS)
A credential in CredentialIDs is expired:
If deposit-preauth otherwise passes and doApply runs, cleanupExpiredCredentials deletes it and returns tecEXPIRED.
If deposit-preauth fails first because the credential issuer/type is not authorized, preclaim returns tecNO_PERMISSION, and cleanup does not run.

9.5. State Changes¶

If the transaction is successful:

Sender Balance: The sender's sfConfidentialBalanceSpending is homomorphically decremented by SenderEncryptedAmount.
Sender Versioning: The sender's sfConfidentialBalanceVersion is incremented by 1 to prevent stale-proof replay.
Receiver Balance: The receiver's sfConfidentialBalanceInbox is homomorphically incremented by the re-randomized DestinationEncryptedAmount.
Issuer Mirrors: The sender's sfIssuerEncryptedBalance is homomorphically decremented by IssuerEncryptedAmount, and the receiver's sfIssuerEncryptedBalance is homomorphically incremented by the re-randomized IssuerEncryptedAmount.
Auditor Mirrors: If the issuance has an auditor configured (sfAuditorEncryptionKey present), the sender's sfAuditorEncryptedBalance is homomorphically decremented by AuditorEncryptedAmount, and the receiver's sfAuditorEncryptedBalance is homomorphically incremented by the re-randomized AuditorEncryptedAmount.
Receiver Versioning: The receiver's sfConfidentialBalanceVersion is not modified. Incoming transfers land in the inbox and therefore cannot invalidate proofs bound to the receiver's spending balance.
Global Supply: Plaintext supply fields (OA and COA) remain unchanged.

Note on re-randomization: "Re-randomized" means that, before a ciphertext is credited to the receiver, an encryption of zero under the same public key is homomorphically added to it. The randomness for that zero encryption is the first 32 bytes of the ZKProof field. Since the added ciphertext encrypts 0, the credited value is unchanged; and since the randomness is read directly from the transaction, every validator derives identical ledger state. Only the three credit-side ciphertexts are treated this way, the ciphertexts subtracted from the sender are applied exactly as submitted. This prevents an attacker from choosing transfer randomness that cancels against a target holder's existing ciphertexts (see §16.8).

9.6. Example JSON¶

{
  "Account": "rSenderAccount...",
  "TransactionType": "ConfidentialMPTSend",
  "Destination": "rReceiverAccount...",
  "MPTokenIssuanceID": "610F33B8EBF7EC795F822A454FB852156AEFE50BE0CB8326338A81CD74801864",
  "SenderEncryptedAmount": "AD3F...",
  "DestinationEncryptedAmount": "DF4E...",
  "BalanceCommitment": "038A...",
  "AmountCommitment": "049B...",
  "IssuerEncryptedAmount": "BC2E...",
  "CredentialIDs": ["DD40031C6C21164E7673...17D467CEEE9"],  // Optional: for credential-based authorization
  "ZKProof": "84af..."
}

Net effect: Public balances unchanged; confidential balance is redistributed (sender CB_S ↓, receiver CB_IN ↑). OA (plaintext) unchanged; COA (plaintext) unchanged.

10. Transaction: `ConfidentialMPTMergeInbox`¶

Purpose: Moves all funds from the inbox balance into the spending balance, then resets the inbox to a canonical encrypted zero (EncZero). This ensures that proofs reference only stable spending balances and prevents staleness from incoming transfers.

This transaction respects authorization and lock constraints, ensuring that unauthorized or locked holders cannot merge funds.

10.1 Use Cases¶

A holder merges newly received confidential transfers into their spendable balance.
An issuer-controlled dedicated account merges its own inbox into the spending balance, like any holder.
Required periodically to combine funds before subsequent confidential sends.

10.2 Fields¶

Field Name	Required?	JSON Type	Internal Type	Default Value	Description
`TransactionType`	Yes	`string`	`UINT16`	N/A	Identifies this as a `ConfidentialMPTMergeInbox` transaction, which is 86.
`Account`	Yes	`string`	`ACCOUNTID`	N/A	The account performing the merge.
`MPTokenIssuanceID`	Yes	`string`	`UINT192`	N/A	The unique identifier for the MPT issuance.

10.3. Transaction Fee¶

Fee Structure: Custom

This transaction requires 10 times the standard base fee because it performs homomorphic operations on the holder's, issuer's, and auditor's ciphertext balances. It carries no zero-knowledge proof, but pays the same fee as the other confidential MPT transactions.

10.4. Failure Conditions¶

10.4.1. Data Verification¶

The ConfidentialTransfer feature is not enabled. (temDISABLED)
The account submitting the transaction is the Issuer. (temMALFORMED)

10.4.2. Protocol-Level Failures¶

The MPTokenIssuance or the user's MPToken object does not exist. (tecOBJECT_NOT_FOUND)
The issuance does not have the lsfMPTCanHoldConfidentialBalance flag set. (tecNO_PERMISSION)
The user's MPToken object has not been initialized (missing sfConfidentialBalanceInbox, sfConfidentialBalanceSpending, or sfHolderEncryptionKey). (tecNO_PERMISSION)
The issuance requires authorization (lsfMPTRequireAuth) and the holder's MPToken is not authorized (lsfMPTAuthorized is not set). (tecNO_AUTH)
The holder's MPToken is locked at the individual level (the lsfMPTLocked flag is set on the MPToken). (tecLOCKED)
The entire token issuance is locked (the lsfMPTLocked flag is set on the MPTokenIssuance). (tecLOCKED)
A system invariant failure where the issuer attempts to merge. (tefINTERNAL)

10.5. State Changes¶

If the transaction is successful:

Update Spending Balance: The current sfConfidentialBalanceInbox is homomorphically added to sfConfidentialBalanceSpending.
Reset Inbox: The sfConfidentialBalanceInbox is reset to a canonical encrypted zero. This ensures the account is ready to receive new transfers without arithmetic errors.
Increment Version: The sfConfidentialBalanceVersion is incremented by 1. If the version reaches the maximum 32-bit integer value, it wraps around to 0.
Mirrors Untouched: sfIssuerEncryptedBalance and sfAuditorEncryptedBalance are not written. They mirror the holder's total confidential balance, and this transaction only moves value between CB_IN and CB_S, so that total is unchanged.
No-op with encrypted zero: If either or both of sfConfidentialBalanceInbox and sfConfidentialBalanceSpending already contain an encrypted zero at the time of the merge, the transaction is still valid and succeeds. The inbox (EncZero) is homomorphically added to the spending balance (leaving it unchanged), the inbox is reset to EncZero, and sfConfidentialBalanceVersion is still incremented. This is a valid no-op: no value moves, but the version bump still occurs, allowing holders to advance their proof version without any pending inbound funds.

10.6. Example JSON¶

{
  "Account": "rUserAccount...",
  "TransactionType": "ConfidentialMPTMergeInbox",
  "MPTokenIssuanceID": "610F33B8EBF7EC795F822A454FB852156AEFE50BE0CB8326338A81CD74801864"
}

11. Transaction: `ConfidentialMPTConvertBack`¶

11.1 Purpose: Convert confidential into public MPT value.¶

For a holder: restore public balance from CB_S.
For an issuer-controlled dedicated account: return confidential supply to public form (credited to the dedicated account’s public balance).

11.2 Account Effects¶

Confidential Supply (COA): Decreases (COA ↓).
Total Supply (OA): Unchanged. (Tokens are converted to public form, not burned).
Holder Public Balance: Increases.
Holder Confidential Balance: Decreases.

11.3. Fields¶

Field Name	Required?	JSON Type	Internal Type	Default Value	Description
`TransactionType`	Yes	`string`	`UINT16`	N/A	Identifies this as a `ConfidentialMPTConvertBack`, which is 87.
`Account`	Yes	`string`	`ACCOUNTID`	N/A	The account performing the conversion.
`MPTokenIssuanceID`	Yes	`string`	`UINT192`	N/A	The unique identifier for the MPT issuance.
`MPTAmount`	Yes	`number`	`UINT64`	N/A	The plaintext amount to credit to the public balance.
`HolderEncryptedAmount`	Yes	`string`	`BLOB`	N/A	A 66-byte ciphertext to be subtracted from the holder's `sfConfidentialBalanceSpending`.
`IssuerEncryptedAmount`	Yes	`string`	`BLOB`	N/A	A 66-byte ciphertext to be subtracted from the issuer's mirror balance.
`BlindingFactor`	Yes	`string`	`UINT256`	N/A	The scalar value used to encrypt the amount. Used by validators to verify the ciphertexts match the plaintext `MPTAmount`. Its length is fixed at 32 bytes by the `UINT256` encoding, so no separate length check applies.
`AuditorEncryptedAmount`	No	`string`	`BLOB`	N/A	A 66-byte ciphertext for the auditor. Required if `sfAuditorEncryptionKey` is present on the issuance.
`BalanceCommitment`	Yes	`string`	`BLOB`	N/A	A 33-byte cryptographic commitment to the user's confidential spending balance.
`ZKProof`	Yes	`string`	`BLOB`	N/A	An 816-byte bundle containing a compact sigma proof (128 bytes, proving balance ownership and key linkage) and a single Bulletproof range proof (688 bytes, proving the remaining balance is non-negative).

11.4. Transaction Fee¶

Fee Structure: Custom

This transaction requires 10 times the standard base fee because zero-knowledge proof verification costs validators significantly more than processing a public MPT transaction.

11.5. Failure Conditions¶

11.5.1. Data Verification¶

The ConfidentialTransfer feature is not enabled. (temDISABLED)
The account submitting the transaction is the Issuer. (temMALFORMED)
Ciphertext lengths or formats are invalid. (temBAD_CIPHERTEXT)
MPTAmount is zero or greater than the maximum allowable supply. (temBAD_AMOUNT)
The BalanceCommitment is not a valid 33-byte compressed elliptic curve point. (temMALFORMED)
The ZKProof is not exactly 816 bytes. (temMALFORMED)

11.5.2. Protocol-Level Failures¶

The MPToken or MPTokenIssuance does not exist. (tecOBJECT_NOT_FOUND)
The issuance does not have the lsfMPTCanHoldConfidentialBalance flag set, or has no registered sfIssuerEncryptionKey. (tecNO_PERMISSION)
The user's MPToken is missing the sfConfidentialBalanceSpending, sfHolderEncryptionKey, or sfIssuerEncryptedBalance fields. (tecNO_PERMISSION)
The issuance has sfAuditorEncryptionKey set but the transaction does not include sfAuditorEncryptedAmount, or the issuance has no auditor key but the transaction includes sfAuditorEncryptedAmount. (tecNO_PERMISSION)
The global sfConfidentialOutstandingAmount is less than the requested MPTAmount. (tecINSUFFICIENT_FUNDS)
The holder's MPToken is locked, or the entire issuance is locked. (tecLOCKED)
The issuance requires authorization (lsfMPTRequireAuth) and the holder's MPToken is not authorized (lsfMPTAuthorized is not set). (tecNO_AUTH)
The BlindingFactor fails to verify the integrity of the ciphertexts. (tecBAD_PROOF)
The ZKProof fails the compact sigma proof check. (tecBAD_PROOF)
The ZKProof fails the Bulletproof range proof check. (tecBAD_PROOF)

11.6. State Changes¶

If the transaction is successful:

Public Balance: The user's sfMPTAmount is increased by MPTAmount.
Global Supply: The sfConfidentialOutstandingAmount on the issuance is decreased by MPTAmount.
Spending Balance: The sfConfidentialBalanceSpending is updated via homomorphic subtraction of HolderEncryptedAmount.
Issuer Mirror: The sfIssuerEncryptedBalance is updated via homomorphic subtraction of IssuerEncryptedAmount.
Auditor Mirror: If the issuance has an auditor configured (sfAuditorEncryptionKey present), the sfAuditorEncryptedBalance is updated via homomorphic subtraction of AuditorEncryptedAmount.
Version: The sfConfidentialBalanceVersion is incremented by 1.

11.7. Example JSON¶

{
  "Account": "rUserAccount...",
  "TransactionType": "ConfidentialMPTConvertBack",
  "MPTokenIssuanceID": "610F33...",
  "MPTAmount": 500,
  "HolderEncryptedAmount": "AD3F...",
  "IssuerEncryptedAmount": "BC2E...",
  "AuditorEncryptedAmount": "C1A9...",
  "BlindingFactor": "12AB...",
  "BalanceCommitment": "038A...",
  "ZKProof": "ABCD..."
}

11.8. Edge Case Analysis (Low-Volume Transaction Flow):¶

** Alice, the issuer, funds her dedicated account with 50 ConfidentialMPT publicly, the dedicated account converts to confidential, performs a single confidential send of 20 to Bob (a holder), and then executes a ConvertBack of 30.

Step 1. Issuer funds dedicated account, dedicated account converts (50)

Publicly revealed: Amount \= 50.
Ledger effect: OA ↑ 50, COA ↑ 50, IPB ↓ 50.
Outsiders now know: 50 CMPT entered confidential circulation.

Step 2. Confidential Send (Alice’s dedicated account → Bob, amount 20)

Public sees: sender \= Alice’s dedicated account, receiver \= Bob, ciphertexts, ZKPs.
Amount 20 is hidden.
Ledger effect: OA, COA, IPB unchanged (just redistribution).

Step 3. ConvertBack (Alice’s dedicated account, 30)

Publicly revealed: Amount \= 30.
Ledger effect: OA unchanged, COA ↓ 30, IPB ↑ 30
Alice’s confidential balance is now 0, but outsiders cannot know this since ElGamal ciphertexts for 0 look indistinguishable from nonzero.

11.8.1 What Outsiders can Infer:¶

Net change in the confidential pool is 50 − 30 = 20. So, 20 CMPT remain somewhere in confidential circulation.
But they cannot know whether Bob got 20, 15, 5, or even 0 — because Alice’s dedicated account may still hold some of the 20.

11.8.2 Why no exact leakage:¶

ElGamal ciphertexts are randomized: encrypting 0 produces a different-looking ciphertext each time.
Outsiders cannot look at the dedicated account’s balance ciphertext and say it is zero.
Thus, they cannot deduce whether Alice’s dedicated account was emptied or kept some confidential balance.

Note: This design allows tokens to move between public and private states. While the Convert and ConvertBack transactions show their amounts to provide this flexibility, they still protect the privacy of individual balances and transfers. Observers can only see the total change in circulation, not how the private supply is shared among holders. ElGamal randomization makes it impossible to tell the difference between accounts with zero balances. This ensures that outsiders cannot know if a specific account is empty or still holds private tokens.

12. Transaction: `ConfidentialMPTClawback`¶

Clawback involves the issuer forcibly reclaiming funds from a holder's account. This action is fundamentally incompatible with standard confidential transfers, as the issuer does not possess the holder's private ElGamal key and therefore cannot generate the required ZKPs for a normal ConfidentialMPTSend. To solve this, the protocol introduces a single and privileged transaction that allows an issuer to verifiably reclaim funds in one uninterruptible step.

This issuer-only transaction is designed to forcibly burn a holder's entire confidential balance, permanently removing those tokens from circulation. Both OutstandingAmount (OA) and ConfidentialOutstandingAmount (COA) are reduced, effectively destroying the tokens rather than returning them to the issuer's reserve.

12.1 How the Clawback Process Works¶

Issuer Decrypts and Prepares: The issuer takes the sfIssuerEncryptedBalance ciphertext from the HolderToClawback's MPToken object and uses its own private key to decrypt it, revealing the holder's total confidential balance, m.
Issuer Submits Transaction: The issuer creates and signs a ConfidentialMPTClawback transaction, setting the MPTAmount field to m. It also generates and includes a compact Clawback sigma proof.
Validator Verification and Execution: Validators receive the transaction and perform a series of checks and state changes as a single:
Verification: They first confirm the transaction was signed by the token Issuer and that the ZKProof is valid. The proof provides cryptographic certainty that MPTAmount is the true value hidden in the holder's on-ledger ciphertext.
Ledger Changes: If the proof is valid, the validators execute all of the following changes at once:
1. The ConfidentialBalanceSpending and ConfidentialBalanceInbox are set to a valid encryption of zero.
2. The global ConfidentialOutstandingAmount (COA) is decreased by MPTAmount.
3. The global OutstandingAmount (OA) is decreased by MPTAmount, burning the clawed-back tokens. The funds are permanently removed from circulation and are not credited to any account.

Note: We recommend locking the MPT before clawing back. This prevents the holder from sending any more mpt transactions while the clawback is in progress.

12.2. Fields¶

Field Name	Required?	JSON Type	Internal Type	Default Value	Description
`TransactionType`	Yes	`string`	`UINT16`	N/A	Identifies this as a `ConfidentialMPTClawback` transaction, which is 89.
`Account`	Yes	`string`	`ACCOUNTID`	N/A	The Issuer account sending the transaction.
`Holder`	Yes	`string`	`ACCOUNTID`	N/A	The account from which funds are being clawed back.
`MPTokenIssuanceID`	Yes	`string`	`UINT192`	N/A	The unique identifier for the MPT issuance.
`MPTAmount`	Yes	`number`	`UINT64`	N/A	The plaintext total amount being removed.
`ZKProof`	Yes	`string`	`BLOB`	N/A	A 64-byte AND-composed compact Clawback sigma proof proving that the `sfIssuerEncryptedBalance` encrypts the plaintext `MPTAmount`.

This single transaction securely and verifiably burns the holder's confidential balance, removing the tokens from circulation without crediting them to any account, while ensuring the integrity of the ledger's public accounting is perfectly maintained.

12.3. Transaction Fee¶

Fee Structure: Custom

This transaction requires 10 times the standard base fee because zero-knowledge proof verification costs validators significantly more than processing a public MPT transaction.

12.4. Failure Conditions¶

12.4.1. Data Verification¶

The ConfidentialTransfer feature is not enabled. (temDISABLED)
The Account is not the issuer of the MPTokenIssuanceID. (temMALFORMED)
The Account is attempting to claw back from itself (Account == Holder). (temMALFORMED)
The ZKProof is not exactly 64 bytes. (temMALFORMED)
MPTAmount is zero or exceeds the maximum limits. (temBAD_AMOUNT)

12.4.2. Protocol-Level Failures¶

The Holder account does not exist. (tecNO_TARGET)
The MPTokenIssuance or the holder's MPToken object does not exist. (tecOBJECT_NOT_FOUND)
The issuance does not have the lsfMPTCanClawback flag set. (tecNO_PERMISSION)
The issuance is missing the sfIssuerEncryptionKey. (tecNO_PERMISSION)
The issuance does not have the lsfMPTCanHoldConfidentialBalance flag set. (tecNO_PERMISSION)
The holder's MPToken is missing the sfIssuerEncryptedBalance. (tecNO_PERMISSION)
The holder's MPToken is missing the sfHolderEncryptionKey. (tecNO_PERMISSION)
The MPTAmount exceeds the global sfConfidentialOutstandingAmount, or exceeds the global sfOutstandingAmount. (tecINSUFFICIENT_FUNDS)
The ZKP fails to prove that the sfIssuerEncryptedBalance (the mirror balance) encrypts the plaintext MPTAmount. (tecBAD_PROOF)

12.5. State Changes¶

If the transaction is successful, the holder's confidential state is reset, and the tokens are removed from the total supply:

Holder State Reset:
sfConfidentialBalanceInbox is set to Encrypted Zero.
sfConfidentialBalanceSpending is set to Encrypted Zero.
sfIssuerEncryptedBalance is set to Encrypted Zero.
sfAuditorEncryptedBalance (if present) is set to Encrypted Zero (using the Auditor's public key).
sfConfidentialBalanceVersion is incremented by 1.
Supply Reduction:
The global sfConfidentialOutstandingAmount (COA) is decreased by MPTAmount.
The global sfOutstandingAmount (OA) is decreased by MPTAmount.

12.6. Example JSON¶

{
  "Account": "rIssuerAccount...",
  "TransactionType": "ConfidentialMPTClawback",
  "Holder": "rMaliciousHolder...",
  "MPTokenIssuanceID": "610F33B8EBF7EC795F822A454FB852156AEFE50BE0CB8326338A81CD74801864",
  "MPTAmount": 1000,
  "ZKProof": "a1b2..."
}

13. Transaction: `MPTokenIssuanceSet`¶

The existing MPTokenIssuanceSet transaction is extended to manage the confidential lifecycle of an MPT issuance. This includes enabling confidential balance status and registering encryption keys.

13.1. Usage & Mutability¶

This transaction is the only method to register keys or enable the confidential balance status (via the Flags field with the tfMPTSetCanHoldConfidentialBalance bit flag) of an issuance. However, these actions are subject to strict state constraints to prevent funds from becoming locked or un-auditable.

Key Registration: Encryption keys (IssuerEncryptionKey and AuditorEncryptionKey) can be set in the same transaction that enables the lsfMPTCanHoldConfidentialBalance flag using tfMPTSetCanHoldConfidentialBalance, allowing issuers to enable confidential transfers and register keys in a single atomic operation.

13.2. Fields¶

The following fields are introduced by this extension to support encryption key registration on the MPTokenIssuance object:

Field Name	Required?	JSON Type	Internal Type	Description
`IssuerEncryptionKey`	No	`string`	`BLOB`	The 33-byte EC-ElGamal public key used for the issuer's mirror balances.
`AuditorEncryptionKey`	No	`string`	`BLOB`	The 33-byte EC-ElGamal public key used for regulatory oversight (if applicable).

The following existing field is extended with a new bit flag to support enabling the confidential balance feature post-issuance:

Field Name	Required?	JSON Type	Internal Type	Description
`ImmutableFlags`	No	`number`	`UINT32`	Indicates which fields or flags of this token issuance can NOT be modified after creation.

13.3. Flags¶

The following bit flag is added to the Flags field to enable the confidential balance feature:

Flag Name	Hex Value	Decimal Value	Description
`tfMPTSetCanHoldConfidentialBalance`	`0x00000100`	256	Sets the `lsfMPTCanHoldConfidentialBalance` flag on the `MPTokenIssuance`. Only valid if `lsifMPTCanHoldConfidentialBalance` is not set.

Usage Notes:

These flags can only be used if the lsifMPTCanHoldConfidentialBalance flag was not set under sfImmutableFlags during MPTokenIssuanceCreate.
Setting tfMPTSetCanHoldConfidentialBalance enables confidential transfers for the token.
Enabling confidential transfers is one-way: there is no flag to clear lsfMPTCanHoldConfidentialBalance once it has been set.

13.4. Failure Conditions¶

13.4.1. Data Verification¶

The featureConfidentialTransfer is not enabled and the transaction supplies sfIssuerEncryptionKey or sfAuditorEncryptionKey, sets tfMPTSetCanHoldConfidentialBalance, or sets lsifMPTCanHoldConfidentialBalance in sfImmutableFlags. (temDISABLED)
The provided Public Key is not a valid 33-byte (ecPubKeyLength) compressed elliptic curve point. (temMALFORMED)
The transaction attempts to mutate confidential amount fields while also acting as a Holder, that is, it includes Holder together with sfIssuerEncryptionKey, sfAuditorEncryptionKey, or tfMPTSetCanHoldConfidentialBalance. (temMALFORMED)
The transaction contains sfAuditorEncryptionKey but does not contain sfIssuerEncryptionKey. (temMALFORMED)
The transaction sets tfMPTSetCanHoldConfidentialBalance or lsifMPTCanHoldConfidentialBalance while the DynamicMPT amendment is not enabled. (temDISABLED)
The transaction sets a non-zero TransferFee and tfMPTSetCanHoldConfidentialBalance in the same transaction (see §6.4). (temBAD_TRANSFER_FEE)

13.4.2. Protocol-Level Failures¶

The transaction attempts to use tfMPTSetCanHoldConfidentialBalance, but the lsifMPTCanHoldConfidentialBalance flag is set in sfImmutableFlags. (tecNO_PERMISSION)
The transaction provides a sfIssuerEncryptionKey (or Auditor Key), but the issuance object already has one. (tecNO_PERMISSION)
The transaction provides a sfIssuerEncryptionKey or sfAuditorEncryptionKey, but the issuance does not have the lsfMPTCanHoldConfidentialBalance flag enabled.
Exception: Keys can be set if the lsfMPTCanHoldConfidentialBalance flag is being enabled in the same transaction via tfMPTSetCanHoldConfidentialBalance. (tecNO_PERMISSION)
The transaction attempts to upload keys or set tfMPTSetCanHoldConfidentialBalance, but sfConfidentialOutstandingAmount is greater than zero (tokens are already in confidential circulation). (tecNO_PERMISSION)
The MPTokenIssuance does not exist. (tecOBJECT_NOT_FOUND)
The transaction sets a non-zero TransferFee while the issuance already has lsfMPTCanHoldConfidentialBalance, or sets tfMPTSetCanHoldConfidentialBalance while the issuance already has a non-zero TransferFee (see §6.4). (tecNO_PERMISSION)

13.5. State Changes¶

If successful:

Flags: The lsfMPTCanHoldConfidentialBalance flag is updated (if mutable).
Keys: The sfIssuerEncryptionKey and/or sfAuditorEncryptionKey are stored on the MPTokenIssuance ledger entry.

13.6. Example JSON¶

13.6.1. Enabling Confidential Balance Feature¶

{
  "Account": "rIssuerAccount...",
  "TransactionType": "MPTokenIssuanceSet",
  "MPTokenIssuanceID": "610F33...",
  "Flags": 256, // tfMPTSetCanHoldConfidentialBalance
  "IssuerEncryptionKey": "028d...",
  "AuditorEncryptionKey": "037c..."
}

This transaction enables the confidential balance feature by setting the tfMPTSetCanHoldConfidentialBalance bit flag in the Flags field, and simultaneously registers the encryption keys in the same atomic operation. This demonstrates that keys can be set when the lsfMPTCanHoldConfidentialBalance flag is being enabled in the same transaction.

14. Rationale¶

This section records why the design looks the way it does, which alternatives were considered, and which trade-offs were accepted. The normative rules themselves are in §6 through §13.

14.1. Issuer Participation Through a Dedicated Account¶

Under XLS-33, issuers don't hold MPTokens directly on their issuance object—OutstandingAmount only tracks tokens held by ordinary accounts. Changing OutstandingAmount to include issuer holdings would break accounting for existing MPTs, while tracking issuer holdings separately would destroy the safety check anchoring encrypted supply to plaintext supply. Instead, the issuer simply uses a dedicated holder account (§5.1), allowing its balance to be tracked in OutstandingAmount like any other user's.

14.2. Parallel Ciphertexts for the Issuer and Auditor¶

A confidential balance is stored as parallel ciphertexts of the same value under the holder's key, the issuer's key, and optionally an auditor's key (§5.3). Encrypting only under the holder's key would leave the issuer unable to verify its own supply and would leave no compliance path short of voluntary disclosure by each holder. Compact sigma proofs bind the parallel ciphertexts to a single hidden value, so a holder cannot present different amounts to different readers.

14.3. Amounts Are Revealed on Conversion¶

ConfidentialMPTConvert and ConfidentialMPTConvertBack disclose their amounts in plaintext, unlike ConfidentialMPTSend. Hiding them would require proving in zero knowledge that the public balance change matches the confidential one, and would force OutstandingAmount and ConfidentialOutstandingAmount to be tracked as ciphertexts. Keeping both totals in plaintext is what makes the supply invariants in §6.6 checkable at all. §11.8 works through the resulting leakage for a low-volume flow.

14.4. Incompatibility with Percentage Transfer Fees¶

XLS-33 transfer fees are based on a percentage of the amount being sent, but ConfidentialMPTSend intentionally hides that amount. To charge the fee correctly, you’d have to either reveal the transfer amount, trust the sender to report it honestly, or add a new zero-knowledge proof to verify the fee math.

Revealing the amount ruins privacy, and adding complex zero-knowledge proofs isn't worth the overhead for a feature issuers can just turn off. Because of this, an issuance cannot use both transfer fees and confidential transfers (§6.4).

14.5. A Flat Fee Multiplier¶

Every confidential transaction pays 10 times the standard base fee. Pricing each transaction type in proportion to its actual verification cost was considered and rejected as unnecessary complexity, with the consequence that ConfidentialMPTMergeInbox, which carries no proof at all, pays the same multiplier as ConfidentialMPTSend.

14.6. Proof System¶

An earlier version of this design used separate equality and range proofs in each transaction. Those were replaced by a single compact sigma proof per transaction type, which bundles the statements into a fixed-size blob verified in one pass and reduced the ConfidentialMPTSend sigma component from roughly 619 bytes to 192 bytes (§A.11). Range proofs use Bulletproofs, aggregated where a transaction must prove more than one range; their verification remains the dominant cost (§17.2).

The scheme is EC-ElGamal over secp256k1 and is not quantum-safe. Migration to a post-quantum construction is an open research area (§A.13).

15. Operational Considerations¶

Issuers must choose between enabling transfer fees and enabling confidential transfers — these two features are mutually exclusive on the same MPTokenIssuance. ConfidentialMPTSend will fail with tecNO_PERMISSION if the issuance has a non-zero sfTransferFee.

16. Security Considerations¶

Confidential MPTs introduce cryptographic mechanisms that require careful validation and enforcement. This section summarizes key privacy guarantees, auditability mechanisms, proof requirements, and considerations against potential attack vectors.

16.1 Privacy Properties¶

Confidential MPT transactions are designed to minimize information leakage while preserving verifiability of supply and balances. Validators and external observers see only ciphertexts and ZKPs and never learn the underlying amounts except where amounts are already revealed in XLS-33 semantics.

16.1.1 Publicly Visible Information¶

Transaction type (ConfidentialMPTConvert, ConfidentialMPTSend, etc.).
Involved accounts (Account, Issuer, Destination).
MPTokenIssuanceID.
Ciphertexts (ElGamal pairs under holder, issuer, optional auditor keys).
ZKPs (non-interactive proofs of correctness).
For issuer funding (issuer sends public MPT to dedicated account, which then converts): Amount is revealed, consistent with visible mint events in XLS-33.
Whether a stored ciphertext is a canonical encrypted zero. Because that value is deterministic, anyone can compare a stored ciphertext against the known encrypted zero for that account; if they match, the balance is known to be exactly 0. This applies to a newly initialized spending balance and to a reset inbox. Non-zero ciphertexts remain opaque.

16.1.2 Hidden Information¶

Amounts moved in ConfidentialMPTSend, ConfidentialMPTMergeInbox.
Holder balances (except their public balance field).
Distribution of confidential supply across holders.

16.1.3 Transaction-Type Privacy Notes¶

Convert (holder):
Public → Confidential: Amount is revealed once, but only as a conversion event.
Thereafter, spending is hidden.
OA unchanged, COA ↑.
Send:
No amounts revealed.
OA unchanged, COA unchanged.
Merge:
No amounts revealed.
OA unchanged, COA unchanged.
Convert back:
Amount revealed.
OA unchanged, COA ↓.

16.2 Auditability & Compliance¶

The Confidential MPT model is designed to provide robust privacy for individual transactions while ensuring both the integrity of the total token supply and a high degree of flexibility for regulatory compliance and auditing.

To achieve this balance, this protocol offers flexible auditability through two distinct mechanisms. The primary method is on-chain selective disclosure, where each confidential balance is dually encrypted under a designated auditor's public key, allowing for independent, trust-minimized verification. This model is also designed for dynamic, forward-looking compliance; if a new auditor or party requires access later, the issuer can re-encrypt existing balances under the new key and provide cryptographic equality proofs to grant them access without disrupting the system or sharing existing keys. As a simpler, trust-based alternative, the protocol also supports an issuer-mediated model using view keys. In this approach, the issuer controls a separate set of keys that provide read-only access and can be shared directly with auditors on an as-needed basis.

The technical foundation for both of these models is a multi-ciphertext architecture, where each confidential balance is maintained under several different public keys (e.g., holder, issuer, and optional auditor) to serve these distinct purposes.

16.2.1 Mechanism 1: On-Chain Selective Disclosure (A Trust-Minimized Approach)¶

The primary method for compliance is on-chain selective disclosure, which provides cryptographically enforced auditability directly on the ledger.

Auditor-Specific Encryption: When an auditor is set, each confidential balance is dually encrypted under the designated auditor's public key and stored in the AuditorEncryptedBalance field on the ledger.
Independent Verification: This allows the auditor to use their own private key to independently decrypt and verify any holder's balance at any time, without needing cooperation from the issuer or the holder.
Dynamic, Forward-Looking Compliance: This model is designed for flexibility. If a new auditor or regulatory body requires access after the token has been issued, the issuer can facilitate this without disrupting the system. The process is as follows:
The issuer uses its private key to decrypt its own on-ledger copy of a holder's balance (sfIssuerEncryptedBalance).
The issuer then re-encrypts this balance under the new auditor’s public key.
Finally, the issuer provides the new ciphertext to the auditor along with a ZK equality proof that cryptographically proves that the new ciphertext matches the official on-ledger version.

This powerful re-encryption capability enables targeted, on-demand compliance without ever sharing the issuer's private key or making user balances public.

16.2.2 Mechanism 2: Issuer-Mediated Auditing (A Simple View Key Model)¶

As a simpler, trust-based alternative, the protocol also supports an issuer-mediated model using view keys.

Issuer-Controlled Keys: In this approach, the issuer controls a separate set of "view keys." All confidential balances and transaction amounts are also encrypted under these keys.
On-Demand Disclosure: When an audit is required, the issuer can share the relevant view key directly with an auditor or regulator. This key grants the third party read-only access to view the necessary confidential information.
Trust Assumption: This model is operationally simpler but requires the auditor to trust that the issuer is providing the correct and complete set of view keys for the scope of the audit.

16.2.3 Foundational Elements for Public Integrity¶

Both compliance models are built upon foundational elements that ensure the integrity of the total token supply remains publicly verifiable at all times.

Issuer Ciphertexts (sfIssuerEncryptedBalance): Every confidential balance is dually encrypted under the issuer's public key. This serves two critical functions:
It acts as the "master copy" that enables the issuer to perform the re-encryption required for dynamic selective disclosure.
It allows the issuer to monitor aggregate confidential circulation and reconcile it with public issuance.
Confidential Outstanding Amount (COA): This plaintext field on the ledger tracks the aggregate total of all non-issuer confidential balances. It provides a global, public view of the confidential supply, allowing any observer to validate the system's most important invariant: OutstandingAmount ≤ MaximumAmount.

16.2.4 Example Audit Flows¶

Public Supply Audit (No Keys Required)
An observer reads the public ledger fields: OA, COA, and MA.
They validate the invariant OA ≤ MA.
They can conclude that the total supply is within its defined limits without seeing any individual balances.
Selective Disclosure Audit (Auditor Uses Own Key)
A regulator is designated as an auditor under the on-chain policy.
The auditor fetches a holder’s ledger object and uses their own private key to decrypt the sfAuditorEncryptedBalance field, revealing the holder's confidential balance.
This balance can be cross-checked against the global COA for consistency.
View Key Audit (Issuer Provides Key)
A regulator requests access to a user's transaction history.
The issuer provides the regulator with the appropriate view key.
The regulator uses the view key to decrypt the relevant confidential balances and transaction amounts.

16.3 Proof Requirements¶

Every confidential transaction must carry appropriate ZKPs:

Convert: Deterministic ElGamal verification using the disclosed blinding factor. If a new holder key is registered, a Schnorr Proof of Knowledge is required.
Send: compact sigma proof (ciphertext consistency, amount linkage, and balance linkage) and aggregated range proof (transfer amount and remaining balance are non-negative).
Optional auditor keys: The auditor ciphertext is covered by the same compact sigma proof; no separate proof is required.

16.4 Confidential Balance Consistency¶

Each confidential balance entry maintains parallel ciphertexts:
Holder key (spendable balance).
Issuer key.
Auditor key(s), if enabled.
Validators require a proof that all ciphertexts encrypt the same plaintext, preventing divergence between views.

16.5 Dedicated Account Model¶

The issuer account cannot hold or convert to confidential balances. Issuers who wish to participate in confidential circulation may optionally use a dedicated holder account (Confidential Vault), which is treated as a standard non-issuer holder of its own MPT issuance.
Prevents redefinition of OA semantics and keeps compatibility with XLS-33.
Validators enforce that ConfidentialMPTConvert from the issuer account is invalid.

16.6 Privacy Guarantees¶

Transaction amounts are hidden in all confidential transfers except:
Issuer mint events (already visible in legacy MPTs).
Conversion from public → confidential, where only the converted amount is disclosed once.
Redistribution among holders (including any issuer-controlled dedicated account) leaks no amounts.

16.7 Auditor & Compliance Controls¶

If auditor is set, ciphertexts under auditor keys are validated by the compact sigma proof alongside holder, issuer, and other recipient ciphertexts.
Prevents issuers from selectively encrypting incorrect balances for auditors.
Selective disclosure allows compliance without undermining public confidentiality.

16.8 Attack Surface & Mitigations¶

Replay attacks: Transactions bound to unique ledger indices/versions; proofs must include domain separation.
Malformed ciphertexts: Validators reject invalid EC points.
Balance underflow: Range proofs prevent spending more than available.
Ciphertext cancellation: Homomorphic addition adds the ciphertexts' randomness, so ciphertexts with randomness r and −r sum to the point at infinity, which is not representable and makes the update fail. Because the canonical encrypted zero is deterministic, its randomness is publicly computable, so an attacker free to choose the transfer randomness could cancel it against a target holder's existing ciphertexts and permanently break their ConfidentialMPTMergeInbox or auditor-balance update. Any holder of the issuance can attempt this with an unsolicited, arbitrarily small transfer, since incoming confidential transfers cannot be refused. Mitigated by re-randomizing the credit-side ciphertexts (§9.5) with the proof's Fiat–Shamir challenge, which the attacker cannot steer.
Auditor collusion: Auditors see balances only if granted view keys; public supply integrity remains trustless.
Issuer misbehavior: Enforced by supply invariants and public COA/OA/MA checks.

17. Analysis of Transaction Cost and Performance¶

The efficiency of Confidential MPT transactions is critical to their practical deployment within XRPL’s performance constraints. This section analyzes the cryptographic payload size and verification cost of the ConfidentialMPTSend transaction, which represents the most complex confidential operation in the protocol.

We assume the common configuration where the transfer amount is encrypted under four public keys (sender, receiver, issuer mirror, auditor mirror), hence Nciphers = 4 throughout this section. All estimates assume secp256k1, 32-byte scalars, compressed curve points of 33 bytes, and EC–ElGamal ciphertexts of 66 bytes. The cryptographic payload consists of ElGamal ciphertexts, two Pedersen commitments, a compact sigma proof binding all ciphertexts under a single Fiat-Shamir challenge, and an aggregated Bulletproof enforcing range constraints.

17.1 Cryptographic Payload Structure (Nciphers = 4)¶

Each EC–ElGamal ciphertext contains two compressed curve points, giving 66 bytes per ciphertext and 4 × 66 = 264 bytes in total. Two Pedersen commitments are included, one for the transfer amount m and one for the balance b, contributing 2 × 33 = 66 bytes. The compact sigma proof (ZKProof prefix) is a fixed 192 bytes regardless of recipient count, replacing the legacy shared-randomness equality proof. An aggregated Bulletproof proves that both the transfer amount and the post-spend remainder lie in [0, 2^64), though transactors cap accepted amounts at maxMPTokenAmount (2^63 − 1); for two aggregated 64-bit values, the proof size is 754 bytes. The ZKProof field therefore carries 192 + 754 = 946 bytes total. Combining all components:

Total crypto size = 264 bytes (ciphertexts) + 66 bytes (Pedersen commitments) + 946 bytes (ZKProof: 192-byte compact sigma proof + 754 aggregated Bulletproof) = 1276 bytes (with auditor). Without auditor (Nciphers = 3): 198 + 66 + 946 = 1210 bytes. Ledger metadata and transaction headers are excluded from this estimate, as the goal is to isolate the cryptographic overhead.

17.2 Timing and Computational Complexity¶

To provide an empirical reference point, we include benchmark results from the reference implementation using aggregated Bulletproofs with two 64-bit values (m = 2). The measured proof size is 754 bytes. On a laptop-class CPU, aggregated Bulletproof proving time was approximately 44.8 ms, while single verification required about 22.6 ms. Averaged across five runs, verification time was approximately 19.6 ms. These measurements include transcript generation, inner-product argument processing, and multi-scalar multiplication steps. The compact sigma proof introduces only a small additional overhead compared to Bulletproof verification, as it consists of a fixed number of scalar multiplications and curve additions independent of the number of recipients. Ledger execution following proof validation performs deterministic homomorphic ciphertext updates and version checks, which add negligible computational overhead relative to proof verification.

These timings are provided as implementation reference values rather than protocol guarantees. Actual performance depends on hardware, software optimization, and batching strategies. The dominant computational cost remains aggregated Bulletproof verification, which scales logarithmically with the bit length of the proved range.

Appendix¶

Appendix A: FAQ¶

This section addresses common questions about Confidential MPTs and their design choices, ranging from basic functionality to advanced research topics.

A.1 Can confidential and public balances coexist?¶

Yes, both issuers and holders may simultaneously maintain both public and confidential balances of the same MPT, fully supporting hybrid ecosystems with explicit conversions between the two using ConfidentialMPTConvert transactions.

A.2 Why introduce a separate Merge transaction?¶

A separate Merge transaction is introduced because incoming transfers could cause proofs to become stale if all balances were in a single field, while split balances (CB_S and CB_IN) isolate proofs to a stable spending balance, allowing the Merge transaction to consolidate funds deterministically and update the version counter without requiring a proof, making it cheap to validate.

A.3 What happens if a user forgets to merge their inbox?¶

If a user forgets to merge their inbox, incoming funds will accumulate in CB_IN, remaining safe but unable to be spent until they are consolidated into CB_S via a merge, therefore wallets are expected to perform this merge before a send if necessary.

A.4 Can confidential transactions be used in DEX, escrow, or checks?¶

No, this version of confidential MPT extensions focuses solely on regular confidential MPT payments between accounts, as integration with XRPL’s DEX, escrow, or checks would require further research into how to represent offers or locked balances without revealing their amounts.

A.5 How does compliance fit in?¶

Compliance is supported by storing each confidential balance as parallel ciphertexts under the holder’s key (CB_S/CB_IN), the issuer’s key (sfIssuerEncryptedBalance), and an optional auditor’s key (sfAuditorEncryptedBalance) if enabled, with ZKPs ensuring all ciphertexts encrypt the same value, allowing the public to verify supply limits via issuer ciphertexts and auditors to decrypt balances if permitted.

A.6 What happens if a holder loses their ElGamal private key?¶

If a holder loses their ElGamal private key, they will be unable to decrypt or spend their confidential balances, which will remain valid on-ledger but are effectively locked and irrecoverable by that holder.

A.7 What prevents replay or proof reuse?¶

Replay and proof reuse are prevented because all ZKPs are transcript-bound with domain separation, meaning the binding includes transaction type, issuer, currency, and version counters, so attempting to replay a proof in another context will result in a failed verification.

A.8 Are confidential transactions more expensive than standard MPT transactions?¶

Yes, confidential transactions are more expensive than standard MPT transactions as they include extra ciphertexts and ZKPs, which increase both transaction size and verification cost, though efficiency remains a design goal with lightweight proofs and future aggregation possibilities.

A.9 What happens if validators cannot verify a ZKP?¶

If validators cannot verify a ZKP, the transaction is rejected during consensus, functioning identically to an invalid signature and thus preventing malformed or incorrect confidential balances from entering the ledger.

A.10 Why can't the issuer account hold confidential balances of its own MPT Issuance?¶

The issuer account has a special role on the ledger: its balance is excluded from OutstandingAmount to preserve the XLS-33 accounting invariant. Allowing the issuer to hold confidential balances directly would break this invariant, since COA and OA would need to account for the issuer's hidden balance. Instead, an issuer that wishes to participate in confidential circulation uses an optional dedicated holder account (Confidential Vault), which is treated as a standard non-issuer holder. Its confidential balance is included in both OA and COA, keeping all accounting consistent and validators able to enforce OA ≤ MaximumAmount without decryption. (See §14.1 for the full rationale.)

A.11 Will proofs be optimized in future versions?¶

The original design employed separate range and equality proofs for each transaction. This has been superseded by the compact sigma proof construction, which replaces the separate sigma proofs with a single fixed-size proof per transaction type, reducing the ConfidentialMPTSend sigma component from ~619 bytes to 192 bytes (a 27% reduction in total transaction size). Further optimizations to range proof aggregation or batched verification may be explored in future versions. (See §14.6 for the full rationale.)

A.12 Can there be more than one auditor?¶

At present, the protocol supports only a single optional auditor. Future extensions could explore multi-auditor setups, potentially leveraging advanced cryptographic techniques such as threshold encryption or more sophisticated policy-driven key distribution mechanisms.

A.13 Is the system quantum-safe?¶

Today's design relies on EC-ElGamal over secp256k1, which is not considered quantum-safe. The long-term plan includes migrating to post-quantum friendly schemes, such as those based on lattice cryptography. The specific migration path and timeline for achieving quantum resistance remain an open area of research.

A.14 Why require explicit Merge instead of eliminating it in future?¶

The explicit MergeInbox transaction is currently required because it deterministically solves the issue of "staleness," ensuring that all received funds are consolidated before spending. While issuers and wallets might prefer less operational overhead, the current design offers clear, verifiable guarantees. Future designs may revisit whether we can eliminate this explicit merge requirement.

Acknowledgements¶

We would like to thank David Schwartz, Ayo Akinyele, Kenny Lei, Shashwat Mittal, Shawn Xie, Yinyi Qian, and Peter Chen for their invaluable feedback and insightful discussions which improved this specification.

← Back to All Standards View on GitHub

Confidential Transfers for Multi-Purpose Tokens¶

1. Abstract¶

2. Motivation¶

2.1 Benefits¶

3. Definitions & Terminology¶

4. Scope¶

4.1 New Transaction Types¶

5. Protocol Overview¶

5.1 The Dedicated Account Model¶

5.2 The Split-Balance Model¶

5.3 The Multi-Ciphertext Architecture¶

5.4. Proof System¶

5.5. Delegate Accounts¶

6. Ledger Entry: MPTokenIssuance¶

6.1. Fields¶

6.2. Flags¶

6.3. Managing Confidentiality Settings¶

6.3.1. Mutability & Defaults¶

6.3.2. Enabling Confidentiality¶

6.3.3. Disabling Confidentiality¶

6.4. Transfer Fee Compatibility¶

6.5. Deletion¶

6.6. Invariants¶

6.7. Example JSON¶

7. Ledger Entry: MPToken¶

7.1. Fields¶

7.2. Deletion¶

7.3. Invariants¶

7.4. Example JSON¶

8. Transaction: ConfidentialMPTConvert¶

8.1 Use Cases¶

8.2 Fields¶

8.3. Transaction Fee¶

8.4. Failure Conditions¶

8.4.1. Data Verification¶

8.4.2. Protocol-Level Failures¶

8.5. State Changes¶

8.6 Example JSON¶

9. Transaction: ConfidentialMPTSend¶

9.1 Use Cases¶

9.2. Fields¶

9.3. Transaction Fee¶

9.4. Failure Conditions¶

9.4.1. Data Verification¶

9.4.2. Protocol-Level Failures¶

9.3.2.1. Authorization Failures¶

9.5. State Changes¶

9.6. Example JSON¶

10. Transaction: ConfidentialMPTMergeInbox¶

10.1 Use Cases¶

10.2 Fields¶

10.3. Transaction Fee¶

10.4. Failure Conditions¶

10.4.1. Data Verification¶

10.4.2. Protocol-Level Failures¶

10.5. State Changes¶

10.6. Example JSON¶

11. Transaction: ConfidentialMPTConvertBack¶

11.1 Purpose: Convert confidential into public MPT value.¶

11.2 Account Effects¶

11.3. Fields¶

11.4. Transaction Fee¶

11.5. Failure Conditions¶

11.5.1. Data Verification¶

11.5.2. Protocol-Level Failures¶

11.6. State Changes¶

11.7. Example JSON¶

11.8. Edge Case Analysis (Low-Volume Transaction Flow):¶

11.8.1 What Outsiders can Infer:¶

11.8.2 Why no exact leakage:¶

12. Transaction: ConfidentialMPTClawback¶

12.1 How the Clawback Process Works¶

12.2. Fields¶

12.3. Transaction Fee¶

12.4. Failure Conditions¶

12.4.1. Data Verification¶

12.4.2. Protocol-Level Failures¶

12.5. State Changes¶

12.6. Example JSON¶

13. Transaction: MPTokenIssuanceSet¶

6. Ledger Entry: `MPTokenIssuance`¶

7. Ledger Entry: `MPToken`¶

8. Transaction: `ConfidentialMPTConvert`¶

9. Transaction: `ConfidentialMPTSend`¶

10. Transaction: `ConfidentialMPTMergeInbox`¶

11. Transaction: `ConfidentialMPTConvertBack`¶

12. Transaction: `ConfidentialMPTClawback`¶

13. Transaction: `MPTokenIssuanceSet`¶