Zum Inhalt springen
Kein Netzwerk-AmendmentTier BKommende StandardsSpec: Draft

Subscriptions XLS-78

Ein Draft für vorautorisierte, wiederkehrende Abrufe von XRP, IOUs oder MPTs mit Betrags- und Zeitgrenzen. Das ist ein Vorschlag, kein aktives Netzwerk-Feature. Was davon kommt und wann, ist offen.

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

Netzwerkstatus
Kein Netzwerk-Amendment
XLS
XLS-78
Spec-Status
Draft
Spec-Stand
10.09.2025

Was schlägt diese XLS vor?

Welches Problem soll der Vorschlag lösen?

Wiederkehrende Zahlungen benötigen heute für jeden Termin eine neue Signatur des Senders oder eine externe Verwahrungslösung. Dienste können deshalb keine eng begrenzte On-Ledger-Abrufberechtigung erhalten.

Wie ist der Mechanismus im aktuellen Draft gedacht?

SubscriptionSet legt ein reservepflichtiges Subscription-Objekt mit SendMax, Frequency, NextClaimTime und optionaler Expiration an. SubscriptionClaim erlaubt dem Ziel genau einen begrenzten Abruf pro Periode und wendet dabei aktuelle Trustline-TransferRate oder MPT-TransferFee an. Beide Parteien dürfen über SubscriptionCancel beenden; Ziel, Frequenz und Startzeit bleiben nach der Erstellung unveränderlich.

Wie verbindlich ist das?

Das ist ein Vorschlag, kein aktives Netzwerk-Feature. Was davon kommt und wann, ist offen.

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

VorherNachher
Jede wiederkehrende Zahlung musste vom Sender neu signiert oder außerhalb des Ledgers automatisiert werden.Ein Ziel könnte innerhalb eines vorab genehmigten Betrags und Zeitfensters selbst XRP oder Token aus dem Senderkonto abrufen.

Für wen ist die Änderung relevant?

XRP-Halter und Nutzer

Zahler behalten eine Obergrenze pro Periode und können jederzeit kündigen. Ein berechtigtes Ziel darf den Betrag aber ohne neue Einzelbestätigung abrufen.

Wallets und App-Entwickler

Wallets müssen Mandatsparameter, Restbetrag der Periode, nächste Abrufzeit, Rückstände und aktuelle Tokengebühren nachvollziehbar anzeigen.

Börsen und Emittenten

Dienste könnten regelmäßige oder variable Beträge einziehen. Freeze, Autorisierung, MPT-Lock und heutige Transfergebühren bleiben bei jedem Claim wirksam.

Node-Betreiber

Nodes prüfen Zeitfenster, Periodensaldo und Assetregeln und können beim ersten Claim eine Trustline oder ein MPToken-Objekt anlegen, sofern Reserve und Autorisierung reichen.

Welche Grenzen und Risiken bleiben?

  • XLS-78 ist ein Draft und noch kein aktives Lastschriftverfahren.
  • Pro Claim wird höchstens eine Periode verarbeitet. Verpasste Perioden lassen sich nur durch mehrere Claims aufholen.
  • Nicht genutzter Rest einer vergangenen Periode verfällt beim Wechsel in die nächste Periode und sammelt sich nicht unbegrenzt an.
  • Destination, Frequency und StartTime lassen sich nicht aktualisieren. Dafür muss das Abo beendet und neu erstellt werden.
  • Eine direkte Pause ist nicht vorgesehen.
  • Aktuelle TransferRate oder TransferFee gilt zum Claim-Zeitpunkt und ist nicht bei Erstellung festgeschrieben.
  • Ein Dienst kann bis zur genehmigten Grenze abrufen. Ob der Abruf wirtschaftlich berechtigt ist, prüft der Ledger nicht.

Welche Gebühren- und Performancewerte nennt die Spec?

  • Das Subscription-Objekt bindet eine Owner-Reserve beim Zahler.
  • Automatisch angelegte Trustlines oder MPToken-Objekte können beim Ziel zusätzliche Reserve erfordern.
Technische Details: Transaktionen, Felder, Codes und Invarianten

Transaktionen

  • SubscriptionSet
  • SubscriptionCancel
  • SubscriptionClaim

Ledger-Objekte

  • Subscription (LedgerEntryType und Key Space 0x0055)
  • RippleState
  • MPToken

Felder und Flags

  • SubscriptionID / Owner / Destination / DestinationTag
  • SendMax / Balance
  • Frequency (mindestens 3.600 Sekunden)
  • StartTime / NextClaimTime / Expiration

Ergebnis-Codes

  • temDST_IS_SRC / temBAD_AMOUNT / temBAD_EXPIRATION / temBAD_CURRENCY
  • tecNO_DST / tecDST_TAG_NEEDED / tecNO_ENTRY / tecNO_PERMISSION
  • tecNO_ISSUER / tecNO_LINE / tecNO_AUTH
  • tecFROZEN / tecLOCKED / tecWRONG_ASSET
  • tecINSUFFICIENT_FUNDS / tecINSUFFICIENT_RESERVE / tecPRECISION_LOSS / tecTOO_SOON
  • tecOBJECT_NOT_FOUND / tecNO_LINE_INSUF_RESERVE

Invarianten

  • Balance darf SendMax nicht überschreiten.
  • NextClaimTime darf nicht vor StartTime liegen.
  • Expiration muss, sofern gesetzt, nach NextClaimTime liegen.
  • Frequency muss positiv sein und Owner sowie Destination müssen verschieden sein.

Wie sieht ein konkreter Ablauf aus?

Ein Nutzer erlaubt einem Dienst monatlich bis zu 50 XRP. Der Dienst ruft in einer Periode 35 XRP ab; die übrigen 15 XRP können in derselben Periode noch abgerufen werden, werden aber nicht dauerhaft angesammelt.

Wie hängt dieses Amendment mit anderen zusammen?

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

Für dieses Amendment ist keine direkte, belastbar belegte Familienkante eingetragen. Die Seite zeigt deshalb bewusst keinen vermuteten Zusammenhang.

Wie geht es mit diesem Vorschlag weiter?

Das ist ein Vorschlag, kein aktives Netzwerk-Feature. Was davon kommt und wann, ist offen.

Der Entwurf muss fachlich reifen und kann sich noch grundlegend ändern oder verworfen werden. Erst ein passendes rippled-Amendment würde eine getrennte Netzwerkabstimmung auslösen.

Wo steht es in seiner Amendment-Familie?

Welche Primärquellen belegen die Angaben?

← Alle XRPL-Amendments und XLS-Spezifikationen