Der XRP Ledger steht mit Version 3.2.0 kurz vor dem nächsten grossen Upgrade. Die wichtigste Änderung ist die Umbenennung der Core-Node-Software von "rippled" zu "xrpld"; das Zieldatum liegt um den 15. Juni 2026.
Der XRP Ledger ist eine dezentrale öffentliche Blockchain, auf der XRP-Transaktionen laufen. Die Software rippled, neu xrpld, ist das Server-Programm, das Node-Betreiber und Validatoren auf ihren Systemen ausführen, um am Netzwerk teilzunehmen. Die XRP Ledger Foundation (XRPLF) pflegt den Code als Open-Source-Projekt in ihrem Repository. Zudem ist Version 3.2.0 bereits das vierte grössere Upgrade seit Dezember 2025. Der zugehörige GitHub-Milestone steht bei 98 Prozent, mit 466 geschlossenen und fünf offenen Issues. Offizielle Release Notes liegen jedoch noch nicht vor, und das ursprüngliche Due-Date vom 26. Mai ist bereits überschritten.
Die Kern-Änderung in 3.2.0: rippled wird zu xrpld
Die grösste Neuerung in 3.2.0 betrifft nicht eine Funktion, sondern den Namen der zentralen Software selbst. Künftig heisst die Core-Node-Software xrpld statt rippled. Das GitHub-Repository" XRPLF/rippled" behält hingegen seinen Namen; den neuen Namen trägt allein die Software, nicht das Projekt-Verzeichnis. Die README des Repositorys hält den Schritt bereits fest und beschreibt die Server-Software als xrpld.
Hinter der Umbenennung steht eine bewusste Distanzierung vom bisherigen Branding. Viele verbanden den Namen rippled mit Ripple Inc., während der neue Name die Software direkt mit dem XRP Ledger verknüpft. XRPL Operations kommunizierte den Schritt am 4. Juni 2026 auf X mit den Worten „XRP Ledger 3.2.0 is coming soon!" und einem GIF, das den Kommandozeilen-Prompt mit „xrpld version 3.2.0" zeigt. Somit zeigt sich die Trennung zwischen dem Open-Source-Protokoll und dem Unternehmen Ripple auch terminologisch. Für die Aussenwahrnehmung des Netzwerks ist diese begriffliche Entkopplung mehr als ein Detail, da sie das Protokoll als eigenständige Infrastruktur betont.
"XRP Ledger 3.2.0 steht kurz bevor. Das Hauptsystem des XRPL wird von rippled in xrpld umbenannt. Dieser Übergang erfordert einige Anpassungen für Infrastruktur-Betreiber. Wir bereiten ein detailliertes Playbook vor, um Sie durch den Upgrade-Prozess zu führen." - XRPL Operations, X-Post vom 4. Juni 2026
Abonnieren Sie unseren Newsletter
Die besten Artikel der Woche direkt in ihre Mailbox geliefert.
Bis zu 40 Prozent weniger Speicherbedarf in 3.2.0
Neben der Umbenennung soll 3.2.0 spürbare Effizienzgewinne bringen. Sekundärquellen nennen einen um 30 bis 40 Prozent niedrigeren Speicherbedarf der Software. Diese Zahl ist allerdings noch nicht offiziell bestätigt, da die finalen Release Notes mit verbindlichen Benchmarks bislang fehlen. Angekündigt sind zudem zahlreiche Performance-Optimierungen, Bug Fixes, Korrekturen beim Rounding und Number-Handling sowie diverse Code-Cleanups. Daher senkt ein geringerer Speicherbedarf die Anforderungen an die Hardware der Node-Betreiber und kann den Betrieb eines Validators günstiger machen.
Ebenso klar ist, was 3.2.0 nicht enthält. Die viel diskutierten AMM Swappable Curves mit Concentrated Liquidity gehören nicht zu diesem Release. Dieser Vorschlag (XLS-Standard-Diskussion #547) befindet sich nämlich im Draft-Status und hat den Amendment-Prozess noch nicht durchlaufen. Der Standard wurde am 26. Mai 2026 von Denis Angell und Roman Thpt publiziert, bleibt aber vorerst eine Diskussionsgrundlage. Solange keine offiziellen Release Notes vorliegen, bleibt der finale Funktionsumfang von 3.2.0 ohnehin nicht abschliessend verifizierbar.
Was Operatoren und Validatoren jetzt tun müssen
Für die Betreiber der Netzwerk-Infrastruktur ist die Umbenennung mehr als kosmetisch. Alle Infrastruktur-Betreiber, Validatoren und Node-Operatoren müssen ihre Systeme vor der Mainnet-Migration aktualisieren. Betroffen sind dabei Service-Files, Scripts, Monitoring-Tools und Command-Line-Checks, die bislang auf den Prozessnamen `rippled` verweisen. Jede Automatisierung, die den alten Prozessnamen erwartet, muss auf `xrpld` angepasst werden, sonst greifen Health-Checks und Alarme ins Leere. XRPL Operations stellt dazu ein detailliertes technisches Playbook bereit, das die Operatoren durch den Upgrade-Prozess führen soll.
Wer das Update verpasst, riskiert konkrete Folgen. Operatoren, die nicht rechtzeitig aktualisieren, können daher ihre Konsens-Berechtigung verlieren. Dieser Mechanismus zeigte sich schon bei der 3.1.3-Aktivierung Ende Mai 2026. Hintergrund ist der Amendment-Prozess des XRPL: Änderungen benötigen mindestens 80 Prozent Validator-Zustimmung über zwei zusammenhängende Wochen. Wer upgradet, stimmt somit automatisch mit „Yes" für jene Amendments mit dem Default-Vote `Yes`. Ein verpasstes Update bedeutet folglich nicht nur veraltete Software, sondern den Verlust der aktiven Rolle im Konsens.
Für normale XRP-Halter ändert sich hingegen nichts. Das Update betrifft ausschliesslich die Server-Infrastruktur, weshalb Endnutzer keine Aktion ergreifen müssen.
Viertes XRPL-Upgrade seit Dezember und das offene Datum
Mit 3.2.0 setzt der XRP Ledger ein hohes Release-Tempo fort. Gleichzeitig ist es das vierte grössere Upgrade seit Dezember 2025, nach der Linie von 3.0.0 über 3.1.0 bis zu den Versionen 3.1.1, 3.1.2 und 3.1.3. Zunächst legte 3.0.0 im Dezember 2025 mit umfangreichem Refactoring und der DynamicMPT-Funktion den Grundstein; 3.1.0 brachte Ende Januar 2026 das Lending Protocol und eine erweiterte Number-Klasse. Die direkte Vorgängerversion 3.1.3 erreichte Ende Mai 2026 auf Ledger-Index 104'507'137 ihre Aktivierung, und zwar mit 100 Prozent Validator-Konsens. Sie brachte das fixCleanup3_1_3-Amendment, eine Sammlung von Korrekturen für NFTs, Permissioned Domains, Vaults, das Lending Protocol und MPTs. Zuvor hatte bereits 3.1.1 im Februar 2026 das Batch-Amendment nach Responsible Disclosure deaktiviert, während 3.1.2 im März verbessertes Exception-Handling und einen Sicherheits-Fix nachreichte.
Das oft genannte Zieldatum um den 15. Juni ist allerdings mit Vorsicht zu geniessen. Es stammt aus Validator-Berichten und wurde von XRPL Operations nicht offiziell bestätigt. Der GitHub-Milestone war ursprünglich auf den 26. Mai terminiert und ist damit deutlich überfällig. Bei 98 Prozent Fertigstellung und noch fünf offenen Issues bleibt schliesslich ein Rest an Arbeit. Solange die offiziellen Release Notes nicht vorliegen, bleibt sowohl der genaue Termin als auch der endgültige Funktionsumfang offen.
