Am 8. September 2026 hielten die Validatoren des XRP Ledger das Amendment BatchV1_1 bei 24 von 35 Stimmen, was 68,57 % Unterstützung entspricht – deutlich unter der Supermehrheit von mehr als 80 %, die für den Beginn des zweiwöchigen Aktivierungsfensters erforderlich ist. Zwar wird BatchV1_1 mit der rippled-Software ausgeliefert, doch das bedeutet nicht, dass es auf dem XRP Ledger aktiv ist. Die mit dem Upgrade oft verbundenen DeFi- und Funktionsgewinne bleiben unbestätigt, bis die Validatoren diese Hürde nehmen.

The XRP Ledger's Batch amendment is now at 68% support. We could see Batch going live by the end of this month. Batch will unlock a lot of new use cases for the XRP ecosystem. You can track progress here pic.twitter.com/uoo2Q5kf0X — moonkie (@xmoonkie), September 7, 2026

BatchV1_1 bleibt unter der Aktivierungsschwelle

BatchV1_1 wurde mit rippled 3.3.0 ausgeliefert, das am 6. August 2026 veröffentlicht wurde – doch die Aufnahme in den Code und die Aktivierung auf der Mainnet sind auf dem XRP Ledger zwei getrennte Ereignisse. Anders als Netzwerke, die Protokolländerungen über Hard Forks oder Off-Chain-Governance-Abstimmungen umsetzen, gehen Änderungen auf dem XRPL automatisch per Validatorkonsens live: Sobald ein Amendment über den erforderlichen Zeitraum Mehrheitsunterstützung hält, wird es auf jedem Server mit kompatibler Software aktiviert, ohne koordinierte Chain-Split. Laut XRPScan-Daten lag das Amendment beim Stand vom 8. September bei 68,57 % Unterstützung innerhalb der Standard-Unique-Node-List.

Für die Aktivierung sind mehr als 80 % Zustimmung an 14 aufeinanderfolgenden Tagen erforderlich; dieser Countdown hat noch nicht begonnen. Bei der aktuellen Konfiguration von 35 Validatoren sind mindestens 29 Ja-Stimmen nötig, um die Schwelle zu erreichen – die genaue Zahl kann sich jedoch verschieben, wenn sich der Kreis der teilnehmenden Validatoren ändert. Die Unterstützung kann während des Countdowns auch wieder unter 80 % fallen, was den Zeitmesser vollständig zurücksetzt.

Version 3.3.0 war kein Release mit nur einer Funktion – sie führte zusätzlich ConfidentialTransfer, DynamicMPT, Sponsor und PermissionDelegationV1_1 ein und bündelte BatchV1_1 in ein breiteres Paket institutionengerichteter Upgrades. Anleger, die das Wachstum des XRP Ledger und ETF-getriebene Zuflüsse verfolgen, sollten diese Amendments als parallele Handlungsstränge betrachten, von denen jeder seine eigene Validator-Supermehrheit benötigt, bevor irgendeine Funktion live geht.

Was Batch-Transaktionen nach Aktivierung ermöglichen könnten

Sobald aktiv, könnte eine Batch-Transaktion bis zu acht innere Transaktionen in einer einzigen äußeren Transaktion bündeln – mit vier Ausführungsmodi: „All or nothing“, bei dem jede innere Transaktion erfolgreich sein muss; „Only one“, das die erste erfolgreiche Operation anwendet; „until failure“, das Transaktionen verarbeitet, bis eine fehlschlägt; und „Independent“, das jede enthaltene Transaktion unabhängig vom Ergebnis ausführt.

Mögliche Anwendungsfälle umfassen atomare Token-Swaps, NFT-Minting gekoppelt mit einem Angebot, gebündelte Plattformgebühren und koordinierte Aktionen über mehrere Konten hinweg – sofern jedes beteiligte Konto die gesamte Sammlung autorisiert. Jede committete innere Transaktion würde eigene Metadaten plus eine Referenz auf ihren übergeordneten Batch behalten – eine Struktur, die die externe Koordinationsinfrastruktur reduzieren soll, die Anwendungen derzeit für mehrstufige Aktionen benötigen.

