Skip to content

Conversation

@mrtcnk
Copy link

@mrtcnk mrtcnk commented Feb 10, 2026

Draft XLS for Confidential Multi-Purpose Tokens.
This brings the spec closer to the current implementation; follow-up PRs may address naming and minor discrepancies.

author: Murat Cenk <[email protected]>, Aanchal Malhotra <[email protected]>, Ayo Akinyele <[email protected]>
status: Ongoing
category: Amendment
created: Jan 15, 2026
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
created: Jan 15, 2026
created: 2026-01-15

description: This amendment introduces Confidential Multi-Purpose Tokens (MPTs) on the XRP Ledger.
author: Murat Cenk <[email protected]>, Aanchal Malhotra <[email protected]>, Ayo Akinyele <[email protected]>
status: Ongoing
category: Amendment
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
category: Amendment
category: Amendment
requires: XLS-33

@@ -0,0 +1,862 @@
<pre>
title: Confidential Multi-Purpose Tokens for XRPL
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

title:  Confidential Multi-Purpose Tokens

created: Jan 15, 2026
</pre>

# Confidential Multi-Purpose Tokens for XRPL
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confidential Multi-Purpose Tokens


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

### 3.2.1 New Flags:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The flags should be declared and defined where they're used.

- lsfMPTCanPrivacy: If set, indicates that confidential transfers and conversions are enabled for this token issuance.
- lsmfMPTCannotMutatePrivacy: If set, the lsfMPTCanPrivacy flag can never be changed after the token is issued, permanently locking the confidentiality setting.

### 3.2.3 New Fields:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New fields should be declared and defined where they're used.


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

### 11.1. New Fields
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### 11.1. New Fields
### 11.1. Fields

| `IssuerElGamalPublicKey` | The 33-byte EC-ElGamal public key used for the issuer's mirror balances. |
| `AuditorElGamalPublicKey` | The 33-byte EC-ElGamal public key used for regulatory oversight (if applicable). |

### 11.2. Usage & Mutability
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be moved before fields.


- **Flags:** The `lsfMPTCanPrivacy` flag is updated (if mutable).
- **Keys:** The `sfIssuerElGamalPublicKey` and/or `sfAuditorElGamalPublicKey` are stored on the `MPTokenIssuance` ledger entry.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add an example JSON please.


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

### Proof Requirements
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please add subsection indexes. E.g. 14.1., 14.2., etc.


Bulletproofs are an efficient choice. Even when reducing the bit length, the decomposition approach results in a transaction payload that is over 6 times larger than a Bulletproof.

## 16. Frequently Asked Questions (FAQ)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The FAQ should go into the appendix:

# Appendix _(Optional)_

## Appendix A: FAQ _(Optional)_

_[A list of questions the author expects to be asked about the spec, and their answers. It is highly recommended but not required to include this section, to make it easier for spec readers to understand it.]_

### A.1: [Question]

_[Answer to the question]_

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

@Tapanito
Copy link
Collaborator

Thank you for rewriting the specification @mrtcnk , it's in a much better state. I left some editorial comments, once they've been addressed, I'll do a technical review of the transactors.

@github-actions
Copy link

github-actions bot commented Feb 11, 2026

🎫 XLS Number Assignment

This PR adds a new XLS draft. The next available XLS number has been determined:

Draft Directory Assigned Number New Directory Name
xls-draft-confidential-mpt XLS-96 xls-0096-confidential-mpt

Next Steps for XLS Editors

Before merging this PR, please:

  1. Rename the directory from xls-draft-confidential-mpt to xls-0096-confidential-mpt
  2. Update the preamble in the README.md:
    • Set xls: to 96
    • Set status: to Draft

This comment was automatically generated. The XLS number is based on the highest existing number in the repository at the time this PR was opened.

@mvadari
Copy link
Collaborator

mvadari commented Feb 11, 2026

@mrtcnk you can now update the XLS number based on the bot's comment 🙂

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

- **Plaintext–ciphertext equality proofs:** Prove that a publicly known amount `m` is correctly encrypted.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I recommend removing the spaces between these bullets for consistency/readability (same with in the other sections)

@@ -0,0 +1,865 @@
<pre>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please rename the folder as per the bot comment

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in the latest push.

@mrtcnk
Copy link
Author

mrtcnk commented Feb 13, 2026

Thank you for the detailed review @Tapanito @mvadari . The comments have been addressed and updates have been pushed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants