XRP Ledger Batch-Amendment auf frühestens 9. Oktober 2026 verschoben: Was Node-Betreiber jetzt prüfen

Aktualisiert am 27.09.2026: Die erste Fassung dieses Artikels vom 18.09.2026 nannte den 29. September 2026, 14:06:41 UTC als Aktivierungstermin. Dieser Termin gilt nicht mehr. Die Zustimmung der Validatoren für BatchV1_1 ist zwischenzeitlich unter die Schwelle gefallen, am 25. September hat sich eine neue Mehrheit gebildet, und damit begann die Zwei-Wochen-Frist von vorn. Das Amendments-Objekt im validierten Ledger (Ledger-Index 107269984, abgefragt am 27.09.2026 um 12:01 UTC) führt die Mehrheit seit dem 25. September 2026, 14:46:02 UTC. Frühester Aktivierungstermin ist damit der 9. Oktober 2026, 14:46:02 UTC, sofern die Mehrheit hält. Seit dem 25. September 2026, 14:12:51 UTC, läuft dort auch die Frist für die Korrektur fixBatchV1_2, die mit xrpld 3.4.1 kam (Versionshinweis vom 25.09.2026). Wer einen eigenen Knoten betreibt, braucht deshalb Version 3.4.1. Die Abschnitte unten sind auf diesen Stand gebracht.

Frühestens am 9. Oktober 2026 um 14:46:02 UTC schaltet sich am XRP Ledger ein Protokoll-Update selbst scharf: das Batch-Amendment mit der internen Bezeichnung BatchV1_1. Wenn du XRP auf einer Börse oder in einer verwahrten Wallet hältst, musst du dafür nichts tun. Wenn du einen eigenen Knoten betreibst oder einen Dienst gegen einen eigenen Knoten laufen lässt, ist dieser Termin eine harte Frist, nach der dein Server aus dem Netzwerk fällt.

Dieser Text erklärt, was das Amendment ändert, woher das Datum stammt, wie du den Stand selbst nachprüfst und welche Vorbehalte an dem Termin hängen. Alle Zahlen in diesem Artikel stammen aus dem validierten Ledger und aus der Protokolldokumentation, nicht aus Ankündigungen.

Was ein Amendment am XRP Ledger ist und warum es ohne Abschalttermin auskommt

Ein Amendment ist eine Regeländerung am Protokoll des XRP Ledger, über die die vertrauenswürdigen Validatoren des Netzwerks abstimmen, statt dass eine Firma sie ansetzt. Genau darin unterscheidet sich das Verfahren von einem klassischen Hard Fork mit angekündigtem Blockhöhen-Termin: Es gibt keinen Kalendereintrag, den jemand setzt, sondern eine Bedingung, die das Netzwerk selbst erfüllt oder eben nicht.

Die Regel dazu ist in der Protokolldokumentation festgeschrieben und kurz: Ein Amendment braucht die Zustimmung von mehr als 80 Prozent der vertrauenswürdigen Validatoren, und es muss diese Zustimmung zwei Wochen lang durchgehend halten. Erst dann wird es aktiviert. Fällt die Zustimmung in diesen zwei Wochen auch nur zeitweise unter die Schwelle, beginnt die Zählung von vorn.

Für dich als Leser heißt das zweierlei. Erstens ist ein solcher Termin nachprüfbar, weil er im Ledger steht und nicht in einer Pressemitteilung. Zweitens ist er nicht unumstößlich, solange die zwei Wochen laufen. Beides ist bei dem Termin, um den es hier geht, der Kern der Sache.

Was das Batch-Amendment BatchV1_1 technisch ändert

Batch ist ein neuer Transaktionstyp, der mehrere einzelne Transaktionen zu einem Paket bündelt, das gemeinsam abgearbeitet wird. Ein Paket fasst laut Protokollreferenz mindestens zwei und höchstens acht innere Transaktionen zusammen, die auch von verschiedenen Konten stammen dürfen. Bisher musstest du am XRP Ledger jeden Schritt einzeln einreichen und bei jedem einzeln hoffen, dass er durchgeht.

Der praktische Gewinn liegt in der Verbindlichkeit. Wer heute zwei Schritte nacheinander einreicht, etwa eine Freigabe und danach einen Tausch, trägt das Risiko, dass der erste Schritt gelingt und der zweite scheitert. Mit einem Paket lässt sich diese Lücke schließen, weil das Netzwerk die Abarbeitungsregel kennt und durchsetzt.

Muss ich etwas tun, wenn mein XRP auf einer Börse liegt?

