xrpld 3.3.0: Der XRP Ledger holt zwei zurückgezogene Amendments zurück

Ripple hat angekündigt, was in der nächsten Version der XRP-Ledger-Software steckt: fünf Amendments, die den Ledger für institutionelle Anwendungen öffnen sollen. Die Ankündigung liest sich glatt. Sie lässt allerdings den Teil weg, der die Geschichte erst interessant macht.

Zwei der fünf Funktionen waren nämlich schon einmal da. Beide wurden wieder eingesammelt, nachdem in ihnen kritische Fehler gefunden wurden. Eine davon fand keine Person, sondern ein autonomes Analysewerkzeug.

Was gerade wirklich veröffentlicht wurde

Am 1. August 2026 ist xrpld 3.2.1 erschienen. Wer darin ein großes Feature-Update erwartet, wird enttäuscht. Die Version ist ein Hotfix, sie enthält kein einziges Amendment, und die Release-Notes begründen nicht einmal, was genau repariert wurde. Ein Eintrag, ein Pull Request, fertig.

Das ist der Normalfall im Protokoll-Alltag und der Kontrast, den man kennen sollte: Die allermeisten Releases sind Wartung. Nur wenige bringen Änderungen mit, über die das Netzwerk abstimmen muss. 3.3.0 gehört zur zweiten Sorte und ist zum Zeitpunkt dieses Artikels noch nicht erschienen. Erwartet wird die Version in der Woche vom 3. bis 9. August.

Am Rande, weil es für Namenssuchen relevant ist: Die Referenzsoftware heißt seit Version 3.2.0 vom 16. Juni 2026 offiziell xrpld. Der alte Name rippled ist Geschichte, das Repository auf GitHub trägt ihn aber weiterhin. Wer nach dem alten Begriff sucht, findet also weiterhin die richtigen Quellen.

Die fünf Amendments in 3.3.0

Ein Hinweis vorweg, der in fast jeder Meldung untergeht: Ripple nennt die Funktionen in der Ankündigung bei ihren Produktnamen. Im Ledger heißen sie anders. Wer den Abstimmungsstand selbst nachsehen will, braucht die technischen Namen, und die stehen hier jeweils dabei.

Confidential MPT, im Ledger: ConfidentialTransfer

Multi-Purpose Tokens bekommen vertrauliche Salden und Beträge. Technisch kombiniert ConfidentialTransfer nach XLS-96 elliptische Kurvenverschlüsselung mit Zero-Knowledge-Beweisen. Beträge sind dann öffentlich nicht mehr lesbar, benannte Stellen wie Emittenten oder Prüfer können sie trotzdem verifizieren.

Wichtig für die Erwartungshaltung: Das betrifft ausgegebene Token, nicht XRP. XRP-Zahlungen bleiben vollständig öffentlich. Wer die Meldung als „XRP wird jetzt privat" liest, liest sie falsch.

Batch, im Ledger: BatchV1_1

Batch nach XLS-56 führt bis zu acht Transaktionen über verschiedene Konten hinweg atomar aus. Entweder alle gehen durch oder keine. Für den Zahlungsverkehr ist das die Grundlage für Zug-um-Zug-Abwicklung, bei der Lieferung und Zahlung nicht getrennt voneinander scheitern können.

Die Versionsnummer im Namen ist kein Zufall, dazu gleich mehr.

Permission Delegation, im Ledger: PermissionDelegationV1_1

Permission Delegation nach XLS-75 erlaubt es, einzelne, eng umrissene Rechte an ein anderes Konto abzugeben, ohne den Schlüssel herauszugeben. Ein Unternehmen kann die Kontrolle über die Ausgabe behalten und trotzdem einer anderen Abteilung erlauben, definierte Transaktionen auszulösen.

Sponsored Fees and Reserves, im Ledger: Sponsor

Das Sponsor-Amendment nach XLS-68 lässt Dritte die Gebühren und die Kontoreserve für ein anderes Konto übernehmen. Der Nutzer behält seine Schlüssel und sein Konto, muss aber kein XRP besitzen, um loszulegen.

Das ist die größte Änderung für alles, was Endkunden anfassen. Bisher gilt: Wer den XRP Ledger nutzen will, braucht vorher XRP für Reserve und Gebühren. Genau an dieser Stelle springen Leute ab.

