Zum Inhalt springen
In EntwicklungTier ANutzerfreundlichkeit

Sponsor XLS-68

Dritte sollen Transaktionsgebühren und Reserven eines Kontos übernehmen können. Sponsor 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-68
Version
Offen
Aktiviert
Keine Angabe

Was ist der Entwicklungsstand?

Warum wird diese Funktion entwickelt?

Neue Konten benötigen XRP für Gebühren und Reserven, bevor sie eine Anwendung sinnvoll nutzen können. Dienste sollen diese Kosten begrenzt übernehmen können, ohne Kontrolle über Schlüssel oder Assets des Nutzers zu erhalten.

Wie soll der Mechanismus funktionieren?

Ein Sponsor kann die Transaktionsgebühr, die Kontoreserve oder die Objektreserve eines anderen Kontos übernehmen, ohne dessen Schlüssel oder Assets zu kontrollieren. SponsorshipSet richtet vorfinanzierte Limits für Gebühren und Reserven ein. SponsorshipTransfer beendet oder überträgt die Reserveverantwortung für ein Konto oder Objekt.

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
Jedes Konto benötigte eigenes XRP für Gebühren und musste die Reserve seiner eigenen Ledger-Objekte tragen.Ein anderes Konto kann definierte Kosten übernehmen und jede gesponserte Transaktion je nach Modell mitunterzeichnen oder aus einem vorfinanzierten Kontingent bezahlen.

Für wen ist die Änderung relevant?

XRP-Halter und Nutzer

Neue Nutzer könnten eine App ohne eigenes Startguthaben für Gebühr und Reserve verwenden. Das Sponsoring überträgt dem Sponsor keine Verfügungsgewalt über ihre Assets.

Wallets und App-Entwickler

Apps müssen zweite Signatur, Sponsorlimits, getrennte Gebühren- und Reserveverantwortung sowie Transfer oder Ende eines Sponsorings abbilden.

Börsen und Emittenten

Dienste können Onboardingkosten übernehmen und pro Sponsee MaxFee, FeeAmount und ReserveCount begrenzen. Aktive Verpflichtungen binden XRP und blockieren die Löschung des Sponsorkontos.

Node-Betreiber

Nodes führen zusätzliche Reservezähler, Signaturprüfungen und Invarianten über alle gesponserten Objekte und Konten.

Welche Grenzen und Risiken bleiben?

  • Das Amendment ist ein Draft und noch keine Mainnet-Funktion.
  • Der Sponsor besitzt das gesponserte Konto oder Objekt nicht und kann es allein wegen der Kostenübernahme nicht löschen.
  • Das Löschen eines Sponsorship-Objekts beendet vorhandene Sponsor-Felder an bereits gesponserten Konten oder Objekten nicht. Dafür ist SponsorshipTransfer nötig.
  • Nur die globale SignerList wird unterstützt.
  • Ein gesponsertes Konto muss sein Restguthaben bei AccountDelete an den Sponsor senden.
  • Ein Sponsor kann sein Konto erst löschen, wenn alle Sponsoringverhältnisse beendet oder übertragen sind.
  • Welche Ledger-Typen ein Sponsor-Feld tragen dürfen, ist ausdrücklich begrenzt. Bestimmte gemeinsame oder protokollinterne Objekte sind ausgeschlossen.

Welche Gebühren- und Performancewerte nennt die Spec?

  • Fee-Sponsoring kann mit MaxFee und einem vorfinanzierten FeeAmount begrenzt werden.
  • Reserve-Sponsoring verschiebt die Reservebelastung zum Sponsor, ohne die Reservehöhe selbst zu senken.
Technische Details: Transaktionen, Felder, Codes und Invarianten

Transaktionen

  • SponsorshipSet
  • SponsorshipTransfer
  • Payment
  • AccountDelete
  • sponsorfähige Transaktionen mit SponsorSignature

Ledger-Objekte

  • Sponsorship
  • AccountRoot
  • sponsorfähige Owner-Objekte

Felder und Flags

  • Sponsor / SponsorSignature / SponsorFlags
  • Sponsee / Owner
  • FeeAmount / MaxFee / ReserveCount
  • SponsoredOwnerCount / SponsoringOwnerCount
  • SponsoringAccountCount
  • CounterpartySponsor / ObjectID
  • tfSponsorshipSetRequireSignForFee 0x00010000
  • tfSponsorshipClearRequireSignForFee 0x00020000
  • tfSponsorshipSetRequireSignForReserve 0x00040000
  • tfSponsorshipClearRequireSignForReserve 0x00080000
  • tfDeleteObject 0x00100000
  • tfSponsorshipEnd 0x00000001
  • tfSponsorshipCreate 0x00000002
  • tfSponsorshipReassign 0x00000004
  • tfSponsorCreatedAccount 0x00080000

API-Methoden

  • account_objects
  • account_sponsoring

Ergebnis-Codes

  • temINVALID_FLAG
  • temMALFORMED
  • tecNO_TARGET
  • tecNO_PERMISSION
  • tecINSUFFICIENT_RESERVE
  • tecHAS_OBLIGATIONS
  • tecNO_SPONSOR_PERMISSION
  • telINSUF_FEE_P

Invarianten

  • Die Summe aller SponsoredOwnerCount-Werte muss der Summe aller SponsoringOwnerCount-Werte entsprechen.
  • Das Erzeugen eines gesponserten Owner-Objekts erhöht SponsoringOwnerCount und SponsoredOwnerCount gemeinsam; das Löschen senkt beide gemeinsam.

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?

Sponsor 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?

Welche Primärquellen belegen die Angaben?

← Alle XRPL-Amendments und XLS-Spezifikationen