Nein. Das ist die häufigste Lage, und sie ist die unaufgeregteste. Liegt dein XRP bei einer Handelsplattform oder in einer verwahrten Wallet, betreibt der Anbieter die Infrastruktur, und die Pflicht zur Aktualisierung liegt bei ihm. Du musst weder umschichten noch verkaufen noch eine Adresse wechseln. Wer aus Sorge vor einem Protokolltermin hektisch Bestände bewegt, erzeugt vor allem Gebühren und im Zweifel einen steuerlich relevanten Vorgang, den er nicht gebraucht hätte.

Sinnvoll ist die Gelegenheit trotzdem für eine ruhige Bestandsaufnahme, die nichts mit dem Termin zu tun hat. Weißt du, bei welchem Anbieter welcher Teil deines Bestands liegt, wie hoch die Auszahlungsgebühr dort ist und ob der Anbieter in der EU beaufsichtigt wird? Diese Fragen sind unabhängig vom Protokolltermin die wichtigeren.

Was du prüfen solltest, wenn du deine XRP selbst verwahrst

Auch bei eigener Verwahrung liegt der Fall meist einfach. Eine Hardware-Wallet speichert deinen privaten Schlüssel und unterschreibt damit Transaktionen; sie spricht das Netzwerk in der Regel über die Server des Wallet-Anbieters an. Die Schlüssel selbst sind von einem Amendment nie betroffen, denn ein Amendment ändert die Regeln der Kette, nicht deine Adresse und nicht deinen Zugang.

Was du tun kannst, ist die Software aktuell zu halten, mit der du auf die Wallet zugreifst, und vor dem Termin einmal zu prüfen, ob deine Wiederherstellungswörter dort liegen, wo du sie vermutest. Das ist Grundhygiene und unabhängig vom 9. Oktober richtig. Wenn du bei der Geräteauswahl noch unschlüssig bist, hilft unser Hardware-Wallet-Vergleich.

Amendment-blocked: Was mit einem veralteten xrpld-Knoten am 9. Oktober passiert

Amendment-blocked ist der Zustand, in den ein Server fällt, der eine aktivierte Protokollregel nicht kennt. Die Protokolldokumentation beschreibt die Folgen unmissverständlich: Ein blockierter Server kann keine Ledger mehr validieren, keine Transaktionen mehr einreichen oder verarbeiten, nicht mehr am Konsens teilnehmen und über künftige Amendments nicht mehr abstimmen.

Entscheidend ist der Satz, der daneben steht: Die Abstimmungskonfiguration eines Servers hat darauf keinen Einfluss. Wer sein xrpld so eingestellt hat, dass es gegen das Amendment stimmt, ist nach der Aktivierung genauso blockiert wie jemand, der dafür gestimmt hat. Blockiert wird allein, wem der Code fehlt, der die neue Regel versteht. Gegen eine aktivierte Mehrheitsentscheidung lässt sich nicht weiterlaufen.

Der Server stürzt dabei nicht ab und wirft keine auffällige Fehlermeldung an die Wand. Er antwortet weiter, nur eben nicht mehr mit gültigen Daten aus der laufenden Kette. Genau das macht diesen Zustand für Dienste gefährlich, die im Hintergrund gegen einen eigenen Knoten abfragen: Die Anwendung wirkt gesund und liefert einen Datenstand, der stehengeblieben ist.

Woher das Datum 9. Oktober 2026 stammt und wie es zustande kommt

Der Termin ist ausgerechnet, nicht abgeleitet und nicht geschätzt. Im validierten Ledger liegt ein Objekt, das den Zustand aller Amendments führt. Darin steht ein Feld Majorities, und dort wird für jedes Amendment, das die Schwelle erreicht hat, der Zeitpunkt vermerkt, ab dem die Zwei-Wochen-Frist läuft.

Diese Redaktion hat das Objekt erstmals am 18. September 2026 abgefragt (Ledger-Index 107058182). Das Feld Majorities enthielt damals genau einen Eintrag: das Amendment mit der Kennung 9F287AED3CDB50A7BD1ACEC24296A30C9B5230CCD136219317AC790E3B884377 und dem CloseTime-Wert 842796401. Bei der erneuten Abfrage am 27. September 2026 gegen 12:01 UTC (Ledger-Index 107269984) stand für dieselbe Kennung der Wert 843662762. Die Mehrheit war also zwischenzeitlich gefallen und neu gebildet worden.

Die Zeitrechnung des XRP Ledger beginnt am 1. Januar 2000. Der alte Wert entspricht dem 15. September 2026, 14:06:41 UTC, und hätte zur Aktivierung am 29. September geführt. Der neue Wert ergibt den 25. September 2026, 14:46:02 UTC als Beginn der Frist. Zwei Wochen später liegt der 9. Oktober 2026, 14:46:02 UTC. Die Gegenprobe über die Abfrage feature lieferte am 27. September für dieselbe Kennung weiter den Namen BatchV1_1 sowie die Werte enabled: false und supported: true. Das Amendment ist dem Netzwerk also bekannt und unterstützt, aber noch nicht aktiv. Im selben Objekt steht seit dem 25. September 2026, 14:12:51 UTC, auch die Korrektur fixBatchV1_2 (Kennung beginnend mit 14A2B45E48A4), frühestens aktiv am 9. Oktober 2026, 14:12:51 UTC.

