Validierer im XRP Ledger aktivierten das Amendment fixCleanup3_4_0 am 4. November um 14:52 UTC und schlossen damit eine knapp vierwöchige Lücke, in der ein delegierter Token-Burn den Kontostand über null hinaus drücken konnte. Coindoo bestätigte die Aktivierungstransaktion im validierten Ledger 108,112,129, und Ripples öffentlicher Mainnet-Server führt das Amendment als aktiviert.

Die Aktivierung folgte auf eine Abstimmung, die Ende Oktober kurzzeitig ihre Supermehrheit verlor – ein Rückschlag, der in Coindoos Bericht vor der Aktivierung dokumentiert wurde. Dieser Bericht enthielt die Checkliste, die Issuer auszuführen empfohlen wurde. Der mit der Korrektur eingereichte Code und Test beantworten eine engere Frage: Wessen Token hat der Überschuss tatsächlich erzeugt.

Fast vier Wochen ohne Nullstands-Prüfung

Die Delegation ging am 8. Oktober unter dem Amendment PermissionDelegationV1_1 live, wie das XRPL-Amendment-Dashboard zeigt. Vom 8. Oktober bis zum 4. November konnte ein Delegate mit PaymentBurn in bestimmten Konfigurationen eine Einlösung über null hinaus drücken. XRPLs Berechtigungsreferenz riet daher davon ab, diese Berechtigung zu delegieren, bis das Amendment aktiviert ist. Diese Bedingung wurde am 4. November erfüllt.

Der rippled-Commit hinter der Korrektur, erstellt unter dem GitHub-Handle yinyiqian1, ergänzt die fehlende Prüfung. Wenn ein Delegate nur PaymentBurn hält, vergleicht das Ledger den Zahlungsbetrag mit dem tatsächlich gehaltenen Kontostand und lehnt alles Größere ab. XRPLs Dokumentation beschrieb Burning bereits als Stopp bei null; für delegierte Zahlungen setzte der Code dieses Limit erst mit diesem Amendment durch.

Im Test: Alice, ein Gateway und eine überdimensionierte Zahlung

Der Test im Commit verwendet drei Konten. Alice hält 50 USD, ausgegeben von einem Konto namens gateway. Gateway wiederum hat eine Trust Line eröffnet, die bis zu 200 USD von alice akzeptiert, was die Code-Kommentare als „issuing liquidity available once the trustline reaches zero" für die Zahlungs-Engine beschreiben.

Alice gewährt dann einem dritten Konto, bob, die Berechtigung PaymentBurn, und bob sendet eine Zahlung von alice an gateway über das Doppelte ihres Guthabens. Der Trace zeigt, wie das Ledger diese Zahlung und die Folgezahlungen unter den jeweiligen Regeln behandelt hat.

Alte Regeln · Nur PaymentBurn

• 100 USD: akzeptiert
• Alices 50 eingelöst, dann 50 alice-ausgegebene USD erzeugt
• Endzustand: gateway hält 50 USD von alice ausgegeben

Neue Regeln · Nur PaymentBurn

• 100 USD: abgelehnt
• 20 USD: akzeptiert, 30 verbleiben
• 30 USD: akzeptiert, Kontostand bei null
• 1 USD: abgelehnt

Neue Regeln · PaymentBurn + PaymentMint

• 100 USD: akzeptiert
• Überschreitet null, da Minting autorisiert ist und gateway Alices IOUs akzeptiert

Die neuen Token waren Alices Schulden

Nach den alten Regeln fügte die Zahlung keine Einheiten von gateways USD hinzu. Gateways Verpflichtung gegenüber alice sank von 50 auf null. Stattdessen erschienen 50 USD, ausgegeben von alice und gehalten von gateway: Alice endete die Transaktion als Schuldner des Issuers – allein auf Grundlage einer Zahlung, die ein Delegate signiert hatte, den sie nur zur Einlösung autorisiert hatte.

Das Ledger behandelt diese als zwei verschiedene Assets. XRPLs Dokumentation zu Asset-Formaten identifiziert einen Trust-Line-Token anhand seines Währungscodes und seines ausgebenden Kontos, sodass Alices USD und gateways USD denselben Code, aber nicht denselben Issuer teilen. Native XRP, das keinen Issuer hat, lag vollständig außerhalb der Schwachstelle.

