Skip to content

Update XLS-0082 to match latest implementation - #615

Open
gregtatcam wants to merge 61 commits into
XRPLF:masterfrom
gregtatcam:master
Open

gregtatcam wants to merge 61 commits into
XRPLF:masterfrom
gregtatcam:master

Conversation

@gregtatcam

Copy link
Copy Markdown
Collaborator

High Level Overview of Change

Update XLS-0082 to match latest implementation

Type of Change

  • New XLS Draft
  • XLS Update (changes to an existing XLS)
  • XLS Status Change (e.g., Draft → Final, Draft → Stagnant)
  • Process/Meta (changes to CONTRIBUTING.md, XLS-1, templates, etc.)
  • Infrastructure (CI, workflows, scripts, website)
  • Documentation (README updates, typo fixes)

gregtatcam and others added 30 commits September 28, 2023 10:36
Co-authored-by: David Fuelling <sappenin@gmail.com>
Co-authored-by: Mayukha Vadari <mvadari@gmail.com>
* Rename SymbolClass
* Rename SymbolPrice
* Rename CURRENCY type
* Rename Set/DeleteOracle transaction
* Add appendix to describe STI_ASSET_TYPE
* Change LastUpdateTime to Unix Time
* Change average to mean
* Add XRP to supported in STI_CURRENCY
* Fix typos
* Remove references to OracleID
* Correct validation for URI and Provider to 32 bytes
* Update OracleSet description
* Reformat transactions and API sections to one table followed by description
* Move JSON examples in transactions and API sections before the tables
Co-authored-by: Mayukha Vadari <mvadari@gmail.com>
* Store LastUpdateTime as Unix Time
* Add comment for decoded hex value
* Remove TBD for tx int value
* Update ledger_entry JSON request
gregtatcam and others added 27 commits February 11, 2026 10:45
Co-authored-by: Mayukha Vadari <mvadari@gmail.com>
Co-authored-by: Mayukha Vadari <mvadari@gmail.com>
Co-authored-by: Mayukha Vadari <mvadari@gmail.com>
Co-authored-by: Mayukha Vadari <mvadari@gmail.com>
Add relevant ledger entry sections and elaborate on RPC added subfields.
Co-authored-by: Mayukha Vadari <mvadari@gmail.com>
Co-authored-by: Mayukha Vadari <mvadari@gmail.com>
Co-authored-by: Mayukha Vadari <mvadari@gmail.com>
Co-authored-by: Mayukha Vadari <mvadari@gmail.com>
Co-authored-by: Mayukha Vadari <mvadari@gmail.com>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🟡 Changes recommended

The updated spec contains at least one correctness issue (MPT value range/type wording) and a template-compliance issue (missing “Security Considerations” section title), both of which should be fixed before approval.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Updates the XLS-0082 (MPT Integration into DEX) specification so its amendment name, transaction semantics, and failure conditions align with the latest implementation behavior.

Changes:

  • Renames/standardizes the amendment name to MPTokensV2 and updates transaction gating language accordingly.
  • Expands DEX/AMM transaction coverage and semantics (notably adding AMMVote / AMMBid, and refining authorization/lock/flag behavior across AMM + DEX flows).
  • Clarifies offer crossing and payment-path behavior for locked/unauthorized MPTs, including when offers are removed from the book.
File summaries
File Description
XLS-0082-mpt-dex/README.md Updates the XLS-0082 spec text, failure conditions, and transaction/RPC sections to match current implementation behavior.
Review details

Suppressed comments (1)

XLS-0082-mpt-dex/README.md:451

  • "WeakAuth" is referenced again but still not defined anywhere in this document; consider removing the term and keeping the explicit explanation.
5. `lsfMPTRequireAuth` flag is set and the destination is not authorized, fail with `tecNO_AUTH`. A missing destination `MPToken` is allowed (WeakAuth); it is created on success.
  • Files reviewed: 1/1 changed files
  • Comments generated: 4
  • Review effort level: Lite

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

- `Payment`: A Payment transaction represents a transfer of value from one account to another.