Wie du den Stand des Amendments selbst nachprüfst

Du brauchst dafür keinen eigenen Knoten. Ein öffentlicher Endpunkt des XRP Ledger beantwortet die Frage mit einer einzigen Anfrage. Wer mit der Kommandozeile umgehen kann, schickt eine feature-Anfrage mit der oben genannten Kennung an einen öffentlichen Knoten und liest drei Felder aus der Antwort:

• enabled: Steht hier false, ist das Amendment noch nicht aktiv. Springt der Wert auf true, ist die Aktivierung erfolgt.
• supported: Steht hier true, kennt die Software des befragten Knotens die Regel bereits. Steht hier false, wird genau dieser Knoten bei der Aktivierung blockiert.
• majority: Der Zeitstempel, ab dem die Zwei-Wochen-Frist läuft. Verschwindet dieses Feld wieder, ist die Mehrheit gefallen und der Countdown zurückgesetzt.

Genau dieser dritte Punkt ist der Grund, warum du den Stand kurz vor dem Termin noch einmal anschauen solltest, statt das Datum abzuschreiben und abzuhaken. Für den eigenen Knoten gilt derselbe Weg mit einem wichtigen Unterschied: Frage feature gegen deinen Server ab, nicht gegen einen fremden. Nur die Antwort deines eigenen Knotens sagt dir etwas über deinen eigenen Knoten.

Welche Software-Version die neue Regel mitbringt

Die Serversoftware des XRP Ledger heißt xrpld und wird als offene Software veröffentlicht. Die aktuelle Fassung ist 3.4.1, veröffentlicht am 25. September 2026 mit der Korrektur fixBatchV1_2, die innere Batch-Transaktionen mit falscher Hülle abweist. Davor standen 3.4.0 vom 17. September und 3.3.0 vom 6. August 2026 (Daten aus dem Versionshinweis zu 3.4.1 und dem offiziellen Quellcode-Archiv). Laut Versionshinweis wird ein Knoten ohne 3.4.1 mit der Aktivierung von fixBatchV1_2 blockiert.

Eine Versionsnummer aus einem Artikel abzuschreiben ist trotzdem der schlechtere Weg. Die belastbare Auskunft gibt dir dein eigener Server über das Feld supported: Es beantwortet die Frage, ob die laufende Software die Regel tatsächlich kennt. Welche Version du zu fahren glaubst, spielt dabei keine Rolle. Frage es für BatchV1_1 und für fixBatchV1_2 ab. Läuft dort bei einem der beiden false, hilft nur ein Update auf 3.4.1, und zwar vor dem 9. Oktober.

Warum der Termin unter Vorbehalt steht

Die Zwei-Wochen-Frist läuft, solange die Zustimmung über 80 Prozent bleibt. Fällt sie darunter, wird der Zähler zurückgesetzt, und der 9. Oktober ist hinfällig, so wie es dem ursprünglich errechneten 29. September ergangen ist. Das ist keine theoretische Klausel, sondern der eingebaute Sicherheitsmechanismus des Verfahrens: Er gibt den Validatoren bis zuletzt die Möglichkeit, eine Änderung zu stoppen, wenn zwischenzeitlich ein Problem auffällt.

Für deine Planung folgt daraus eine einfache Haltung. Behandle den 9. Oktober als die Frist, auf die du dich vorbereitest, und nicht als Ereignis, dessen Eintreten schon feststeht. Wer einen Knoten aktualisiert, verliert nichts, falls der Countdown zurückgesetzt wird. Wer die Aktualisierung aufschiebt, weil der Termin ja noch kippen könnte, hat im umgekehrten Fall ein abgeschnittenes System.

Die vier Modi eines Batch-Pakets und was sie im Alltag bedeuten

Ein Paket bekommt beim Einreichen einen Modus mitgegeben, der festlegt, wie das Netzwerk mit Fehlschlägen umgeht. Die Protokollreferenz nennt vier:

• AllOrNothing: Jede einzelne Transaktion im Paket muss gelingen. Scheitert eine, scheitert das ganze Paket. Das ist der Modus für Abläufe, die nur vollständig sinnvoll sind.
• OnlyOne: Sobald die erste Transaktion erfolgreich war, werden die übrigen übersprungen. Damit lassen sich Alternativen einreichen, von denen genau eine greifen soll.
• UntilFailure: Die Transaktionen laufen der Reihe nach, bis eine scheitert; alles danach entfällt. Das passt zu Abläufen, die aufeinander aufbauen.
• Independent: Alle Transaktionen werden unabhängig voneinander abgearbeitet, unabhängig davon, ob einzelne scheitern. Das ist die reine Bündelung ohne Verkettung.

