Neufassung von XLS-87: MPT-Emittenten sollen Inhaber vorab freigeben und Konten sperren können

Serguey Asael Shinder15 October 2026, 06:562 Min. Lesezeit

Im Repository XRPL-Standards schlägt ein am 13. Oktober 2026 eröffneter Pull-Request eine schmalere erste Fassung von XLS-87 vor, dem Entwurf zur Vorab-Autorisierung von Token. Er wurde am 14. Oktober aktualisiert, ist noch offen, und die Spezifikation hat weiterhin den Status Draft; die genannten Autoren arbeiten bei Ripple.

Das beschriebene Problem. Emittenten eines Multi-Purpose Token (MPT) mit Autorisierungspflicht müssen heute für jeden zugelassenen Inhaber eine eigene Transaktion signieren – im großen Maßstab unpraktisch und schwer vereinbar mit Schlüsseln im Cold Storage. Bei erlaubnisfreien MPTs ist es umgekehrt: Jedes Konto kann sich sofort eintragen und den Token empfangen, und die vorhandenen Mittel – Sperre einzelner Inhaber, globale Sperre und Clawback – greifen erst bei einem bereits bestehenden Bestand. Ein Konto, das der Emittent nicht bedienen darf, kann also Mittel erhalten, bevor er reagiert; als Beispiel nennt der Entwurf Sanktionsregeln.

Zwei neue Ledger-Einträge. Nach dem Vorbild von DepositPreauth gehören beide dem Emittenten, sind nach Inhaber und MPTokenIssuanceID geschlüsselt und werden über eine gleichnamige Transaktion verwaltet:

• TokenPreauth gibt einen Inhaber vorab frei: Bei einer Emission mit RequireAuth genügt dann dessen eigenes MPTokenAuthorize, eine zweite Transaktion des Emittenten entfällt.
• TokenBlock verhindert, dass ein Konto auf irgendeinem Weg einen Bestand des Tokens erhält – über MPTokenAuthorize oder implizit über Zahlungen, die DEX, Checks, Escrow, AMM und Vault. Hält das Konto den Token bereits, wird die Autorisierung entzogen, der Bestand aber nicht eingefroren; dafür bleibt eine separate Sperre nötig. Ein neuer Ergebniscode, tecTOKEN_BLOCKED, meldet die Ablehnung.

Grenzen. Eine Sperre gilt nur für eine Emission und nie für alle Token eines Emittenten; ein gesperrtes Konto kann XRP und alle anderen Token weiter nutzen. Ein Inhaber kann für dieselbe Emission nie gleichzeitig freigegeben und gesperrt sein. IOUs, Freigaben per Credential (XLS-70) oder Domain (XLS-80) und Sperren für Deposit Authorization bleiben späteren Amendments vorbehalten. Nötig wäre ein Amendment mit dem vorläufigen Namen TokenPreauth.

Quelle: XRPL-Standards, Pull-Request #660 „XLS-87: Revise Token Pre-Authorization as MPT-only TokenPreauth and TokenBlock“ — https://github.com/XRPLF/XRPL-Standards/pull/660