Die offizielle Dokumentation des XRP Ledger (XRPL) rät Kontoinhabern, die PaymentBurn-Berechtigung nicht zu delegieren, bis ein Amendment namens fixCleanup3_4_0 im Netzwerk aktiviert ist. Die Warnung betrifft einen Fehler an der Grenze zwischen dem Vernichten und dem Erzeugen von Token – ein Fehler, der unter bestimmten Umständen einem Burn-only-Delegate ermöglichte, neue Token auszugeben, statt sie zu vernichten. Der Fehler kann keine neuen XRP erschaffen, betrifft jedoch genau die Aufgabe, die die Berechtigungsdelegation eigentlich hinter Offline-Keys halten sollte.

Was ein Burn-only-Delegate eigentlich tun sollte

Die Berechtigungsdelegation erlaubt einem Konto, bestimmte Aufgaben an ein zweites Konto zu übertragen, das mit seinen eigenen Keys signiert. Die XRPL-Dokumentation beschreibt den Zweck ausdrücklich: Routineaufgaben laufen auf Keys, die online gehalten werden, während die Keys mit voller Kontrolle offline bleiben – für besondere Aufgaben wie die Ausgabe von Token. Coindoos Leitfaden zu XRPLs delegierten Kontokontrollen erläutert, wie Institutionen diese Rollen aufteilen können.

Zwei der zwölf granularen Berechtigungen des Ledgers betreffen das Token-Angebot. PaymentMint umfasst Zahlungen, die fungible Token oder Multi-Purpose Tokens (MPTs) erzeugen. PaymentBurn umfasst Zahlungen, die sie vernichten, und die Dokumentation zieht die Grenze präzise: Das Vernichten endet bei einem Nullsaldo.

An dieser Grenze sitzt der Fehler. Vor der Korrektur konnte eine Zahlung unter PaymentBurn unter bestimmten Umständen über den Nullpunkt hinausgehen und neue Trust-Line-Token oder MPTs ausgeben. fixCleanup3_4_0 weist jede Burn-only-delegierte Zahlung zurück, deren Betrag in das Minting übergreifen würde – es sei denn, dasselbe Delegate hält auch PaymentMint. Die anderen elf granularen Berechtigungen sind nicht betroffen.

Das macht den Fehler in seiner Reichweite eng, aber in seiner Wirkung heikel. Nutzen kann ihn nur ein Konto, das ein Issuer bereits als Delegate ausgewählt hat – doch was es freischaltet, ist die Ausgabe von Token, genau die Aufgabe, die die Delegation hinter Offline-Keys halten sollte.

Cold Storage deckt die Keys eines Delegates nicht ab

Delegierte Transaktionen werden mit dem Master-Key, dem Regular Key oder der Multi-Signing-Liste des Delegates selbst signiert. Ein Issuer kann seine Haupt-Zugangsdaten vollständig offline halten und bleibt dennoch gefährdet, wenn ein Delegate mit PaymentBurn kompromittiert wird, falsch konfiguriert ist oder außerhalb seines Auftrags handelt.

Bei einem fiat-gedeckten Token besteht das wirtschaftliche Risiko in Umlaufeinheiten ohne entsprechende Reserven. Eine Reserve-Bestätigung zeigt die Vermögenswerte, die zu einem Stichtag gegen die ausstehenden Token gehalten werden. Sie sagt nichts darüber aus, welche Konten diese Menge zwischen den Berichten ändern könnten – und genau diese Kontrolle schwächt der Fehler.

Delegation startete, bevor ihre Korrektur die Stimmen hatte

Dies ist der zweite Fehler, der in XRPLs Delegationsfunktion gefunden wurde. Die Originalversion wurde 2025 zurückgezogen, nachdem ein Community-Tester auf dem Devnet entdeckt hatte, dass sie Transaktionsgebühren von Konten einziehen konnte, die nicht signiert hatten; die offizielle Offenlegung bestätigt, dass sie das Mainnet nie erreichte. Ihr Nachfolger, PermissionDelegationV1_1, ging laut XRPLs Amendment-Dashboard am 8. Oktober live, während die PaymentBurn-Korrektur noch Unterstützung bei den Validatoren sammelte.

Die Betroffenheit ist daher Konto für Konto zu bewerten: Nur Issuer, die PaymentBurn seit dem Start gewährt haben, sind betroffen. Jedes Grant ist öffentlich, da Delegate-Ledger-Einträge das gewährende Konto, den Delegate und dessen Berechtigungsliste festhalten. Zum Zeitpunkt der Erstellung identifiziert weder die XRPL-Dokumentation noch die veröffentlichte Berichterstattung einen betroffenen Issuer oder einen Missbrauch.

Eine Erhöhung des Angebots allein würde nichts beweisen, da ein Issuer PaymentMint auch absichtlich gewährt haben kann. Erklärt werden müsste ein Delegate, der nur PaymentBurn hält und dessen Zahlungen Token hinzugefügt haben.

Was Issuer bis Mittwoch prüfen können

Die veröffentlichte Empfehlung von XRPL lautet, PaymentBurn nicht mehr zu delegieren, bis die Korrektur aktiviert ist. Für Issuer, die sie bereits gewährt haben, läuft die Arbeit in dieser Reihenfolge:

1. Alle Delegate-Einträge des ausgebenden Kontos abrufen und jede Berechtigungsliste markieren, die PaymentBurn enthält.
2. DelegateSet mit der vollständigen Liste der zu behaltenden Berechtigungen erneut senden. Eine neue Liste ersetzt die alte; alles, was fehlt, wird entfernt.
3. Ein Grant erst dann als widerrufen betrachten, wenn die Änderung in einem validierten Ledger erscheint.
4. Die früheren Zahlungen des Delegates separat prüfen, da der Widerruf künftige Nutzung stoppt, frühere Transaktionen jedoch nicht rückgängig macht.
5. PaymentBurn erst dann erneut delegieren, wenn fixCleanup3_4_0 im Mainnet als aktiviert angezeigt wird.

Warum die Abstimmung noch kippen kann

Nach den offiziellen Amendment-Regeln benötigt eine Änderung eine Supermehrheit der vertrauenswürdigen Validatoren, die zwei ununterbrochene Wochen gehalten wird. Bei 35 Validatoren im getrackten Set liegt die Schwelle bei 29, und ein Unterschreiten setzt die Uhr zurück. Diese Zurücksetzung ist bereits einmal eingetreten; derzeit unterstützen 33 der 35 vertrauenswürdigen Validatoren die Korrektur.

Selbst bei intakter Unterstützung markiert 14:46 UTC den Beginn des Zwei-Wochen-Fensters. Die Aktivierung erfolgt an einem Ledger-Voting-Checkpoint, sodass die Änderung erst einige Zeit danach in Kraft treten kann.

Die Validatoren stimmen zudem über weit mehr ab als nur diese Korrektur. fixCleanup3_4_0 bündelt 25 Änderungen in den Bereichen Vaults, Lending, Automated Market Makers, NFTs, Escrow und Sponsorship; die PaymentBurn-Korrektur ist der letzte Punkt auf der Liste. Sie patcht den Lending-Code, ohne das Lending Protocol selbst zu aktivieren, für das ein eigenes Amendment noch in Abstimmung ist.

Für Issuer zählt die Bestätigung, dass fixCleanup3_4_0 im Mainnet als aktiviert gelistet ist. Bis dahin birgt ein PaymentBurn-Grant mehr Befugnis, als sein Name vermuten lässt.

Dieser Artikel erschien ursprünglich auf Coindoo.