MPT supports all of the above transactions. MPT can be combined with IOU and XRP tokens in the transactions. For instance, a Payment could be a cross-token payment from MPT token to IOU token; AMM can be created for XRP and MPT token-pair; an order book offer can be created to buy some MPT token and to sell another MPT token. MPT doesn't modify the transactions fields, flags, and functionality. However, the JSON of the MPT amount field differs from the JSON of the IOU amount field. Instead of `currency` and `issuer`, MPT is identified by `mpt_issuance_id`. MPT amount `value` is INT or UINT, which must be less or equal to $63^2 - 1$. Below are the examples of JSON MPT amount and JSON MPT asset:
MPT supports all of the above transactions. MPT can be combined with IOU and XRP tokens in the transactions. For instance, a Payment could be a cross-token payment from MPT token to IOU token; AMM can be created for XRP and MPT token-pair; an order book offer can be created to buy some MPT token and to sell another MPT token. MPT doesn't modify the transactions fields, flags, and functionality. However, the JSON of the MPT amount field differs from the JSON of the IOU amount field. Instead of `currency` and `issuer`, MPT is identified by `mpt_issuance_id`. MPT amount `value` is INT or UINT, which must be less than or equal to $2^{63} - 1$. Below are the examples of JSON MPT amount and JSON MPT asset:
```

Any transaction with MPT `Amount` or `Asset` have to use JSON format as described above. For any transaction, which uses MPT token, the token has to be created first by an issuer with `MPTokenIssuanceCreate` transaction and in most cases, except for `AMMCreate`, `AMMWithdraw`, `AMMClawback`, `CheckCash`, and `OfferCreate`, the token has to be authorized by the holder account with `MPTokenAuthorize` transaction as described in [XLS-33d](../XLS-0033d-multi-purpose-tokens/README.md). `MPTokenAuthorize` creates `MPToken` object, owned by a holder account. In addition, `MPTokenIssuanceCreate` must have the following flags set:
Any transaction with MPT `Amount` or `Asset` have to use JSON format as described above. For any transaction, which uses MPT token, the token has to be created first by an issuer with `MPTokenIssuanceCreate` transaction and in most cases, except for `AMMWithdraw`, `AMMClawback`, `CheckCash`, and `OfferCreate`, the token has to be authorized by the holder account with `MPTokenAuthorize` transaction as described in [XLS-33](../XLS-0033-multi-purpose-tokens/README.md). `AMMCreate` is not in that list: the creator must already hold an `MPToken` unless they are the issuer. `MPTokenAuthorize` creates `MPToken` object, owned by a holder account. In addition, `MPTokenIssuanceCreate` must have the following flags set for DEX and AMM participation:
6. `MPTRequireAuth` flag is set and the account is not authorized, fail with `tecNO_AUTH`.
7. `MPTCanTransfer` flag is not set and the account is not the issuer of MPT, fail with `tecNO_PERMISSION`.
8. `MPTCanTrade` flag is not set, fail with `tecNO_PERMISSION`.
Lock, `lsfMPTCanTrade`, and `lsfMPTCanTransfer` checks apply to both pool assets even on a single-asset deposit. A missing `MPToken` is tolerated for a pool asset that is not being deposited (WeakAuth). The strong existence check applies only to assets named in `Amount`/`Amount2`, or to both pool balances under `tfLPToken`. A missing AMM instance fails with `terNO_AMM`.
Furthermore, the design prioritizes a unified liquidity model where the ledger's pathfinding logic treats MPTs and IOUs as functionally equivalent nodes. While MPTs use a unique mpt_issuance_id for technical precision, the underlying economic logic—such as cross-currency payments and order book mechanics—remains consistent. This prevents a fragmented developer experience where two different "flavors" of trading would need to be maintained. By choosing to wrap the new functionality within the ledger’s battle-tested DEX primitives, the XLS provides a robust and secure migration path, allowing institutions to adopt the more efficient MPT standard without losing access to the global liquidity and mature tooling that the XRP Ledger has cultivated over the past decade.

## 16. Security
## 18. Security

This branch has not been deployed

No deployments
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.

4 participants