Zum Inhalt springen
In EntwicklungTier ADeFi & DEX

MPTokensV2 XLS-82

Multi-Purpose Tokens sollen im nativen DEX direkt handelbar werden. MPTokensV2 ist laut xrpl.org in Entwicklung und noch nicht als Mainnet-Abstimmung gelistet. Eine stabile rippled-Version und die Validatorabstimmung stehen noch aus.

Fachlich geprüft am 31.07.2026 · Autor: Philip F. Schmitt

Status
In Entwicklung
XLS
XLS-82
Version
Offen
Aktiviert
Keine Angabe

Was ist der Entwicklungsstand?

Warum wird diese Funktion entwickelt?

MPTokensV1 stellt den Token-Typ bereit, aber noch keine vollständige Nutzung in den nativen Handels- und Liquiditätswegen.

Wie soll der Mechanismus funktionieren?

MPTokensV2 lässt bestehende DEX-, Payment-, Check- und AMM-Transaktionen einen MPT über mpt_issuance_id referenzieren. Neue Transaktionsfelder oder Ledger-Objekte entstehen dafür nicht. Bei jedem Handel prüft der Ledger Autorisierung sowie CanTransfer, CanTrade und Lock-Status der Ausgabe und des Halters.

Was fehlt bis zum Mainnet?

Nach Implementierung und Tests muss die Änderung in einer stabilen rippled-Version erscheinen. Erst dann kann die Mainnet-Abstimmung beginnen.

Was ändert sich gegenüber dem Vorgänger?

VorherNachher
MPTokensV1 erlaubt direkte MPT-Zahlungen, isoliert MPTs aber von Orderbüchern, Cross-Currency-Pfaden, Checks und AMMs.MPTs können mit XRP, Trustline-Token oder anderen MPTs in den vorhandenen Liquiditätswegen kombiniert werden.

Für wen ist die Änderung relevant?

XRP-Halter und Nutzer

Nach Aktivierung könnten Halter MPTs direkt über Orderbücher und Pools handeln. Die Emittentenrechte der Ausgabe gelten dabei auch im DEX.

Wallets und App-Entwickler

DEX- und Zahlungssoftware muss mpt_issuance_id in allen Asset- und Amount-Varianten, Pfaden und API-Antworten verarbeiten.

Börsen und Emittenten

Emittenten können native Märkte für MPTs aufbauen, müssen dafür CanTrade und für Transfers zwischen Haltern auch CanTransfer aktivieren.

Node-Betreiber

Nodes erweitern die vorhandene DEX-Engine um MPT-Prüfungen und die MPT-Variante von STIssue, ohne eine zweite Handelsengine einzuführen.

Welche Grenzen und Risiken bleiben?

  • Das Amendment ist als Draft in Entwicklung und noch keine Mainnet-Funktion.
  • MPTs unterstützen kein Payment-Rippling über gegenseitige Salden wie Trustlines.
  • Handel scheitert oder wird aus dem Orderbuch entfernt, wenn CanTrade, CanTransfer, Autorisierung oder Lock-Status nicht passen.
  • Die MPT-Betragsgrenze aus XLS-33 bleibt bestehen.
  • Der Draft enthält bei tecOBJECT_NO_FOUND eine abweichende Schreibweise neben tecOBJECT_NOT_FOUND. Die Seite übernimmt beide Spec-Bezeichnungen und glättet sie nicht stillschweigend.
  • Spezifikation und Implementierung können sich bis zu einer stabilen rippled-Version ändern.
Technische Details: Transaktionen, Felder, Codes und Invarianten

Transaktionen

  • AMMCreate
  • AMMDeposit
  • AMMWithdraw
  • AMMDelete
  • AMMClawback
  • CheckCreate
  • CheckCash
  • OfferCreate
  • Payment

Ledger-Objekte

  • MPTokenIssuance
  • MPToken
  • Offer
  • AMM
  • Check

Felder und Flags

  • mpt_issuance_id in Amount und Asset
  • Amount / Amount2
  • Asset / Asset2
  • TakerGets / TakerPays
  • SendMax / DeliverMin / Paths
  • lsfMPTAMM 0x00000004
  • lsfMPTCanTrade
  • lsfMPTCanTransfer
  • lsfMPTRequireAuth

API-Methoden

  • path_find
  • ripple_path_find
  • amm_info
  • book_offers

Ergebnis-Codes

  • temDISABLED
  • tecOBJECT_NOT_FOUND / tecOBJECT_NO_FOUND
  • tecNO_AUTH
  • tecNO_PERMISSION
  • tecFROZEN
  • tecPATH_DRY
  • tecPATH_PARTIAL
  • tecUNFUNDED_OFFER
  • terNO_AMM

Wie hängt dieses Amendment mit anderen zusammen?

Jede direkte Verbindung besitzt einen Typ, eine Erklärung und eine Primärquelle.

Wie geht es mit diesem Amendment weiter?

MPTokensV2 ist laut xrpl.org in Entwicklung und noch nicht als Mainnet-Abstimmung gelistet. Eine stabile rippled-Version und die Validatorabstimmung stehen noch aus.

Nach Implementierung und Tests muss die Änderung in einer stabilen rippled-Version erscheinen. Erst dann kann die Mainnet-Abstimmung beginnen.

Wo steht es in seiner Amendment-Familie?

AMM und Clawback: Protokollfolge

  1. AMMAktiviert · ab rippled 1.12.0
  2. ClawbackAktiviert · ab rippled 1.12.0
  3. fixInnerObjTemplateAktiviert · ab rippled 2.1.0
  4. fixAMMOverflowOfferAktiviert · ab rippled 2.1.1
  5. fixPreviousTxnIDAktiviert · ab rippled 2.2.0
  6. fixAMMv1_1Aktiviert · ab rippled 2.2.0
  7. fixInnerObjTemplate2Aktiviert · ab rippled 2.3.0
  8. fixAMMv1_2Aktiviert · ab rippled 2.3.0
  9. AMMClawbackAktiviert · ab rippled 2.3.0
  10. fixFrozenLPTokenTransferAktiviert · ab rippled 2.4.0
  11. DeepFreezeAktiviert · ab rippled 2.4.0
  12. fixAMMv1_3Aktiviert · ab rippled 2.5.0
  13. fixAMMClawbackRoundingAktiviert · ab rippled 3.0.0
  14. MPTokensV2In Entwicklung

Welche Primärquellen belegen die Angaben?

← Alle XRPL-Amendments und XLS-Spezifikationen