Batch-Amendment: 30 von 35 Stimmen, frühester Start am 9. Oktober

Nachtrag vom 27. September 2026: Das Batch-Upgrade des XRP Ledgers kommt frühestens am 9. Oktober 2026 gegen 14:46 UTC und damit später als am erwarteten 29. September. Laut CoinDesk fiel die Zustimmung der Validatoren kurzzeitig unter die Schwelle, die Aktivierung verschiebt sich dadurch um mindestens zehn Tage. Inzwischen steht die Mehrheit wieder: XRPSCAN zählt für BatchV1_1 30 Ja-Stimmen bei 35 Validierungen, Stand 27. September 2026, 04:11 UTC. Der neue Termin gilt nur, wenn diese Zustimmung bis dahin durchgehend über der Schwelle bleibt.

Batch bringt eine neue Transaktionsart auf den Ledger, die Batch-Transaktion: Ein Konto reicht damit bis zu 8 innere Transaktionen gemeinsam ein, was etwa atomare Tauschgeschäfte ermöglicht. Die 8 ist der Höchstwert je Batch-Transaktion. Handeln müssen bis zum Termin nur Betreiber eigener Server, denn mit xrpld 3.4.1 gibt es ein Notfall-Release mit einem neuen Fix für Batch.

Die Mehrheit steht seit dem 25. September, Batch kann frühestens am 9. Oktober starten

Der neue Termin lässt sich aus den XRPSCAN-Daten nachrechnen. BatchV1_1 hält dort seit dem 25. September 2026, 14:46 UTC, wieder eine Mehrheit. Zwei Wochen später ist der 9. Oktober gegen 14:46 UTC erreicht.

Die Uhrzeit ist ein Näherungswert, weil Amendments an sogenannten Flag-Ledgern aktiviert werden, die etwa alle 15 Minuten anfallen; die XRPL-Dokumentation zu Amendments beschreibt diesen Takt. Wichtiger als die Minute ist die Bedingung: Der 9. Oktober ist der früheste Zeitpunkt, und er gilt nur bei durchgehender Zustimmung über der Schwelle.

Wie viel Luft die Mehrheit hat, zeigt der Abstand zur Schwelle. Am 27. September um 04:11 UTC lag BatchV1_1 mit 30 Ja-Stimmen bei 35 Validierungen zwei Stimmen über der Schwelle von 28. Bleibt die Zustimmung bis zum 9. Oktober durchgehend über dieser Schwelle, ist Batch zum frühesten Termin an der Reihe.

Fünf Gegenstimmen und eine Standardstimme Nein: so steht die Abstimmung

Wer in der Verschiebung ein Misstrauensvotum gegen Batch vermutet, findet im Stimmenstand zwei Anhaltspunkte. XRPSCAN führte am 27. September um 04:11 UTC 5 Validatoren mit einer Gegenstimme zu BatchV1_1. Zusammen mit den 30 Ja-Stimmen ergibt das genau die 35 Validierungen, die Schwelle liegt bei 28.

Der zweite Anhaltspunkt: Die Seite Known Amendments nennt für BatchV1_1 als Standardstimme der neuesten stabilen Version Nein (Stand Abruf 27. September 2026). Diese Standardstimme ist die Voreinstellung der Software. Wie die Validatoren tatsächlich abstimmen, zeigt der XRPSCAN-Stand mit 30 Ja-Stimmen.

Die Gegenstimmen stehen dort als bloße Einträge ohne Begründung. Aussagekräftig ist deshalb der Verlauf bis zum 9. Oktober: Bleibt die Zustimmung durchgehend über der Schwelle, ist der früheste Termin erreichbar.

Notfall-Release 3.4.1: Serverbetreiber aktualisieren, Halter beobachten

Für Batch gibt es außerdem einen neuen Fix. xrpld 3.4.1 ist ein Notfall-Release gegen sicherheitsrelevante Probleme im XRPL-Protokoll und führt das Amendment fixBatchV1_2 mit Standardstimme Ja ein. Der Fix lehnt innere Batch-Transaktionen mit falschem Wrapper ab, also mit falscher Hülle.

Nach Angaben des XRPL-Blogs hat fixBatchV1_2 bereits die Unterstützung einer Supermehrheit der Validatoren. Die Entwickler erwarten die Aktivierung voraussichtlich am 9. Oktober 2026.

Den Quellcode von 3.4.1 halten die Entwickler wegen der Sicherheitsrelevanz des Fixes vorerst zurück. Er soll zu einem späteren Termin zusammen mit einer Retrospektive erscheinen.

