Der XRP Ledger nähert sich einer zweiten Frist zur Aktivierung eines Sicherheitsfixes, der eine Token-Erstellungslücke mit potenziellen Auswirkungen auf die Stablecoin-Sicherheit im Netzwerk schließen soll. Die Änderung, bekannt als fixCleanup3_4_0, soll am 4. November aktiviert werden, nach einer früheren Verzögerung aufgrund sinkender Validator-Unterstützung.

Nothing fancy here but happy this fixCleanup amendment is going live on the XRP Ledger in the next 48h! Hardening and improving the XRP protocol. pic.twitter.com/XAzbFW4rPY

— Vet (@Vet_X0), November 2, 2026

Die Änderung currently verfügt über die Unterstützung von 33 der 35 vertrauenswürdigen Validatoren des Ledgers und übersteigt damit bequem den Schwellenwert, der zur Aufrechterhaltung der Aktivierung erforderlich ist. Die Unterstützung muss jedoch kontinuierlich 14 Tage lang auf diesem Niveau bleiben, und ein erneuter Rückgang unter den Schwellenwert könnte die Frist erneut verschieben. Die live-Stimmenzählung kann öffentlich auf der XRPSCAN-Seite der Änderung verfolgt werden, was Emittenten und Entwicklern einen direkten Einblick gibt, ob der Countdown hält.

Der Fix ist besonders relevant für die Stablecoin-Sicherheit, da er sich mit den Berechtigungen befasst, die zum Vernichten ausgegebener Tokens verwendet werden. Unter bestimmten Bedingungen könnte ein Konto, das nur zum Verbrennen von Tokens autorisiert ist – ein Konto, das ausschließlich mit dem Entfernen von Tokens aus dem Umlauf beauftragt ist – auch neue erstellen und so den Supply ohne Erlaubnis ausweiten.

Zweite Aktivierungsfrist

Die Änderung hatte ursprünglich den 23. Oktober als Aktivierungsdatum ins Visier genommen, doch die Validator-Unterstützung fiel am 21. Oktober kurzzeitig auf 26 von 35. Dieser Wert lag unter den 29 Stimmen, die zur Aufrechterhaltung des Genehmigungsschwellenwerts erforderlich sind, und setzte den zweiwöchigen Aktivierungs-Countdown zurück.

Die Unterstützung erholte sich später am Tag auf das erforderliche Niveau, startete die Uhr neu und verschob das früheste Aktivierungsdatum auf den 4. November. Die Änderung verfügt jetzt über 33 unterstützende Validatoren, ein Puffer von vier Stimmen über dem Minimum – das entspricht mindestens 29 Stimmen gemäß der 80-%-Regel des Ledgers.

XRP LEDGER BIG UPDATE XRPL bug fix is delayed until November 4. It closes a loophole that could let burn only accounts create new tokens. Will this delay affect confidence in $XRP, even as ETFs have attracted $1.8 billion in net inflows since launch? pic.twitter.com/hgzHkyQvXV

— TMA | The Money Ape (@TheMoneyApe), October 22, 2026

Gemäß dem Änderungsprozess des XRP Ledger müssen Änderungen auf Protokollebene länger als 14 aufeinanderfolgende Tage die Unterstützung von mehr als 80 % der vertrauenswürdigen Validatoren aufrechterhalten, bevor sie aktiviert werden können. Vertrauenswürdige Validatoren sind die Serverbetreiber, die den Konsens des Ledgers antreiben, sodass ihre individuellen Unterstützungsentscheidungen direkt bestimmen, wann Protokoll-Upgrades live gehen. Das Netzwerk überprüft die Unterstützung in regelmäßigen Abständen, was bedeutet, dass selbst ein vorübergehender Rückgang den Countdown neu starten kann. Änderungen laufen nicht ab, wenn die Unterstützung nachlässt; eine Änderung wartet einfach, bis genügend Validatoren sie für das volle Zweiwochenfenster unterstützen.

Die aktuelle Aktivierungsschätzung ist der 4. November um 14:46 UTC, basierend auf der am 21. Oktober neu gestarteten Unterstützungsuhr. Das Datum bleibt bedingt, bis die Änderung formell im Netzwerk aktiviert wird.

Warum der Fix für die Stablecoin-Sicherheit wichtig ist

Die Schwachstelle betrifft die delegierte PaymentBurn-Berechtigung von XRPL, die einem Konto ermöglicht, fungible Tokens oder Multi-Purpose-Tokens im Namen eines Emittenten zu vernichten. Delegierte Berechtigungen ermöglichen es Emittenten, bestimmte Token-Operationen, wie das Verbrennen, an externe Konten oder Dienstleister zu übertragen. Unter bestimmten Umständen könnte dieselbe Berechtigung einem Delegaten auch das Erstellen neuer Tokens ermöglichen, obwohl er nicht zur Erstellung autorisiert ist. Die Änderung soll eine klarere Trennung zwischen Token-Verbrennung und -Ausgabe durchsetzen.

Anders als XRP selbst sind alle anderen Tokens im Ledger ausgegebene Assets, die über Trust Lines mit ausgebenden Konten verbunden sind, die bestimmen, wer sie halten und übertragen darf. Dies ist für Stablecoins relevant, da Emittenten sich oft auf Drittanbieter-Dienste verlassen, um Tokens zu verbrennen, wenn Kunden sie in Fiat-Währung einlösen, und diese Dienste sollten nicht in der Lage sein, zusätzliche Tokens ohne Autorisierung des Emittenten zu erstellen. Unbefugte Ausgabe könnte das Vertrauen in die Angebotskontrollen eines Tokens untergraben, insbesondere bei Assets, die darauf ausgelegt sind, einen festen Wert gegenüber Reserven zu halten.

Die offizielle XRPL-Dokumentation warnt Entwickler davor, PaymentBurn zu delegieren, bis der Fix aktiviert ist. Diese Vorsicht ist an den Aktivierungszeitplan gebunden, sodass jede weitere Verschiebung über den 4. November hinaus den Zeitraum verlängern würde, in dem die Warnung der Dokumentation gilt.

Ripples RLUSD, ein durch US-Dollar gedeckter Stablecoin, läuft sowohl auf dem XRP Ledger als auch auf Ethereum, wodurch die Token-Kontrollen von XRPL für das Stablecoin-Ökosystem des Netzwerks relevant sind. Es gibt jedoch keine öffentlichen Hinweise darauf, dass RLUSD von der Schwachstelle betroffen war oder dass seine Reserven kompromittiert wurden.

Die Änderung ist Teil eines breiteren Pakets technischer Fixes, das Token-Berechtigungen, Automated Market Maker, Vaults, Kreditberechnungen, Escrow und andere Ledger-Funktionen umfasst. Sie aktiviert nicht eigenständig das vorgeschlagene Kreditprotokoll von XRPL, das ein separater Vorschlag bleibt und eine eigene Validator-Zustimmung erfordert.

Wenn die Änderung planmäßig aktiviert wird, wird sie die Berechtigungslücke schließen und die Schutzmaßnahmen rund um ausgegebene Assets im Ledger stärken. Ein weiterer Rückgang der Validator-Unterstützung könnte das Upgrade jedoch erneut verzögern und das Netzwerk auf sein nächstes Aktivierungsfenster warten lassen.