Ein Community-Audit-Wettbewerb im Wert von 550.000 US-Dollar deckte zwei kritische Schwachstellen in XRP-Ledger-Funktionen auf, die Benutzerkonten ohne private Schlüssel hätten leeren können. Die Ergebnisse zeigen, wie sich Ripples Modell „Audit vor Veröffentlichung“ deutlich von der in der breiteren Krypto-Branche üblichen Praxis „Erst ausnutzen, dann patchen“ unterscheidet.
Zusammenfassung
- Sherlocks zweiwöchiger Audit-Wettbewerb, der am 13. April 2026 eröffnet wurde, deckte 96 gültige Schwachstellen in fünf vorgeschlagenen XRP-Ledger-Änderungen auf, darunter 2 kritische und 6 schwerwiegende Fehler, bevor eine davon im Hauptnetz (Mainnet) landete.
- Ripple zahlte 309.000 US-Dollar in RLUSD-Prämien aus einem Preispool von 550.000 US-Dollar – die erste Zusammenarbeit zwischen Sherlock und Ripple und einer der größten Audit-Wettbewerbe des Jahres 2026.
- Der schwerwiegendste Befund war ein Fehler bei der Signaturprüfung in der Batch-Änderung, der es Angreifern ermöglicht hätte, Transaktionen von jedem Konto auszuführen, ohne dessen private Schlüssel zu besitzen. Er wurde erstmals am 19. Februar 2026 von dem Forscher Pranamya Keshkamat und Cantinas KI-Tool Apex identifiziert.
- Ein separater kritischer Fehler in der Berechtigungsdelegierung (Permission Delegation) ermöglichte es böswilligen Akteuren, XRP-Guthaben durch wiederholte Gebührenbelastungen bei ungültigen delegierten Transaktionen stillschweigend abzuziehen, da der Code Berechtigungen vor der Überprüfung von Signaturen prüfte.
- DeFi-Exploits überstiegen allein in den ersten fünf Monaten des Jahres 2026 840 Millionen US-Dollar bei mehr als 50 Vorfällen – ein Anstieg von 70 % im Jahresvergleich – und 70 % der ausgenutzten Verträge waren geprüft worden, es fehlte jedoch an Überwachung nach der Bereitstellung.
XRP Ledger Version 3.3.0 wurde am 6. August 2026 ausgeliefert und enthielt fünf vorgeschlagene Änderungen sowie einen gebündelten Bereinigungspatch. Auf dem Papier sah es nach einer routinemäßigen Infrastrukturveröffentlichung aus. Darunter stellte das Update den Abschluss eines sechsmonatigen Sicherheitsparcours dar, der zwei kontenentleerende Fehler aufdeckte, zwei gesamte Feature-Implementierungen von Grund auf neu schrieb und Hunderttausende von Dollar an externe Forscher zahlte, die Probleme fanden, die das interne Team übersehen hatte. Der Prozess wirft eine pointierte Frage für die breitere Blockchain-Branche auf: Wenn Ripple kritische Fehler vor der Bereitstellung erkennen kann, warum behandelt ein Großteil der Krypto-Branche Sicherheitsaudits immer noch als Kontrollkästchen nach dem Start?
Dieser Beitrag erläutert, was die beiden kritischen Schwachstellen auf technischer Ebene tatsächlich waren, untersucht, wie sich die Audit-Abstimmungs-Aktivierungs-Pipeline mit den Sicherheitsmodellen konkurrierender Chains vergleicht, und bewertet, ob die Ergebnisse die Argumente für XRPL als institutionelle Infrastruktur stärken oder untergraben.
Was der Sherlock-Wettbewerb tatsächlich fand
Der Umfang umfasste fünf Säulen der kommenden XRPL-Funktionalität: Batch-Transaktionen, Berechtigungsdelegierung, Multi-Purpose-Token (MPT) DEX-Integration, vertrauliche Übertragungen für MPTs sowie gesponserte Gebühren und Reserven. Sherlock, ein Web3-Sicherheitsunternehmen, das Forscher nach Leistung einstuft und Engagements als Wettbewerbe gestaltet, eröffnete den Audit am 13. April 2026 mit einem Preispool von 550.000 US-Dollar in RLUSD. Die Wettbewerbsseite auf Sherlocks Plattform listete das Engagement als „XRP Ledger – April 2026 Contest – 550.000 RLUSD“ auf, was signalisierte, dass Ripple die Prämien in seiner eigenen Stablecoin zahlte.
Über zwei Wochen hinweg reichten die Teilnehmer Berichte ein, die 96 gültige Befunde ergaben: 2 kritische, 6 hohe, 29 mittlere und 59 niedrige Schweregrade. Ripple verteilte 309.000 US-Dollar in RLUSD an die Mitwirkenden. Der verbleibende Pool deckte Sherlocks Betriebskosten und Befunde niedrigerer Stufen ab, die die Auszahlungsschwelle nicht erreichten.
Der Wettbewerb markierte die erste formelle Zusammenarbeit zwischen Sherlock und Ripple und kam zu einem Zeitpunkt, als die Feature-Pipeline des XRP Ledger schneller wuchs als je zuvor in seiner Geschichte. Fünf gleichzeitig ausgelieferte Änderungen bedeuteten fünf verschiedene Angriffsflächen, jede mit eigener Transaktionslogik, Autorisierungsmodell und kryptografischen Anforderungen. Zum Vergleich: Sherlocks Audit-Wettbewerbsmodell wurde zuvor von Protokollen wie Aave, Euler und Olympus DAO genutzt, aber ein Engagement, das C++-Protokollebene-Code für eine Layer-One-Blockchain abdeckte, war für eine Plattform, die eher mit Solidity-Smart-Contracts assoziiert wird, untypisch.
Die Schweregradverteilung selbst erzählt eine Geschichte. Die 29 mittelschweren Befunde deuten auf eine Kategorie von Fehlern hin, die einzelne Konten nicht kompromittieren würden, aber unter bestimmten Transaktionssequenzen unerwartetes Verhalten verursachen könnten. Die 59 niedrigschweren Probleme umfassen wahrscheinlich Bedenken zur Codequalität, Dokumentationslücken und Randfälle, die sich unter widrigen Bedingungen verstärken könnten. Die zwei kritischen und sechs hochschweren Fehler stellten jedoch ausnutzbare Schwachstellen dar, die eine sofortige Behebung erforderten.
Der Batch-Amendment-Bug, der Konten hätte leeren können
Die gefährlichste Schwachstelle datierte zwei Monate vor dem Sherlock-Wettbewerb. Am 19. Februar 2026 identifizierten der Sicherheitsforscher Pranamya Keshkamat und das autonome KI-Audit-Tool Apex von Cantina unabhängig voneinander einen Signaturvalidierungsfehler im ursprünglichen Batch-Amendment, während es sich noch in der Validator-Abstimmungsphase befand.
Der technische Fehler war präzise. Batch-Transaktionen erlauben bis zu acht Operationen, die atomar unter einer einzigen äußeren Transaktion ausgeführt werden. Der Signaturvalidierungscode der äußeren Transaktion enthielt eine Early-Exit-Bedingung, die erfüllt werden konnte, ohne ordnungsgemäß zu überprüfen, wer die inneren Transaktionen autorisierte. In der Praxis hätte ein Angreifer eine Batch-Transaktion konstruieren können, die innere Zahlungsoperationen enthielt, die auf ein Opferkonto abzielten, und es bis auf seinen Reservebestand leeren konnte, ohne jemals die privaten Schlüssel dieses Kontos zu besitzen. Dieselbe Logiklücke hätte unbefugte AccountSet-, TrustSet- oder AccountDelete-Operationen ermöglicht.
Der auf xrpl.org veröffentlichte Offenlegungsbericht zur Schwachstelle beschrieb die Mechanik: Die Signaturprüfung in der äußeren Transaktion konnte bestehen, ohne zu bestätigen, dass die Entität, die den Batch einreichte, tatsächlich die in den inneren Transaktionen referenzierten Konten kontrollierte. Dies bedeutete, dass die Atomaritätsfunktion, die die Benutzererfahrung verbessern sollte, hätte bewaffnet werden können, um jedes Konto im Netzwerk mit einer einzigen Transaktion zu leeren.
RippleX reagierte mit einem Notfall-Release. Rippled Version 3.1.1, veröffentlicht am 23. Februar 2026, vier Tage nach der Entdeckung, markierte sowohl das ursprüngliche Batch-Amendment als auch seinen Begleit-Fix fixBatchInnerSigs als nicht unterstützt, wodurch Validatoren daran gehindert wurden, darüber abzustimmen oder sie zu aktivieren. Es gingen keine Gelder verloren, da das Amendment die für die Aktivierung erforderliche 80%-Validator-Schwelle noch nicht erreicht hatte. Der Ersatz, BatchV1_1, wurde in Version 3.3.0 ausgeliefert, mit entfernter Early-Exit-Bedingung, zusätzlichen Autorisierungsprüfungen und einem enger gefassten Signaturprüfungsbereich, der jede innere Transaktion unabhängig gegen den korrekten Unterzeichner verifiziert.
Permission Delegations stiller Gebührenabfluss-Exploit
Die zweite kritische Schwachstelle funktionierte über einen subtileren Mechanismus. Eine Offenlegung vom September 2025 dokumentierte, wie die ursprüngliche Permission-Delegation-Implementierung es einem Angreifer ermöglichte, den XRP-Saldo eines Opferkontos still zu leeren, ohne auf dessen Schlüssel zuzugreifen.
Der Exploit stützte sich auf ein Designmerkmal der Transaktionsverarbeitung des XRP-Ledgers, das seit den frühesten Tagen des Netzwerks existiert. Bei XRPL wird eine Transaktion, die mit einem Fehler der Klasse „tec“ fehlschlägt, dennoch mit einer Gebühr belegt, während Fehler, die früher in der Pipeline vor der Signaturprüfung abgefangen werden, dies nicht tun. Diese Unterscheidung existiert, weil tec-Klasse-Fehler anzeigen, dass Transaktionen ordnungsgemäß geformt und signiert waren, aber aus geschäftslogischen Gründen fehlschlugen, und die Gebühr verhindert Spam. Der ursprüngliche Code von Permission Delegation prüfte, ob ein Delegatenkonto über die relevante Berechtigung verfügte, bevor er die Signatur der Transaktion verifizierte. Ein Angreifer könnte wiederholt ungültige offline signierte Transaktionen mit erhöhten Gebühren gegen ein delegiertes Konto einreichen, und jede fehlgeschlagene Transaktion würde dennoch die Gebühr vom Saldo des Opfers abziehen.
Die wirtschaftlichen Auswirkungen hätten sich schnell vervielfacht. Da der Angreifer beliebig hohe Gebühren für diese Transaktionen festlegen konnte, könnte ein anhaltender Angriff ein Konto weit schneller leeren, als normale Transaktionsgebühren vermuten ließen. Das Opfer würde sehen, wie sein Saldo ohne entsprechende ausgehende Zahlungen sinkt, was den Angriff ohne Untersuchung der rohen Transaktionsmetadaten schwer zu diagnostizieren macht.
Der Fix stufte den relevanten Fehler von tec auf ter um und ordnete die Prüfungen neu an, sodass keine Gebühr abgezogen werden kann, bevor die Signaturprüfung bestanden ist. Das Ersatz-Amendment, PermissionDelegationV1_1, trägt im 3.3.0-Register eine Standard-„Nein“-Kennzeichnung, was bedeutet, dass Validatoren aktiv dafür stimmen müssen, es zu aktivieren. Diese konservative Standardeinstellung spiegelt die Sensibilität des ursprünglichen Fehlers wider: Selbst nach der Neufassung entschied sich Ripple, eine explizite Opt-in der Validatoren für die Funktion zu verlangen.
Warum beide Neufassungen in einem einzigen Release veröffentlicht wurden
Die Bündelung von zwei sicherheitsüberarbeiteten Amendments zusammen mit drei völlig neuen Funktionen in einer Version war eine bewusste Entscheidung. RippleX veröffentlichte xrpld 3.3.0 am 6. August 2026, wobei der Code für alle sechs Vorschläge (einschließlich eines gebündelten Aufräum-Amendments namens fixCleanup3_3_0) vorhanden war, aber keiner davon aktiviert wurde. Gemäß dem Amendment-Prozess des XRP Ledgers muss jeder Vorschlag zwei aufeinanderfolgende Wochen lang mehr als 80% Unterstützung der Validatoren aufrechterhalten, bevor er live geht.
Diese Trennung zwischen Code-Verfügbarkeit und Funktionsaktivierung ist ein struktureller Vorteil, der den meisten Smart-Contract-Plattformen fehlt. Auf Ethereum ist ein bereitgestellter Vertrag in dem Moment live, in dem er die Blockchain erreicht. Auf XRPL kann Code ausgeliefert werden, während des Abstimmungsfensters weiter geprüft werden und dennoch blockiert werden, wenn die Validatoren das Vertrauen verlieren. Die Neufassungen von Batch und Permission Delegation hatten bereits den Sherlock-Wettbewerb, ein Halborn-Re-Audit, das keine kritischen oder schwerwiegenden Probleme feststellte, und monatelange interne Tests überstanden. Die Abstimmungsfrist fügt eine weitere Verteidigungsebene hinzu, bevor Code echtes Geld berührt.
Die Version zog auch fünf veraltete Amendments zurück, darunter Clawback, fixDisallowIncomingV1, fixInnerObjTemplate, fixNFTokenReserve und fixUniversalNumber, und entfernte tote Codepfade, die sich sonst im Laufe der Zeit als latente Angriffsfläche ansammeln könnten.
Die fünf Funktions-Amendments in 3.3.0 stellen die breiteste einzelne Erweiterung der XRPL-Fähigkeiten dar. Confidential Transfers bringen EC-ElGamal-Verschlüsselung und Zero-Knowledge-Beweise in Multi-Purpose Tokens, schützen einzelne Guthaben und Transferbeträge vor öffentlicher Einsicht und bewahren gleichzeitig den Compliance-Zugang für autorisierte Parteien. Sponsored Fees ermöglichen es Anwendungen, Netzwerkkosten im Namen von Benutzern zu übernehmen, und adressieren die Onboarding-Reibung, die verbraucherorientierte Anwendungen von dezentralen Netzwerken ferngehalten hat. DynamicMPT ermöglicht es Emittenten, Token-Eigenschaften nach der Erstellung zu ändern, um sich entwickelnde regulatorische und geschäftliche Anforderungen zu unterstützen. Zusammen mit den Neufassungen von Batch und Permission Delegation zielen diese Funktionen auf ein bestimmtes Publikum: regulierte Finanzinstitute, die Privatsphäre, atomare Abwicklung und delegierte Operationen benötigen, ohne die Prüfbarkeit zu opfern.
Audit vor der Veröffentlichung versus Patch nach dem Exploit
Der Kontrast zwischen Ripples Ansatz und der Sicherheitsbilanz der breiteren Branche ist eklatant. DeFi-Exploits überstiegen in den ersten fünf Monaten des Jahres 2026 840 Millionen US-Dollar bei mehr als 50 Vorfällen, ein Anstieg von 70% im Jahresvergleich gegenüber dem gleichen Zeitraum im Jahr 2025. Mit Nordkorea verbundene Akteure waren in den ersten vier Monaten des Jahres für 76% der weltweiten Krypto-Hack-Verluste verantwortlich. Und die vernichtendste Statistik: 70% der ausgenutzten Verträge waren geprüft worden, hatten aber keinerlei Form von Post-Deployment-Überwachung. Nur 4% der verfolgten Projekte kombinierten Audits, aktive Bug-Bounties und Überwachung durch Dritte.
Das Ethereum-Ökosystem, das die größte Konzentration an Smart-Contract-Wert beherbergt, arbeitet unter einem grundlegend anderen Sicherheitsmodell. Verträge werden über eine unveränderliche Transaktion auf dem Mainnet bereitgestellt. Wenn später eine Schwachstelle auftaucht, sind die Optionen begrenzt: einen neuen Vertrag bereitstellen und Benutzer migrieren, ein Proxy-Upgrade-Muster implementieren, das eine eigene Angriffsfläche einführt, oder das Risiko akzeptieren. Der Wormhole-Bridge-Hack von 2022 kostete 320 Millionen US-Dollar, weil eine veraltete Verifikationsfunktion im Produktionscode verblieb. Ronins Exploit im August 2024 kostete 12 Millionen US-Dollar, weil ein Vertrags-Upgrade die Initialisierung der Operator-Gewichte nicht korrekt durchführte. In beiden Fällen waren Audits durchgeführt worden; die Fehler traten nach der Bereitstellung auf.
Der KelpDAO-Hack am 18. April 2026, der etwa 293 Millionen US-Dollar abzog, war der größte einzelne DeFi-Exploit des Jahres. Der Drift-Protocol-Exploit auf Solana am 1. April, der etwa 286 Millionen US-Dollar kostete, war der größte, der jemals auf dieser Chain verzeichnet wurde. Diese Zahlen sind keine Randereignisse. Sie repräsentieren die grundlegende Fehlerrate einer Branche, die laut DeFiLlama-Daten insgesamt 16,69 Milliarden US-Dollar durch Hacks, Bridge-Exploits und Sicherheitsvorfälle verloren hat.
Der Änderungsabstimmungsprozess von XRPL kehrt diese Reihenfolge um. Code wird in einem Release ausgeliefert, aber Funktionen bleiben inaktiv, bis die Validatoren sie genehmigen. Während des Abstimmungsfensters können Forscher, Knotenbetreiber und konkurrierende Prüfer die Live-Codebasis mit vollem Kontext untersuchen. Wenn ein Problem auftaucht, enthalten die Validatoren einfach ihre Stimmen. Kein Notfall-Patch, keine Migration, kein Proxy-Vertrag. Der Batch-Fehler vom Februar 2026 folgte genau diesem Weg: Die Änderung befand sich in der Abstimmungsphase, die Schwachstelle wurde identifiziert, und ein Notfall-Release verhinderte die Aktivierung. Null Gelder gefährdet, null Auswirkungen auf Benutzer.
Das soll nicht heißen, dass das XRPL-Modell fehlerfrei ist. Der Änderungsprozess funktioniert für Funktionen auf Protokollebene, erstreckt sich jedoch nicht auf Anwendungen, die auf dem Ledger aufbauen. Eine schlecht codierte Trustline oder MPT-Integration könnte immer noch Gelder verlieren. Und die 80%-Validatoren-Schwelle birgt eigene Risiken: Wenn zu wenige Validatoren auf eine neue Version aktualisieren, können legitime Sicherheits-Patches ins Stocken geraten. Aber für Kernprotokolländerungen stellt die Prüf-Abstimmungs-Aktivierungs-Pipeline eine materiell andere Sicherheitshaltung dar als "Bereitstellen und Hoffen".
Was das für den institutionellen Pitch von XRPL bedeutet
Ripple hat 2026 damit verbracht, einen institutionellen Infrastruktur-Stack in aggressivem Tempo aufzubauen. Die Übernahme von Hidden Road im Wert von 1,25 Milliarden US-Dollar, ein Multi-Asset-Prime-Broker, der in Ripple Prime umbenannt wurde, verschaffte dem Unternehmen einen regulierten Einstieg für traditionelle Finanzen. RLUSD erreichte in weniger als einem Jahr eine Marktkapitalisierung von 1,72 Milliarden US-Dollar und bewegte allein im ersten Quartal ein Transaktionsvolumen von über 18 Milliarden US-Dollar. Goldman Sachs legte eine Position von 153,8 Millionen US-Dollar über vier XRP-ETFs offen. Ripple sicherte sich im Februar eine vollständige Elektronische-Geld-Institut-Lizenz von Luxemburg, im Januar Genehmigungen der britischen Financial Conduct Authority und am 6. Juli eine MiCA-Lizenz für Krypto-Dienstleister.
Die institutionellen DeFi-Funktionen, die in Version 3.3.0 kommen, sind das technische Gegenstück zu diesem Geschäftsentwicklungsvorstoß. Vertrauliche Übertragungen adressieren die Datenschutzanforderungen von Banken, die Transaktionsdetails nicht auf einem öffentlichen Ledger offenlegen können. Gesponserte Gebühren lösen die Onboarding-Reibung, die Retail-Banking-Anwendungen von dezentralen Netzwerken ferngehalten hat. Berechtigungsdelegation, sobald ihre Neufassung den Abstimmungsprozess durchläuft, ermöglicht die Art von kontrollierten Zugriffsmodellen, die Compliance-Abteilungen benötigen.
Aber die institutionelle Akzeptanz hängt vom Vertrauen ab, und Vertrauen in Blockchain-Infrastruktur läuft letztlich auf die Sicherheitsbilanz hinaus. Die Tatsache, dass Ripple zwei kritische Fehler entdeckte, zwei gesamte Feature-Implementierungen neu schrieb, externen Forschern 309.000 US-Dollar zahlte, um Probleme zu finden, und dennoch alle fünf Funktionen termingerecht lieferte, ist ein stärkeres institutionelles Verkaufsargument als jede einzelne Funktion. Es deutet auf eine Sicherheitskultur hin, in der das Finden von Fehlern belohnt wird und in der das Ausliefern der Verifizierung untergeordnet ist.
Über 300 Finanzinstitute in 55 Ländern nutzen derzeit RippleNet, mit aktiven On-Demand-Liquiditätskorridoren in mehr als 70 Märkten. Für diese Institute sind die Sherlock-Prüfergebnisse nicht abstrakt. Sie sind Beweis dafür, dass der Code, der ihre grenzüberschreitenden Zahlungen ausführt, von gegnerischen Forschern mit finanziellen Anreizen, ihn zu brechen, einem Stresstest unterzogen wurde. Ripples vierteiliger Quantenresistenz-Fahrplan, der bis 2028 abgeschlossen sein soll, signalisiert weiterhin, dass das Unternehmen für institutionelle Zeithorizonte entwickelt, die in Jahrzehnten gemessen werden, nicht in Bereitstellungszyklen.
Der Gegenfall: Warum Skeptiker nicht überzeugt sind
Das stärkste Argument gegen eine Überinterpretation des Sherlock-Audits läuft in zwei Richtungen.
Erstens kann das Finden von 96 Fehlern vor der Veröffentlichung als Beweis für gründliche Tests oder als Beweis für schlampige Entwicklung interpretiert werden. Sowohl die Batch- als auch die Permission-Delegation-Schwachstellen befanden sich in den ursprünglichen Implementierungen, was bedeutet, dass sie die interne Überprüfung bestanden, bevor externe Forscher sie entdeckten. Der Batch-Fehler vom Februar 2026 wurde nicht vom eigenen Team von Ripple identifiziert, sondern von einem unabhängigen Forscher und einem KI-Tool. Wenn externe Prüfer das primäre Sicherheitsnetz sind, könnte der interne Entwicklungsprozess Qualitätslücken aufweisen, die schließlich zu einer Schwachstelle führen, die kein externer Prüfer rechtzeitig erkennt.
Zweitens ist die Stärke des XRPL-Änderungsmodells, die Fähigkeit, die Aktivierung während des Abstimmungsfensters zu verhindern, auch eine Geschwindigkeitsbeschränkung. Die Bereitschaft von Ethereum, zu deployen und zu iterieren, hat ein Innovationstempo ermöglicht, das XRPL nicht erreichen kann. Die fünf Änderungen in Version 3.3.0 befinden sich seit Monaten in Entwicklungs- und Überprüfungszyklen. Die ursprüngliche Batch-Änderung wurde 2025 vorgeschlagen. Für Protokolle, die in sich schnell bewegenden Märkten um die Aufmerksamkeit von Entwicklern konkurrieren, könnte eine sechsmonatige Sicherheitspipeline zu langsam sein, um das Builder-Ökosystem anzuziehen, das Netzwerkeffekte antreibt.
Es gibt auch ein Konzentrationsrisiko im Validator-Set. Die 80%-Aktivierungsschwelle bedeutet, dass eine relativ kleine Anzahl von Validatoren, von denen viele von Unternehmen betrieben werden, die enge Verbindungen zu Ripple haben, kontrolliert, ob Änderungen live gehen. Kritiker argumentieren, dass dies keine wirklich dezentrale Governance ist, sondern ein kuratierter Genehmigungsprozess, der in Konsenssprache gekleidet ist. Als Ripples eigener Validator in den letzten Wochen mit „Ja" zu den Kreditänderungen stimmte, unterstrich dies, wie viel Einfluss das Unternehmen auf sein nominell dezentrales Netzwerk behält.
Schließlich wirft die Auszahlung von 309.000 $ aus einem Pool von 550.000 $ eine praktische Frage zur Anreizausrichtung auf. Top-Sicherheitsforscher verlangen Sätze, die über dem liegen, was Wettbewerbsmodelle typischerweise pro Arbeitsstunde zahlen. Wenn die qualifiziertesten Auditoren XRPL-Wettbewerbe überspringen, weil die erwartete Auszahlung pro Fund niedriger ist als bei privaten Engagements, könnte die adversariale Überprüfung zwar breit, aber nicht tief genug sein, um die ausgefeiltesten Angriffsvektoren zu erfassen.
Diese Einwände haben Gewicht. XRP wurde Ende Juli 2026 bei etwa 1,03 $ gehandelt, etwa 71% unter seinem Zyklushoch von 3,65 $ vom 17. Juli 2025, was darauf hindeutet, dass der Markt die institutionelle Erzählung noch nicht eingepreist hat. Ob sich die Sicherheitsbilanz in Akzeptanz niederschlägt, hängt von Faktoren ab, die über die Codequalität hinausgehen: regulatorische Klarheit, Wettbewerbspositionierung gegenüber Ethereum-Layer-2-Lösungen und ob Institutionen Vorab-Prüfungen wichtiger nehmen als die Größe des Ökosystems.
Was zu beobachten ist
Abstimmungsschwellen der Validatoren für die fünf 3.3.0-Änderungen: Wenn BatchV1_1 und PermissionDelegationV1_1 im ersten Abstimmungszyklus 80% Unterstützung erreichen, signalisiert dies das Vertrauen der Validatoren in die Neufassungen. Ein Stillstand würde auf anhaltende Bedenken hinsichtlich des neu geschriebenen Codes hindeuten.
Fehlerberichte nach der Aktivierung: Der wahre Test für die Gründlichkeit des Sherlock-Audits kommt, nachdem die Funktionen live gehen. Null kritische Befunde in den ersten 90 Tagen würden das Vorab-Veröffentlichungsmodell bestätigen; jede Schwachstelle nach der Aktivierung würde die gesamte These untergraben.
RLUSD-Akzeptanz bei vertraulichen Übertragungen: Die institutionelle Nutzung von Stablecoins auf geschützten Schienen würde die Nachfrage nach datenschutzkonformer Abwicklung bestätigen. Volumenkennzahlen im ersten Quartal nach der Aktivierung werden das klarste Signal dafür sein, ob Banken bereit sind, auf einem öffentlichen Hauptbuch mit Datenschutzgarantien zu transagieren.
Sherlocks nächste XRPL-Engagements: Ob Ripple weiterhin adversariale Audit-Wettbewerbe für zukünftige Änderungen durchführt oder zu traditionellen privaten Audits zurückkehrt, wird zeigen, wie tief das Vorab-Veröffentlichungsmodell in der Entwicklungskultur verankert ist.
Konkurrierende Sicherheitsvorfälle in Ketten: Jeder größere Exploit auf Ethereum oder Solana, der auf eine Schwachstelle nach der Bereitstellung zurückzuführen ist, stärkt das Argument für die Audit-Vote-Activate-Pipeline von XRPL. Der Vergleich ist nur so stark wie das anhaltende Versagen der Branche, ähnliche Prozesse zu übernehmen.
Was hat das Sherlock-Audit des XRP Ledger ergeben?
Der zweiwöchige Audit-Wettbewerb, der am 13. April 2026 eröffnet wurde, deckte 96 gültige Schwachstellen in fünf vorgeschlagenen XRPL-Änderungen auf: 2 kritische, 6 hohe, 29 mittlere und 59 Schwachstellen mit geringem Schweregrad. Ripple zahlte 309.000 $ in RLUSD-Prämien aus einem Preispool von 550.000 $. Alle Befunde wurden behoben, bevor eine der betroffenen Funktionen im Mainnet aktiviert wurde.
Was war der kritische Batch-Änderungsfehler?
Die ursprüngliche Batch-Änderung enthielt einen Fehler bei der Signaturvalidierung, der es einem Angreifer ermöglichte, innere Transaktionen von jedem Konto auszuführen, ohne dessen private Schlüssel zu besitzen. Der Fehler war eine Early-Exit-Bedingung in der Signaturprüfung der äußeren Transaktion, die ohne ordnungsgemäße Autorisierungsprüfung erfüllt werden konnte. Der Forscher Pranamya Keshkamat und das KI-Tool Apex von Cantina identifizierten ihn am 19. Februar 2026. RippleX patchte ihn vier Tage später in der Notfallversion 3.1.1.
Wie funktionierte die Schwachstelle bei der Berechtigungsdelegation?
Die ursprüngliche Implementierung prüfte die Delegiertenberechtigungen, bevor sie Transaktionssignaturen verifizierte. Auf XRPL verursachen Transaktionen, die mit Fehlern der Klasse "tec" fehlschlagen, dennoch Gebühren. Ein Angreifer könnte wiederholt ungültige Transaktionen mit erhöhten Gebühren gegen ein delegiertes Konto einreichen und so dessen XRP-Guthaben aufbrauchen, ohne jemals dessen Schlüssel zu besitzen. Der Fix stufte den Fehlertyp neu ein und ordnete die Verifizierungsprüfungen neu.
Gingen durch diese Schwachstellen Gelder verloren?
Es gingen keine Gelder verloren. Beide kritischen Schwachstellen wurden identifiziert, bevor ihre jeweiligen Änderungen im Mainnet aktiviert wurden. Der Batch-Fehler wurde während der Validator-Abstimmungsphase entdeckt, und die Schwachstelle bei der Berechtigungsdelegation wurde vor der Aktivierung offengelegt und gepatcht. Der Änderungsprozess des XRP Ledger, der zwei aufeinanderfolgende Wochen lang eine Unterstützung von 80 % der Validatoren erfordert, bot einen strukturellen Puffer, der eine Ausnutzung verhinderte.
Was ist Sherlock und wie funktioniert sein Audit-Modell?
Sherlock ist ein Web3-Sicherheitsunternehmen, das Audits als Wettbewerbe mit Gegnern strukturiert, Forscher nach Leistung einstuft und durch Preispools finanzielle Anreize bietet. Das Engagement des XRP Ledger war die erste Zusammenarbeit von Sherlock mit Ripple und einer der größten Audit-Wettbewerbe des Jahres 2026. Das Modell unterscheidet sich von traditionellen privaten Audits, indem es eine breite Beteiligung unabhängiger Sicherheitsforscher einlädt, die um Prämien konkurrieren, was ein breiteres Spektrum an Angriffsvektoren aufdeckt, als ein kleines internes Team abdecken kann.
Wie unterscheidet sich das Sicherheitsmodell von XRPL von dem von Ethereum?
Der Änderungsprozess von XRPL trennt die Codebereitstellung von der Funktionsaktivierung. Neue Funktionen werden in einer Softwareversion ausgeliefert, bleiben jedoch inaktiv, bis Validatoren über ihre Aktivierung abstimmen, wodurch ein Überprüfungsfenster entsteht, in dem Schwachstellen ohne Notfall-Patches erkannt werden können. Smart Contracts von Ethereum sind nach der Bereitstellung sofort live, und die Behebung von Schwachstellen erfordert die Bereitstellung neuer Verträge, die Migration von Benutzern oder die Implementierung von Proxy-Upgrades. In den ersten fünf Monaten des Jahres 2026 überstiegen DeFi-Exploits 840 Millionen US-Dollar, und 70 % der ausgenutzten Verträge waren geprüft, entbehrten jedoch einer Überwachung nach der Bereitstellung.
Welche Funktionen enthält XRP Ledger Version 3.3.0?
Version 3.3.0, veröffentlicht am 6. August 2026, enthält Code für fünf Funktionsänderungen und einen Bereinigungspatch. Die Funktionen umfassen vertrauliche Übertragungen für Multi-Purpose-Token unter Verwendung von Zero-Knowledge-Beweisen, neu geschriebene Batch-Transaktionen für atomare Multi-Operation-Abwicklung, neu geschriebene Berechtigungsdelegation für kontrollierten Kontozugriff, gesponserte Gebühren, die es Anwendungen ermöglichen, Benutzerkosten zu übernehmen, und DynamicMPT, das Emittenten ermöglicht, Token-Eigenschaften nach der Erstellung zu ändern.
Macht dieses Audit XRPL zu einer sicheren Investition?
Das Sherlock-Audit spiegelt einen strengen Sicherheitsprozess vor der Veröffentlichung wider, aber die Codequalität ist nur einer von vielen Faktoren, die die Anlageergebnisse beeinflussen. XRP wurde Ende Juli 2026 bei etwa 1,03 $ gehandelt, etwa 71 % unter seinem Zyklushoch, und die Marktleistung hängt von regulatorischen Entwicklungen, institutionellen Akzeptanzraten, Wettbewerbsdynamik und makroökonomischen Bedingungen ab. Dies ist eine bildungsbezogene Analyse, keine Anlageberatung. **Haftungsausschluss**: Dieser Artikel wurde am 14. August 2026 veröffentlicht. Er dient nur zu Bildungs- und Informationszwecken und sollte nicht als Finanz-, Anlage- oder Rechtsberatung ausgelegt werden. Kryptowährungsmärkte sind volatil und bergen ein erhebliches Risiko. Leser sollten eigene Nachforschungen anstellen und qualifizierte Fachleute konsultieren, bevor sie Anlageentscheidungen treffen.