Im dokumentierten Fall lag das Risiko also bei zwei Parteien: beim Konto, das die Burn-Berechtigung delegiert hatte und eine nie genehmigte Verbindlichkeit aufnehmen konnte, sowie beim Issuer, der diese IOUs empfing. Halter von gateways USD sahen sich keinen neuen Einheiten des gehaltenen Tokens gegenüber.

Die Voraussetzung, die die Schwachstelle einschränkte

Der Überschuss hing von einer einzigen Einstellung auf Gateways Seite ab. Ohne eine Trust Line, die Alices IOUs akzeptiert, gab es für die Zahlung keinen Weg, alice-ausgegebenes USD zu erzeugen. Ein Issuer muss diese Trust Line selbst einreichen – das stärkste Argument dafür, dass die Schwachstelle nur begrenzte praktische Reichweite hatte.

Dieses Argument hat einen Haken. XRPLs Delegationsdokumentation führte vor der Korrektur auch Multi-Purpose Tokens (MPTs) unter den Assets, die ein Burn-only-Delegate minten konnte, während der Test im Commit nur den Trust-Line-Fall abdeckt. Keine der beiden Quellen beschreibt einen Live-Vorfall, doch die Trust-Line-Lesart sollte nicht ohne einen eigenen Test auf MPT-Issuer ausgeweitet werden.

Eine Berechtigung deckt weiterhin jede Währung ab

Das Amendment begrenzt, wie viel ein Burn-only-Delegate einlösen kann. Unberührt bleibt, welche Token die Berechtigung erfasst. Granulare Berechtigungen sind fest verankert, und dieselbe Dokumentation stellt fest, dass ein Konto einem Delegate nicht das Recht geben kann, einige Währungen zu senden, während andere ausgeschlossen bleiben.

Für ein Operations-Konto, das USD- und EUR-Token oder Stablecoins von zwei Issuern hält, erlaubt eine einzige PaymentBurn-Gewährung dem Delegate, alle davon einzulösen – jeweils bis zum Kontostand. Jede Aufteilung nach Währung muss aus der Verteilung der Bestände auf Konten resultieren. Die Payment-Berechtigung auf Transaktionstyp-Ebene reicht noch weiter, da sie Zahlungen dieses Typs generell abdeckt, sodass eine Prüfung, die nur die beiden granularen Werte kontrolliert, sie übersehen kann. Coindoos früherer Beitrag dazu, wie XRPL die operative Autorität zwischen Konten aufteilt, erläutert, wie Institutionen diese Rollen strukturieren.

Was belegen würde, ob die Schwachstelle ausgenutzt wurde

Jede Gewährung ist öffentlich. Der Delegate-Ledger-Eintrag erfasst das gewährende Konto, den Delegate und dessen Berechtigungsliste, womit Missbrauch für jedermann onchain überprüfbar ist.

Das Onchain-Muster:

• Eine Zahlung, validiert nach dem 8. Oktober und vor Ledger 108,112,129.
• Signiert von einem Delegate, der zu diesem Zeitpunkt PaymentBurn, aber weder PaymentMint noch Payment hielt.
• Gesendet an den Issuer des Tokens, wodurch das delegierende Konto einen negativen Stand auf dieser Trust Line behielt.

Eine Zahlung, die alle drei Kriterien erfüllt, würde bestätigen, dass der Überschuss im Mainnet stattfand. Eine Prüfung aller PaymentBurn-Gewährungen in diesem Zeitraum ohne Treffer würde dies für Trust-Line-Token ausschließen, wobei MPTs eine separate Prüfung erfordern. Da DelegateSet eine Berechtigungsliste vollständig ersetzt, wie der Bericht vor der Aktivierung erklärte, muss die Prüfung die jeweils bei Validierung der Zahlung geltenden Berechtigungen heranziehen.

Das Amendment gilt ab Ledger 108,112,129. Jede zuvor validierte Zahlung bleibt exakt wie aufgezeichnet bestehen – auch solche, die null überschritten haben. Für Betreiber, die Transaktionen rund um die Änderung prüfen, ist die Nummer des validierten Ledgers daher die maßgebliche Grenze zur Bestimmung, welche Regeln galten.

Quelle: Coindoo