Wenn du einen eigenen XRP-Ledger-Server betreibst, ist die Lage eindeutig: Die Entwickler raten im XRPL-Blog, so bald wie möglich auf xrpld 3.4.1 zu aktualisieren, damit der Server ohne Unterbrechung weiterläuft.

Der Grund ist eine Bedingung: Wird fixBatchV1_2 aktiviert, werden xrpld-Server ohne Version 3.4.1 amendment-blockiert und können nicht mehr mit dem Netzwerk synchron bleiben. Die XRPL-Dokumentation nennt den Ausweg: Ein Update auf die neueste xrpld-Version löst eine solche Blockade, die eigene Stimmkonfiguration schützt davor nicht.

Die Aufforderung richtet sich an Betreiber eigener Server. Hältst du XRP in einer Wallet oder bei einer Börse, ist der 9. Oktober für dich ein Termin zum Beobachten.

Zur Einordnung: BatchV1_1 ist selbst schon ein Ersatz. Es kam mit xrpld 3.3.0 und löst das ursprüngliche Batch-Amendment ab, das in Version 3.1.1 wegen eines Fehlers deaktiviert wurde. Die Vorgeschichte beider zurückgeholten Amendments steht in der Analyse zu xrpld 3.3.0 und den zwei zurückgeholten Amendments.

Ein am 19. Februar 2026 gemeldeter Fehler im ursprünglichen Batch-Amendment erlaubte, innere Transaktionen im Namen fremder Konten ohne deren private Schlüssel auszuführen (Offenlegungsbericht Februar 2026). Batch war damals noch in der Abstimmung und im Mainnet inaktiv, laut Bericht waren keine Gelder gefährdet. BatchV1_1 wartet laut XRPSCAN am 27. September weiterhin auf die Aktivierung.

PermissionDelegation: frühestens am 8. Oktober, mit einer Stimme Vorsprung

Das zweite zurückgeholte Amendment, PermissionDelegationV1_1, erlaubt Konten, einzelne Berechtigungen an andere Konten zu delegieren. Es ersetzt die ursprüngliche Fassung, in der ein kritischer Fehler steckte. Dieser am 15. September 2025 gemeldete Fehler ermöglichte, anderen Konten Transaktionsgebühren anzulasten und so deren XRP abzuziehen; die Funktion war damals im Mainnet inaktiv (Offenlegungsbericht September 2025).

Am 27. September 2026 um 04:11 UTC zählte XRPSCAN für PermissionDelegationV1_1 29 Ja-Stimmen bei 35 Validierungen und derselben Schwelle von 28. Der Vorsprung beträgt damit eine Stimme, die Aktivierung steht noch aus.

Die Mehrheit besteht seit dem 24. September 2026, 21:25 UTC. Hält die Zustimmung durchgehend, ist eine Aktivierung frühestens am 8. Oktober 2026 gegen 21:25 UTC möglich. Laut CoinDesk hatte das Amendment seine Mehrheit am 23. September verloren und einen Tag später zurückgewonnen.

Woran du erkennst, ob die Termine halten

Den Ausgang verfolgst du im Live-Status der XRPL-Amendments. Halten beide Mehrheiten durchgehend, ist PermissionDelegationV1_1 frühestens am 8. Oktober gegen 21:25 UTC an der Reihe und Batch frühestens am 9. Oktober gegen 14:46 UTC. Wie sich neue Funktionen danach im Netzwerk zeigen, siehst du in den XRP Insights, mehr zu Amendments, die auf Stimmen warten, in der Analyse zum XRP Ledger im zweiten Quartal 2026.

Unterm Strich: Batch hält wieder eine Mehrheit und kann frühestens am 9. Oktober aktiv werden, handeln müssen bis dahin nur Serverbetreiber. Wofür Batch gebraucht wird, deutet RippleX-Entwicklungschef Ayo Akinyele an: Laut CoinDesk sagte er zu einem früheren, nicht genannten Zeitpunkt, einige Projekte würden bereits mit Blick auf Batch gebaut.

Offen bleiben die Ursache für das kurze Unterschreiten der Schwelle, von dem CoinDesk berichtet, sowie Namen und Starttermine der Projekte, die Akinyele meint. Welche Schwachstelle 3.4.1 genau schließt, zeigen erst der Quellcode und die angekündigte Retrospektive, für die es noch keinen Termin gibt.