Zum Inhalt springen
AktiviertTier BIdentität & Oracle

PermissionDelegationV1_1 XLS-75

Konten können ausgewählte Transaktionsrechte an andere Konten delegieren und behalten ihre eigenen Schlüssel für sich. PermissionDelegationV1_1 ist im XRP Ledger aktiviert. xrpscan nennt 08.10.2026 als Aktivierungsdatum und rippled 3.3.0 als erste Version.

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

Status
Aktiviert
XLS
XLS-75
Aktiviert
08.10.2026

Was ändert dieses Amendment?

Warum gibt es dieses Amendment?

Emittenten und Unternehmen wollen operative Aufgaben wie Token-Ausgabe oder Trustline-Freigaben auf mehrere Personen verteilen und dabei die volle Kontrolle über das Konto behalten. Die erste Fassung wurde nach einem Fehler deaktiviert, deshalb erscheint die Funktion mit neuer Amendment-ID.

Wie funktioniert der Mechanismus?

DelegateSet legt für ein Kontenpaar ein Delegate-Objekt mit bis zu zehn Berechtigungen an, eine leere Liste löscht es wieder. Der Delegierte sendet Transaktionen mit dem Feld Delegate, signiert mit eigenen Schlüsseln und zahlt die Gebühr, während nur die Sequence des delegierenden Kontos steigt. Granulare Rechte erlauben ausschließlich die dafür vorgesehenen Felder und Flags einer Transaktion.

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

VorherNachher
Kontoaktionen wie das Autorisieren von Trustlines erforderten direkte Kontrolle über die Schlüssel des Kontos. Die erste Fassung PermissionDelegation ist seit rippled 2.6.1 als nicht unterstützt markiert.Mit aktivem Amendment kann ein Konto einzelnen anderen Konten ausgewählte Transaktionstypen oder granulare Rechte wie TrustlineAuthorize zuweisen und diese Liste jederzeit ersetzen oder löschen.

Für wen ist die Änderung relevant?

XRP-Halter und Nutzer

Delegation ist freiwillig. Wer ein Recht wie Payment delegiert, gibt dem Delegierten Zugriff auf die entsprechenden Mittel und sollte die Freigabe eng fassen.

Wallets und App-Entwickler

Wallets müssen das Feld Delegate erkennen, die Gebühr dem Delegierten zuordnen und verständlich anzeigen, welche Rechte ein Konto vergeben hat.

Börsen und Emittenten

Emittenten können Rollen trennen, etwa Token-Ausgabe, Trustline-Verwaltung und KYC-Freigaben durch einen externen Anbieter.

Node-Betreiber

Nodes prüfen bei jeder delegierten Transaktion das passende Delegate-Objekt, die Berechtigung und bei granularen Rechten die zulässigen Felder und Flags.

Welche Grenzen und Risiken bleiben?

  • Die vollständigen Transaktionen AccountSet, SetRegularKey, SignerListSet, DelegateSet und AccountDelete sind von der Delegation ausgeschlossen.
  • Vault- und Lending-Transaktionen, SponsorshipTransfer und ConfidentialMPTConvert sind ebenfalls ausgeschlossen.
  • Ein Delegate-Objekt speichert höchstens zehn Berechtigungen.
  • Rechte an ein Pseudo-Konto lassen sich nicht vergeben.
  • Delegierte Transaktionen werden ab rippled 3.3.0 nicht in die Transaktionswarteschlange aufgenommen.

Welche Gebühren- und Performancewerte nennt die Spec?

  • Der Delegierte zahlt die Gebühr der delegierten Transaktion.
  • Jedes Delegate-Objekt belegt eine Objektreserve des delegierenden Kontos.
Technische Details: Transaktionen, Felder, Codes und Invarianten

Transaktionen

  • DelegateSet
  • delegierbare Transaktionen mit Feld Delegate

Ledger-Objekte

  • Delegate

