Die XRP-Ledger-Entwickler haben am 6. August die Version 3.3.0 von xrpld veröffentlicht und damit mehrere Protokolländerungen näher an eine mögliche Aktivierung im Hauptnetz gebracht.
Zusammenfassung
- XRPL 3.3.0 führt Protokollcode ein, aber die Zustimmung der Validatoren bleibt vor einer Aktivierung im Hauptnetz erforderlich.
- ConfidentialTransfer würde MPT-Salden und Transferbeträge abschirmen und gleichzeitig autorisierten Parteien den Compliance-Zugriff erhalten.
- BatchV1_1 stellt die atomare Transaktionsfunktionalität wieder her, nachdem eine frühere Version aufgrund eines Sicherheitsfehlers gestoppt wurde.
- Sponsor würde es Dritten ermöglichen, Gebühren und Reserven zu übernehmen, während die Benutzer die volle Kontrolle über ihr Konto behalten.
- DynamicMPT würde es Emittenten ermöglichen, ausgewählte Token-Eigenschaften später zu ändern, um sich entwickelnde Geschäfts- und Compliance-Anforderungen zu unterstützen.
Die offizielle GitHub-Veröffentlichung bestätigt Arbeiten an ConfidentialTransfer, BatchV1_1, Sponsor und DynamicMPT sowie Fehlerbehebungen und andere Protokolländerungen. Die Software-Veröffentlichung selbst aktiviert diese Funktionen nicht im Netzwerk.
Die Unterscheidung ist wichtig, weil einige Berichte sechs Upgrades als bereits live beschreiben. Im Rahmen des XRP-Ledger-Änderungsprozesses erfordern neue Protokollfunktionen die Unterstützung der Validatoren vor der Aktivierung. Eine Änderung muss zwei aufeinanderfolgende Wochen lang mehr als 80 % Unterstützung von vertrauenswürdigen Validatoren aufrechterhalten, bevor sie in Kraft tritt.
XRP Ledger 3.3.0 fügt Datenschutz- und atomare Transaktionswerkzeuge hinzu
ConfidentialTransfer soll Datenschutz für Multi-Purpose-Tokens (MPTs) bieten. Die XRPL-Dokumentation besagt, dass die Änderung Kryptografie verwendet, um einzelne Salden und Transferbeträge abzuschirmen, während Mechanismen erhalten bleiben, die autorisierten Parteien, einschließlich Emittenten oder Prüfern, die für die Compliance erforderlichen Informationen überprüfen lassen.
Die Funktion unterliegt weiterhin der Aktivierung durch eine Änderung, daher sollten private MPT-Transfers noch nicht als aktiv im XRPL-Hauptnetz beschrieben werden.
BatchV1_1 ist eine weitere wichtige Komponente. Der XLS-56-Standard ermöglicht es, mehrere Transaktionen zu bündeln und gemeinsam zu verarbeiten, einschließlich Transaktionen, die verschiedene Konten betreffen. Die atomare Ausführung kann Abwicklungsworkflows unterstützen, bei denen mehrere Aktionen gemeinsam erfolgreich sein müssen, anstatt dass ein Teil abgeschlossen wird, während ein anderer fehlschlägt.
Überarbeitete Funktionen folgen auf frühere Sicherheitserkenntnisse
Batch hat eine wichtige Geschichte. Eine frühere Version wurde vor der Aktivierung im Hauptnetz deaktiviert, nachdem ein Sicherheitsproblem in der Transaktionssignierungslogik entdeckt wurde. Die XRPL Foundation bewegte sich später auf BatchV1_1 als korrigierten Ersatz. Wie zuvor in der XRPL-Sicherheitsberichterstattung berichtet, haben Entwickler die formelle Überprüfung bei kürzlichen Upgrades verstärkt.
Permission Delegation folgte einem ähnlichen Weg. XRPL gab im September 2025 bekannt, dass ein Fehler in der früheren Änderung es einer unbefugten Transaktion unter bestimmten Bedingungen hätte ermöglichen können, Gebühren einem anderen Konto zu belasten. Validatoren wurde geraten, mit Nein zu stimmen, und die anfällige Funktion wurde nie aktiviert. PermissionDelegationV1_1 wurde als Ersatz entwickelt.
Das überarbeitete Konzept ermöglicht es einem Konto, definierte Transaktionsberechtigungen zu erteilen, ohne seinen Haupt-Privatschlüssel herauszugeben, und unterstützt operative Wallets mit begrenzter Autorität.
Sponsor und DynamicMPT zielen auf institutionelles Onboarding ab
Sponsor, basierend auf XLS-68, ist darauf ausgelegt, dass ein anderes Konto Transaktionsgebühren oder Reserveanforderungen übernimmt, während der Benutzer die Kontrolle über das Konto und die Schlüssel behält. Die Funktion könnte es Anwendungen ermöglichen, Benutzer zu onboarden, ohne dass diese XRP ausschließlich zur Deckung der Netzwerkkosten erwerben müssen. Der XLS-68-Vorschlag unterstützt ausdrücklich Gebühren- und Reserve-Sponsoring, während die Schlüsselkontrolle des Benutzers erhalten bleibt.
DynamicMPT zielt auf Token-Emittenten ab. Der XLS-94-Vorschlag ermöglicht es Emittenten, bei der Erstellung eines Tokens ausgewählte MPT-Eigenschaften als änderbar zu kennzeichnen und diese zulässigen Felder später zu aktualisieren. Der Standard soll sich ändernden Geschäfts- oder Compliance-Anforderungen gerecht werden, ohne dass jede Token-Eigenschaft frei bearbeitbar wird.
Zusammen passen diese Funktionen zu XRPLs wachsendem Fokus auf tokenisierte Finanzen. In der zugehörigen Tokenisierungsberichterstattung berichtete crypto.news, dass JPMorgan, Mastercard, Ondo Finance und Ripple eine tokenisierte Treasury-Einlösung unter Verwendung von XRPL getestet haben.
Nicht jedes zitierte Upgrade gehört zur Version 3.3.0
Eine Korrektur ist bezüglich des weit verbreiteten Rahmens der "sechs Upgrades" erforderlich. fixCleanup3_2_0 gehört zum früheren xrpld-3.2.0-Zyklus, nicht zum neu veröffentlichten 3.3.0-Funktionspaket. Der 3.3.0-GitHub-Changelog zeigt stattdessen Arbeiten rund um LendingProtocolV1_1 und eine separate fixCleanup3_3_0-Spur neben den Hauptfunktionen.
Die Veröffentlichung sollte daher nicht als sechs gleichzeitig verfügbare abgeschlossene Funktionen gelesen werden. Es ist ein Server-Software-Meilenstein, der Validatoren und Betreibern den für Änderungsentscheidungen erforderlichen Code liefert. Einzelne Änderungen können unterschiedliche Abstimmungszeitpläne haben und möglicherweise nicht aktiviert werden, wenn die Unterstützung unter die erforderliche Schwelle fällt.
Dieser Governance-Prozess war schon früher von Bedeutung. Die ursprünglichen Batch- und Permission-Delegation-Änderungen wurden gestoppt, nachdem vor der Mainnet-Aktivierung Fehler identifiziert wurden, was zeigt, dass die Aufnahme in Software oder Validator-Abstimmungen nicht dasselbe ist wie die Produktionsbereitstellung.
Was als Nächstes für XRPL-Validatoren passiert
Node-Betreiber müssen nun Version 3.3.0 bewerten und entscheiden, ob sie upgraden und einzelne Änderungen unterstützen. Genaue Aktivierungstermine hängen von der Validator-Abstimmung ab, nicht von der Software-Veröffentlichung am 6. August. Die Änderungsregeln von XRPL erfordern, dass die Supermehrheit zwei Wochen lang kontinuierlich besteht.
Für XRP-Inhaber ist die unmittelbare Änderung technischer als monetärer Natur. Version 3.3.0 erweitert den potenziellen Werkzeugkasten des Netzwerks für Datenschutz, mehrstufige Abwicklung, delegierte Autorität, gesponsertes Onboarding und konfigurierbare Token-Ausgabe, aber nichts davon garantiert eine höhere XRP-Nachfrage oder Preissteigerung.
Die nächsten überprüfbaren Meilensteine werden die Validator-Übernahme von 3.3.0, die Unterstützungsniveaus für Änderungen und die geplanten Aktivierungstermine sein. Bis diese Schwellenwerte erreicht sind, sollten die neuen Funktionen als in der Knotensoftware veröffentlicht und in der Governance befindlich beschrieben werden, nicht als vollständig aktive XRP-Ledger-Mainnet-Funktionen.
Validator-Entscheidungen, nicht Veröffentlichungsmarketing, werden bestimmen, wann jede Funktion im Mainnet nutzbar wird.