Dynamic MPT, im Ledger: DynamicMPT

DynamicMPT nach XLS-94 löst ein praktisches Problem: Bisher ist die Konfiguration eines Multi-Purpose Tokens nach der Ausgabe faktisch festgezurrt. Wer später die Transfergebühr ändern will, muss einen neuen Token ausgeben und alle Halter migrieren. Künftig legt der Emittent bei der Ausgabe fest, welche Eigenschaften später änderbar bleiben. Was nicht als änderbar markiert wurde, bleibt fest.

Für Halter ist das der entscheidende Punkt: Man kann von Anfang an sehen, welche Rechte sich der Emittent dauerhaft vorbehält.

Warum zwei dieser Amendments schon einmal gescheitert sind

Batch und Permission Delegation tragen beide ein V1_1 im Namen. Das ist kein kosmetisches Detail, sondern die Kennzeichnung, dass es sich um überarbeitete Fassungen handelt. Beide Vorgänger wurden aus dem Verkehr gezogen.

Permission Delegation, September 2025. Ein Community-Mitglied unter dem Namen tequ meldete am 15. September 2025 beim Testen im Devnet einen Fehler. Die Rechteprüfung lief vor der Signaturprüfung. Dadurch konnte ein Angreifer einem fremden Konto Transaktionsgebühren aufbürden und dessen XRP-Bestand abschmelzen. Das Amendment wurde ab Version 2.6.1 deaktiviert, wie der Disclosure Report festhält.

Batch, Februar 2026. Dieser Fall ist der schwerwiegendere. Am 19. Februar 2026 fand das autonome Sicherheitswerkzeug Apex von Cantina AI per statischer Analyse einen Fehler in der Signaturprüfung, gemeldet wurde er von Pranamya Keshkamat. Traf die Prüfung auf einen Unterzeichner, dessen Konto im Ledger noch nicht existierte und dessen Signaturschlüssel dem eigenen Konto entsprach, meldete sie sofort Erfolg und übersprang alle weiteren Unterzeichner.

Im Klartext: Ein Angreifer hätte Autorisierungen für fremde Konten fälschen können, ohne deren Schlüssel zu besitzen. Möglich gewesen wären Zahlungen, die fremde Konten bis zur Mindestreserve leeren, sowie Änderungen an fremden Kontoeinstellungen und Trustlines.

Die Reaktion kam innerhalb von vier Tagen. Am 23. Februar 2026 erschien Version 3.1.1 als Notfall-Release und markierte Batch sowie fixBatchInnerSigs als nicht unterstützt. Den Validatoren der Unique Node List wurde geraten, mit Nein zu stimmen.

Der entscheidende Satz steht im Disclosure Report: Das Amendment befand sich in der Abstimmungsphase und war nie auf dem Mainnet aktiv. Es war zu keinem Zeitpunkt Geld in Gefahr.

Ich bin ehrlich: Das System hat genau so funktioniert, wie es soll. Zwischen Devnet, Abstimmungsphase und Zwei-Wochen-Frist liegen mehrere Netze, die ein Fehler passieren muss, bevor er echtes Geld erreicht. In beiden Fällen war vorher Schluss. Und der Februar-Fall zeigt zusätzlich, dass die Prüfung selbst besser wird, wenn ein automatisches Werkzeug Dinge findet, die menschliche Reviews übersehen haben. Das Paradebeispiel dafür, wie es funktionieren sollte!

Ein Release ist eine Einladung, keine Aktivierung

Das ist der Punkt, an dem die meisten Meldungen unsauber werden. Wenn 3.3.0 erscheint, ist keine dieser fünf Funktionen nutzbar. Die Software bringt lediglich den Code mit und stellt die Amendments zur Abstimmung.

Aktiviert wird ein Amendment erst, wenn mehr als 80 Prozent der Validatoren zustimmen und diese Mehrheit zwei Wochen ohne Unterbrechung hält. Fällt die Zustimmung zwischendurch unter die Schwelle, beginnt die Frist von vorn.