Es handelt sich weiterhin um konzipierte Fähigkeiten, nicht um live geschaltete Funktionen. Die Effizienzgewinne (und jede daraus resultierende Belebung von Anwendungsfällen wie RLUSD-Settlement und Tokenized-Finance-Flüsse auf dem XRPL) hängen sowohl von der Aktivierung durch die Validatoren als auch von der anschließenden Unterstützung durch Wallets und SDKs ab.

Sicherheitshistorie hinter dem Ersatz-Amendment

BatchV1_1 ist nicht der ursprüngliche Batch-Code, sondern eine Neuauflage. Die Entwickler deaktivierten das ursprüngliche Amendment im Februar 2026, nachdem Pranamya Keshkamat und das Apex-Sicherheitstool von Cantina AI eine kritische Schwäche in der Verifizierungslogik der Batch-Signierer identifiziert hatten. Der Fehler hätte einem Angreifer ermöglichen können, Autorisierungsprüfungen für einige Teilnehmer zu umgehen und unbefugte Transaktionen vom Konto eines Opfers einzureichen.

Entscheidend ist: Die verwundbare Version wurde auf der Mainnet nie aktiviert, und XRPL Labs erklärte, dass keine Nutzergelder gefährdet waren. Rippled 3.1.1 stufte das ursprüngliche Batch-Amendment als nicht unterstützt ein; der Ersatz behebt den Early-Exit-Fehler, ergänzt Autorisierungssicherungen und verengt die Signierer-Prüfungen, wobei ein unabhängiges Audit BatchV1_1 vor der Aufnahme in 3.3.0 überprüfte.

Warum dies noch kein XRP-Preiskatalysator ist

Diese Nachricht löste keine nennenswerte Kursbewegung aus, und das dürfte sich kaum ändern, solange die Unterstützung bei 68,57 % liegt. Das Amendment verändert die Transaktionsfunktionalität auf dem Ledger, nicht die Angebots- oder Emissionsregeln von XRP – es hat also keine direkte geldpolitische Dimension für Trader, die XRPs kurzfristiges Breakout-Potenzial bewerten.

Jede Steigerung des XRPL-Transaktionsvolumens, der DeFi-Aktivität oder der Token-Nachfrage durch Batch bleibt zukunftsgerichtet – abhängig davon, dass die Aktivierung die Supermehrheit erreicht und anschließend Wallets, Börsen und DeFi-Protokolle die Funktion tatsächlich integrieren. Bis dahin ist Batch eine Infrastrukturgeschichte und kein bestätigter Bewertungskatalysator.

Der nächste Meilenstein: eine anhaltende Validator-Supermehrheit

Der nächste bestätigte Kontrollpunkt für die XRPL-Validatoren ist das Überschreiten von 80 % Unterstützung. Erst danach beginnt das Ledger, den verpflichtenden 14-tägigen durchgehenden Mehrheitszeitraum aufzuzeichnen. Die Unterstützung muss die gesamte Dauer über der Schwelle bleiben, sonst wird die Uhr auf null zurückgesetzt.

Eine Aktivierung Ende September war beim Stand vom 8. September mathematisch möglich, doch nichts ist terminiert. Knotenbetreiber müssen zunächst Software mit BatchV1_1-Unterstützung ausführen, bevor sie dafür stimmen können; zudem wies XRPL die Clio-Betreiber gesondert an, auf Version 2.8.0 zu aktualisieren, damit die API-Infrastruktur neue Transaktions- und Ledger-Formate verarbeiten kann, falls das Amendment tatsächlich aktiviert wird.

Quelle: https://icobench.com/news/xrp-news-batchv1-1-xrp-ledger-vote/