Als Halter wirst du diese Modi selten selbst setzen. Sichtbar wird der Unterschied dort, wo Anwendungen ihn nutzen: in Wallet-Oberflächen, die mehrere Schritte zu einer Bestätigung zusammenfassen, und in Handelsanwendungen, bei denen ein halb ausgeführter Ablauf bisher der unangenehmste Fall war.

Was Dienste, Wallet-Anbieter und Zahlungsabwickler jetzt klären sollten

Betroffen ist jeder, der nicht über einen fremden Anbieter, sondern über eigene Infrastruktur auf das XRP Ledger zugreift. Dazu zählen Zahlungsdienste, Handelsanwendungen, Buchhaltungswerkzeuge mit eigenem Abruf und jede Wallet, deren Anbieter einen eigenen Knoten betreibt. Für diese Gruppe sind drei Fragen vor dem Termin zu beantworten.

1. Läuft der Abruf gegen einen eigenen Knoten oder gegen einen fremden Endpunkt? Bei einem fremden Endpunkt liegt die Pflicht beim Betreiber, und du solltest dort nachfragen statt selbst zu handeln.
2. Meldet der eigene Knoten für BatchV1_1 den Wert supported: true? Wenn nicht, steht ein Update an, mit dem üblichen Vorlauf für Test und Wartungsfenster.
3. Fällt ein stehengebliebener Datenstand in der Überwachung überhaupt auf? Ein blockierter Knoten antwortet weiter. Eine Überwachung, die nur auf Erreichbarkeit prüft, merkt davon nichts. Wer den Abstand zwischen dem letzten validierten Ledger und der aktuellen Zeit überwacht, merkt es sofort.

Die dritte Frage ist erfahrungsgemäß die, an der es hängt. Ein Ausfall, der sich als normaler Betrieb tarnt, wird spät entdeckt, und in der Zwischenzeit arbeiten Buchungen und Anzeigen mit alten Daten weiter.

Wie dieser Termin in die Reihe der bisherigen Amendments passt

Das Verfahren ist am XRP Ledger Routine und läuft mehrmals im Jahr ab. Zuletzt haben wir am 9. September 2026 die Aktivierung des vorangegangenen Amendments beschrieben; wer den Ablauf noch einmal von vorn nachlesen will, findet ihn in unserem Beitrag dazu, welche Punkte an Wallet, Node und Position zu prüfen sind. Die Mechanik ist dieselbe, nur hängt diesmal ein konkretes Datum und eine offene Bedingung daran.

Für die Einordnung des Netzwerks insgesamt bleibt der Blick auf das, was darauf gebaut wird, aussagekräftiger als jeder einzelne Protokollschritt. Ein Beispiel aus dem Februar 2026 ist der Euro-Stablecoin der Société Générale, der auf dem XRP Ledger ausgegeben wird. Solche Anwendungen sind der Grund, warum verbindliche Transaktionspakete überhaupt gefragt sind: Wer Zahlungsabläufe automatisiert, will keine halb ausgeführten Ketten.

XRP Ledger Batch-Amendment: Was du daraus mitnimmst

1. Liegt dein XRP bei einem Anbieter, tust du nichts. Nutze den Termin höchstens für eine ruhige Prüfung, ob der Anbieter noch zu dir passt: Die Übersicht der besten Krypto-Börsen stellt Gebühren und Auszahlungswege nebeneinander.
2. Verwahrst du selbst, prüfe Zugang und Wiederherstellung, nicht das Protokoll. Deine Schlüssel sind von einem Amendment nicht betroffen. Welches Gerät dazu taugt, zeigt der Hardware-Wallet-Vergleich.
3. Betreibst du einen eigenen Knoten, frage vor dem 9. Oktober feature für BatchV1_1 und fixBatchV1_2 ab. Steht dort bei einem der beiden supported: false, aktualisiere auf xrpld 3.4.1. Wer nebenbei den Überblick über seine Bestände und deren steuerliche Erfassung braucht, findet die Werkzeuge dafür unter den Krypto-Steuer-Tools und Portfolio-Trackern.

Die Primärquellen zu diesem Artikel: die Beschreibung des Amendment-Verfahrens und die Protokollreferenz zur Batch-Transaktion, beide in der offiziellen Dokumentation des XRP Ledger.

(Stand: 27. September 2026, erste Fassung vom 18. September 2026. Dieser Beitrag ist keine Anlageberatung. Kurse und Gebührenmodelle ändern sich; prüfe die Konditionen vor jedem Kauf beim Anbieter selbst.)