Wie lange das dauern kann, zeigt ein Blick auf den aktuellen Abstimmungsstand. Version 3.2.0 erschien am 16. Juni 2026 mit dem Lending-Protokoll und dem Single Asset Vault. Sechs Wochen später sieht es so aus:

Stand: 1. August 2026, Daten von XRPScan. Den fortlaufend aktualisierten Stand aller Amendments findest du in unserer Amendment-Übersicht, die Zuordnung zu den einzelnen Versionen in der Release-Historie.

Zwei Dinge liest man daraus. Erstens: Niedrige Zustimmung kurz nach einem Release ist normal, weil Validatoren ihre Server nach und nach aktualisieren. Zweitens, und das ist der wichtigere Teil: XChainBridge hängt nicht mangels Update fest, sondern weil das Netzwerk seit geraumer Zeit nicht mitzieht. Ein Amendment, das niemand aktiviert, bleibt eben inaktiv.

Für 3.3.0 heißt das: Ein realistischer Zeitraum bis zur Aktivierung liegt bei mehreren Wochen bis Monaten. Bei Batch und Permission Delegation kommt hinzu, dass beide Vorgänger wegen Sicherheitsfehlern zurückgezogen wurden. Es wäre nicht überraschend, wenn Validatoren hier länger prüfen als sonst.

Was das für XRP bedeutet

Die naheliegende Frage zuerst, weil sie ohnehin gestellt wird: Direkt am Kurs hängt an diesen fünf Amendments nichts. Protokoll-Upgrades sind keine Nachfrageereignisse.

Interessanter ist das Sponsor-Amendment, weil es auf den ersten Blick gegen XRP zu arbeiten scheint. Wenn eine Bank oder eine App die Gebühren und die Reserve übernimmt, braucht der Endnutzer selbst kein XRP mehr. Weniger Nutzer, die XRP kaufen müssen, klingt zunächst nach weniger Nachfrage.

Die Rechnung geht anders auf. Die Pflicht, sich vorher XRP zu besorgen, war nie ein Nachfragetreiber, sondern eine Abbruchstelle. Wer eine App ausprobieren will und erst eine Börse, eine Verifizierung und einen Kauf hinter sich bringen muss, kommt gar nicht erst an. Sponsoring nimmt genau diese Hürde raus. Das XRP verschwindet dabei nicht, es wandert nur zum Sponsor, der es in größerem Umfang vorhalten muss.

Die übrigen vier Amendments zielen erkennbar auf regulierte Anwender. Vertrauliche Beträge mit Prüfmöglichkeit, abgestufte Rechte statt geteilter Schlüssel, nachträglich anpassbare Token-Eigenschaften und Zug-um-Zug-Abwicklung sind Anforderungen aus dem Bankenumfeld, nicht aus der Retail-Welt.

Woran du selbst erkennst, ob ein Amendment live geht

Du musst dich nicht auf Meldungen verlassen. Der Abstimmungsstand ist öffentlich, und drei Dinge reichen zur Einordnung:

• Der technische Name. Suche nach ConfidentialTransfer, Sponsor, DynamicMPT, BatchV1_1 und PermissionDelegationV1_1, nicht nach den Produktnamen aus der Ankündigung.

• Die Zustimmungszahl gegen die Schwelle. Entscheidend ist nicht die absolute Zahl, sondern der Abstand zur benötigten Schwelle. Die verschiebt sich, wenn Validatoren dazukommen oder wegfallen.

• Die Zwei-Wochen-Frist. Erst wenn die Mehrheit steht, läuft die Uhr. Und sie startet neu, sobald die Zustimmung zwischendurch abrutscht.

Erst wenn ein Amendment als aktiviert eingetragen ist, hat sich am Ledger tatsächlich etwas geändert. Alles davor ist Absichtserklärung.

Einordnung

Wenn ich mir diesen Fortschritt so ansehe, wir eins klar: Die Entwickler rund um den XRP Ledger wissen genau was sie tun und im Zusammenspiel mit den Validatoren fühlt es sich so an, als würden wir uns zeitnah Richtung stärkerer Adoption bewegen, als es die meisten wahrnehmen.

Dieser Artikel wird aktualisiert, sobald xrpld 3.3.0 veröffentlicht ist und sich der Abstimmungsstand ändert. Keine Anlageberatung.