Felder und Flags

  • Authorize
  • Permissions (max. 10 Einträge)
  • Delegate (gemeinsames Transaktionsfeld)

API-Methoden

  • account_tx (Filter für delegierte Transaktionen ab rippled 3.3.0)

Ergebnis-Codes

  • temDISABLED
  • temARRAY_TOO_LARGE
  • temMALFORMED
  • temBAD_SIGNER
  • tecNO_TARGET
  • tecNO_PERMISSION
  • tecNO_ENTRY
  • terNO_DELEGATE_PERMISSION

Invarianten

  • Ein Konto darf ohne gültiges Delegate-Objekt keine Transaktion im Namen eines anderen Kontos senden.

Wie sieht ein konkreter Ablauf aus?

Ein Emittent vergibt an einen KYC-Dienstleister nur das granulare Recht TrustlineAuthorize. Der Dienstleister kann damit Trustlines freigeben, Zahlungen aus dem Emittentenkonto bleiben ihm verwehrt.

Wie hängt dieses Amendment mit anderen zusammen?

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

ist Teil des Sammel-Fix

fixCleanup3_4_0

Der Sammel-Fix zu rippled 3.4.0 korrigiert Randfälle in Vaults, Lending, AMM, Permissioned DEX, Escrow, Sponsoring und Delegation. Der dokumentierte Sammel-Fix umfasst PermissionDelegationV1_1.

Beziehung in der Primärquelle prüfen

Wie geht es mit diesem Amendment weiter?

PermissionDelegationV1_1 ist im XRP Ledger aktiviert. xrpscan nennt 08.10.2026 als Aktivierungsdatum und rippled 3.3.0 als erste Version.

Die Regeln sind bereits Teil des Mainnets. Serverbetreiber brauchen eine kompatible rippled-Version, normale Wallet-Nutzer müssen nichts manuell aktivieren.

Wo steht es in seiner Amendment-Familie?

AMM und Clawback: Protokollfolge

  1. DeletableAccountsAktiviert · ab rippled 1.4.0
  2. TicketBatchAktiviert · ab rippled 1.7.0
  3. DisallowIncomingAktiviert · ab rippled 1.10.0
  4. AMMAktiviert · ab rippled 1.12.0
  5. ClawbackAktiviert · ab rippled 1.12.0
  6. fixDisallowIncomingV1Aktiviert · ab rippled 2.0.0
  7. fixInnerObjTemplateAktiviert · ab rippled 2.1.0
  8. fixAMMOverflowOfferAktiviert · ab rippled 2.1.1
  9. fixAMMv1_1Aktiviert · ab rippled 2.2.0
  10. fixPreviousTxnIDAktiviert · ab rippled 2.2.0
  11. AMMClawbackAktiviert · ab rippled 2.3.0
  12. fixAMMv1_2Aktiviert · ab rippled 2.3.0
  13. fixInnerObjTemplate2Aktiviert · ab rippled 2.3.0
  14. fixFrozenLPTokenTransferAktiviert · ab rippled 2.4.0
  15. DeepFreezeAktiviert · ab rippled 2.4.0
  16. PermissionedDEXAktiviert · ab rippled 2.5.0
  17. fixAMMv1_3Aktiviert · ab rippled 2.5.0
  18. PermissionDelegationVeraltet · ab rippled 2.5.0
  19. fixAMMClawbackRoundingAktiviert · ab rippled 3.0.0
  20. SponsorIn Abstimmung · ab rippled 3.3.0
  21. PermissionDelegationV1_1Aktiviert · ab rippled 3.3.0
  22. fixCleanup3_3_0Aktiviert · ab rippled 3.3.0
  23. fixCleanup3_4_0In Abstimmung · ab rippled 3.4.0
  24. MPTokensV2In Entwicklung

Welche Primärquellen belegen die Angaben?

← Alle XRPL-Amendments und XLS-Spezifikationen