Zum Inhalt springen
In AbstimmungTier AToken

DynamicMPT XLS-94

Emittenten können Metadaten, TransferFee und bestimmte Fähigkeiten einer MPT-Ausgabe nachträglich ändern oder dauerhaft festschreiben. DynamicMPT ist auf dem Mainnet offen, aber noch nicht aktiviert. Aktuell melden 14 von 35 erfassten Validatoren Unterstützung.

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

Status
In Abstimmung
XLS
XLS-94
Aktiviert
Keine Angabe

Wie steht die Mainnet-Abstimmung?

14 von 35 Ja-Stimmen, benötigt: 28 (aktuell 40 %, Ziel 80 %)

Was ändert dieses Amendment?

Warum gibt es dieses Amendment?

Emittenten brauchen für einzelne MPT-Eigenschaften kontrollierte Aktualisierbarkeit, ohne alle bei der Ausgabe gesetzten Merkmale nachträglich öffnen zu müssen.

Wie funktioniert der Mechanismus?

Ohne ImmutableFlags bleiben MPTokenMetadata und TransferFee einer Ausgabe änderbar, und Fähigkeitsflags wie CanLock, CanEscrow, CanTrade, CanTransfer oder CanClawback lassen sich später einmalig einschalten. MPTokenIssuanceCreate oder MPTokenIssuanceSet können über ImmutableFlags einzelne Felder oder Flags dauerhaft sperren, neue Bits kommen nur hinzu und werden nie gelöscht. Eingeschaltete Fähigkeitsflags lassen sich per MPTokenIssuanceSet nicht wieder abschalten.

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

VorherNachher
Felder und Verhaltensflags einer MPT-Ausgabe waren nach der Erstellung grundsätzlich unveränderlich.Metadaten und TransferFee bleiben änderbar und Fähigkeitsflags lassen sich nachträglich einschalten, bis der Emittent die jeweilige Eigenschaft über ImmutableFlags dauerhaft festschreibt.

Für wen ist die Änderung relevant?

XRP-Halter und Nutzer

Ohne gesetzte ImmutableFlags kann der Emittent Metadaten und TransferFee ändern sowie Rechte wie Clawback oder RequireAuth nachträglich einschalten. Vor dem Erwerb sollte sichtbar sein, welche Eigenschaften bereits festgeschrieben sind.

Wallets und App-Entwickler

Wallets und Explorer stellen aktive Flags und ImmutableFlags getrennt dar und verfolgen Änderungen an Metadaten oder TransferFee.

Börsen und Emittenten

Emittenten behalten standardmäßig Spielraum für spätere Anpassungen und können Haltern verbindliche Zusagen geben, indem sie einzelne Eigenschaften dauerhaft sperren.

Node-Betreiber

Nodes prüfen Bitmasken, Emittentenberechtigung, Größen- und Gebührenlimits und lehnen jede Änderung an bereits festgeschriebenen Eigenschaften ab.

Welche Grenzen und Risiken bleiben?

  • Ein Bit in ImmutableFlags lässt sich nach dem Setzen nicht mehr entfernen.
  • Eingeschaltete Fähigkeitsflags sind eine Einbahnstraße und können mit MPTokenIssuanceSet nicht wieder deaktiviert werden.
  • MPTokenMetadata ist auf 1.024 Byte und TransferFee auf 50.000 Einheiten begrenzt.
  • Eine TransferFee über null setzt voraus, dass CanTransfer bereits aktiv ist oder in derselben Transaktion eingeschaltet wird.
  • Bei MPT-Ausgaben mit vertraulichen Salden muss die TransferFee null bleiben.
  • MPTokenHolder sowie tfMPTLock und tfMPTUnlock lassen sich nicht mit diesen Änderungen in einer Transaktion kombinieren.
Technische Details: Transaktionen, Felder, Codes und Invarianten

Transaktionen

  • MPTokenIssuanceCreate
  • MPTokenIssuanceSet

Ledger-Objekte

  • MPTokenIssuance

Felder und Flags

  • ImmutableFlags
  • MPTokenMetadata
  • TransferFee
  • tifMPTCanLock bis tifMPTCanClawback 0x00000002 bis 0x00000040
  • tifMPTCanHoldConfidentialBalance 0x00000080
  • tifMPTMetadata 0x00010000
  • tifMPTTransferFee 0x00020000
  • tfMPTSetCanLock bis tfMPTSetCanClawback 0x00000004 bis 0x00000080
  • tfMPTSetCanHoldConfidentialBalance 0x00000100

Ergebnis-Codes

  • temINVALID_FLAG
  • temDISABLED
  • temMALFORMED
  • temBAD_TRANSFER_FEE
  • tecOBJECT_NOT_FOUND
  • tecNO_PERMISSION

Invarianten

  • Ein gesetztes ImmutableFlags-Bit wird nie gelöscht, und die zugehörige Eigenschaft ändert sich danach nicht mehr.

Wie sieht ein konkreter Ablauf aus?

Ein Emittent legt eine MPT-Ausgabe ohne ImmutableFlags an und aktualisiert später die Metadaten. Danach setzt er tifMPTMetadata, und der Ledger weist jede weitere Metadaten-Änderung mit tecNO_PERMISSION ab.

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?

DynamicMPT ist auf dem Mainnet offen, aber noch nicht aktiviert. Aktuell melden 14 von 35 erfassten Validatoren Unterstützung.

Für die Aktivierung muss die Unterstützung mindestens 80 Prozent erreichen und zwei Wochen ununterbrochen oberhalb dieser Schwelle bleiben.

Wo steht es in seiner Amendment-Familie?

Multi-Purpose Tokens: Protokollfolge

  1. DeletableAccountsAktiviert · ab rippled 1.4.0
  2. TicketBatchAktiviert · ab rippled 1.7.0
  3. DisallowIncomingAktiviert · ab rippled 1.10.0
  4. fixDisallowIncomingV1Aktiviert · ab rippled 2.0.0
  5. MPTokensV1Aktiviert · ab rippled 2.3.0
  6. PermissionedDEXAktiviert · ab rippled 2.5.0
  7. TokenEscrowAktiviert · ab rippled 2.5.0
  8. PermissionDelegationVeraltet · ab rippled 2.5.0
  9. fixTokenEscrowV1Aktiviert · ab rippled 3.0.0
  10. fixMPTDeliveredAmountAktiviert · ab rippled 3.0.0
  11. fixCleanup3_2_0Aktiviert · ab rippled 3.2.0
  12. ConfidentialTransferIn Abstimmung · ab rippled 3.3.0
  13. DynamicMPTIn Abstimmung · ab rippled 3.3.0
  14. PermissionDelegationV1_1In Abstimmung · ab rippled 3.3.0
  15. SponsorIn Abstimmung · ab rippled 3.3.0
  16. fixCleanup3_4_0In Abstimmung · ab rippled 3.4.0
  17. MPTokensV2In Entwicklung

Welche Primärquellen belegen die Angaben?

← Alle XRPL-Amendments und XLS-Spezifikationen