Der „Garden Finance“-Hack zeigt, warum es bei DeFi-Risiken nicht mehr nur um den Code geht

Wenn eine DeFi-Brücke Verluste verzeichnet, geht man in der Regel davon aus, dass ein Smart Contract versagt hat. Eine Codezeile war fehlerhaft, eine Validierungsprüfung fehlte, ein Orakel wurde manipuliert oder ein Angreifer fand einen Weg, Vermögenswerte durch das System zu leiten, den die Entwickler nicht vorhergesehen hatten.

Der Vorfall bei Garden Finance weist auf ein komplexeres Problem hin. Die Cross-Chain-Brücke verlor Berichten zufolge rund 11 Millionen US-Dollar, nachdem einer ihrer Solver kompromittiert worden war. Garden erklärte, die Gelder der Nutzer seien sicher und der betroffene Solver sei vom Kernprotokoll getrennt. Das Team stellte seine Anwendung vorübergehend ein und setzte eine Belohnung von 10 Prozent für die Rückgabe der gestohlenen Gelder aus. Der Vorfall wurde im Oktober 2025 gemeldet und tauchte in späteren Berichten erneut als Beispiel für Solver-bezogene Brückenrisiken auf.

Das spielt in der Regel eine Rolle. Eine Bridge kann über geprüfte Verträge, eine übersichtliche Benutzeroberfläche und ein dezentrales Konzept verfügen und dennoch von Off-Chain-Teilnehmern, Betriebsprozessen und Drittanbietern abhängig sein, die den Nutzern möglicherweise kaum verständlich sind. In diesem Fall ist der Begriff “Solver” keine technische Fußnote. Er ist der zentrale Punkt.

Ein „Solver“ ist in der Regel ein Akteur, der zur Abwicklung von Transaktionen beiträgt, indem er Liquidität bereitstellt, Aufträge weiterleitet oder Absichten systemübergreifend abgleicht. In einer absichtsbasierten und kettenübergreifenden Infrastruktur können Solver das Nutzererlebnis beschleunigen und reibungsloser gestalten. Der Nutzer gibt an, was geschehen soll, und das System stützt sich auf spezialisierte Akteure, die dies im Hintergrund umsetzen.

Dieses Modell ist leistungsstark. Es ist aber auch komplexer als das einfache Versprechen einer vertrauenslosen Finanzwelt.

Die Schwachstelle könnte außerhalb des Smart Contracts liegen

DeFi vermarktet sich oft über den Code. Smart Contracts sind transparent, überprüfbar und theoretisch vorhersehbar. Dies hat die Vorstellung gefördert, dass sich Risiken hauptsächlich anhand des Protokoll-Designs und der Vertragssicherheit einschätzen lassen.

Der Fall „Garden Finance“ macht deutlich, dass moderne DeFi-Systeme nicht nur aus Smart Contracts bestehen. Sie sind Netzwerke aus Verträgen, Brücken, Relayern, Solvern, Market Makern, Wallets, Schnittstellen, Governance-Prozessen, Cloud-Diensten, privaten Schlüsseln, Multisigs, Überwachungstools und menschlichen Betreibern. Eine Schwachstelle in einer dieser Ebenen kann zum tatsächlichen Ausfallpunkt werden.

Dies gilt insbesondere für Brücken. Die kettenübergreifende Infrastruktur war schon immer einer der schwierigsten Sicherheitsbereiche im Kryptobereich, da sie separate Ökosysteme miteinander verbindet, die ursprünglich nicht darauf ausgelegt waren, einander zu vertrauen. Eine Brücke muss überprüfen, ob ein Ereignis auf einer Kette stattgefunden hat, und anschließend eine entsprechende Aktion an anderer Stelle zulassen. Dadurch entsteht eine große Angriffsfläche.

Wissenschaftliche Untersuchungen zu Hacks bei Cross-Chain-Brücken haben wiederholt gezeigt, dass Brücken zwar eine kritische, aber anfällige Infrastruktur darstellen, wobei Verluste auf Schwachstellen im Design, Validierungsfehler und Mängel bei den betrieblichen Kontrollmechanismen zurückzuführen sind. Der Angriff auf die Ronin-Brücke im Jahr 2022, der zu Verlusten in Höhe von fast 600 Millionen US-Dollar führte, ist nach wie vor eines der deutlichsten Beispiele für das Ausmaß des Risikos, das von solchen Brücken ausgeht.

Doch nicht jeder Vorfall im Zusammenhang mit einer Bridge ist auf einen reinen Smart-Contract-Exploit zurückzuführen. Zunehmend liegt das Risiko im operativen Bereich: kompromittierte Schlüssel, schwache Zugriffskontrollen, unzureichende Überwachung, Abhängigkeit von Akteuren mit Sonderrechten oder unklare Zuständigkeiten zwischen dem Protokoll und den damit verbundenen Akteuren.

Deshalb ist die Aussage “Die Gelder der Nutzer sind sicher” noch nicht das letzte Wort in dieser Diskussion. Im engeren Sinne mag es zwar zutreffen, dass die Einlagen nicht direkt abgezogen wurden. Aber die Nutzer, Liquiditätsanbieter und die Geschäftspartner müssen nach wie vor wissen, welche Teile des Systems Risiken bergen und wer dafür haftet, wenn etwas schiefgeht.

Solver machen DeFi einfacher, aber schwerer zu durchschauen

Intent-basierte Systeme und Solver-Netzwerke sind Teil einer umfassenderen Initiative, die darauf abzielt, DeFi benutzerfreundlicher zu gestalten. Anstatt von den Nutzern zu verlangen, dass sie jeden Pfad, jeden Pool, jede Bridge, jede Gasgebühr und jeden Ausführungsschritt verstehen, können Protokolle den Nutzern ermöglichen, das gewünschte Ergebnis zu definieren. Solver konkurrieren dann miteinander oder arbeiten zusammen, um dieses Ergebnis zu erzielen.

Für den Nutzer fühlt sich das einfacher an. Für die Infrastruktur ist es jedoch alles andere als einfach.

Je mehr das System Komplexität abstrahiert, desto wichtiger wird es zu wissen, wer die im Hintergrund stattfindende Arbeit leistet. Sind die Solver genehmigungsfrei oder zugelassen? Sind sie finanziell abgesichert? Können sie schnell entfernt werden? Was passiert, wenn einer kompromittiert wird? Gibt es Grenzen für das Risiko? Gibt es eine unabhängige Überwachung? Ist das Protokoll für das Verhalten der Solver verantwortlich, oder behandelt es den Solver als externen Teilnehmer?

Diese Fragen sind im Frontend einer DeFi-Anwendung nicht immer ersichtlich. Für den Nutzer mag es wie eine reibungslose Bridge-Transaktion aussehen. Dahinter stützt sich das System jedoch möglicherweise auf Akteure mit unterschiedlichen Anreizen, unterschiedlichen Sicherheitsstandards und unterschiedlichen Transparenzniveaus.

Das ist das Beunruhigende am Vorfall um Garden Finance. Er zeigt, dass DeFi Risiken zwar von der Benutzeroberfläche verlagern kann, ohne sie jedoch aus dem System zu beseitigen. Die Benutzererfahrung mag übersichtlich wirken, doch die zugrunde liegende Risikolandschaft könnte fragmentierter sein, als den Nutzern bewusst ist.

Auch die Frage nach dem Ansehen ist ein ernstes Thema

Garden Finance war bereits vor dem Vorfall mit dem Solver ins Visier der Behörden geraten. Im Juni 2025 warf der Blockchain-Ermittler ZachXBT der Bitcoin-Bridge vor, Geldströme im Zusammenhang mit gestohlenen Geldern zu ermöglichen, darunter Vermögenswerte, die angeblich mit der Lazarus-Gruppe in Verbindung stehen. Garden wies diese Anschuldigungen zurück, doch der Vorwurf warf weiterreichende Fragen zur Überwachung von Bridges, zu illegalen Geldströmen und zur Verantwortung von Infrastrukturen auf, die den kettenübergreifenden Transfer ermöglichen.

Dieser Zusammenhang ist von Bedeutung, da Brücken an der Schnittstelle zwischen Liquidität, Geschwindigkeit und Anonymität angesiedelt sind. Sie sind nützlich für legitime Nutzer, die Vermögenswerte kettenübergreifend transferieren müssen. Gleichzeitig sind sie attraktiv für Angreifer, die gestohlene Gelder verschieben, Spuren verwischen oder lückenhafte Compliance-Standards ausnutzen wollen.

Das bedeutet nicht, dass jede Brücke mangelhaft ist. Es bedeutet jedoch, dass Brückenbetreiber die Überwachung, die Reaktion auf Vorfälle und die Prävention von Missbrauch als zentrale Infrastruktur betrachten müssen und nicht als PR-Themen, die erst nach einem Vorfall angegangen werden.

Im Bereich DeFi ist die Reputation untrennbar mit der Sicherheit verbunden. Ein Protokoll kann einen technischen Vorfall überstehen, wenn die Nutzer der Meinung sind, dass die Reaktion schnell, transparent und glaubwürdig ist. Es könnte jedoch in Schwierigkeiten geraten, wenn der Vorfall Unklarheiten darüber offenbart, wer was betrieben hat, wo die Verantwortung liegt und inwieweit das System tatsächlich unter der Kontrolle des Protokolls stand.

Prüfungen sind notwendig, reichen aber nicht aus

Nach einem DeFi-Exploit wird oft reflexartig die Forderung nach mehr Audits laut. Das ist verständlich. Die Überprüfung von Smart Contracts, die formale Verifikation und externe Sicherheitsbewertungen sind nach wie vor wichtig. Der Vorfall bei Garden Finance zeigt jedoch, warum Audits nicht die einzige Lösung sein können.

Im Rahmen eines Audits kann der Code bewertet werden. Das operative Verhalten von Solvern, Verwahrungsvereinbarungen, die Verwaltung privater Schlüssel, die Reaktionsfähigkeit bei Vorfällen, die Off-Chain-Infrastruktur oder die wirtschaftlichen Anreize externer Teilnehmer lassen sich dabei jedoch möglicherweise nicht vollständig beurteilen. Selbst wenn diese Bereiche überprüft werden, können sie sich nach der Bereitstellung ändern.

Die Sicherheit im DeFi-Bereich muss sich daher von einer auf einmalige Prüfungen ausgerichteten Denkweise hin zu einem kontinuierlichen Risikomanagementmodell entwickeln. Das bedeutet, Transaktionen in Echtzeit zu überwachen, Grenzwerte festzulegen, operative Kontrollen zu testen, die Reaktion auf Vorfälle zu proben, privilegierte Zugriffsrechte zu überprüfen und zu verstehen, wie sich Abhängigkeiten unter Belastung verhalten.

Untersuchungen zu DeFi-Angriffen haben gezeigt, dass sich die Vorfälle nicht auf eine einzige technische Kategorie beschränken. Dazu gehören Orakel-Manipulationen, Missbrauch von Governance-Mechanismen, Flash-Loan-Angriffe, Fehler bei der Zugriffskontrolle, Kompromittierungen von Brücken sowie operative Schwachstellen. Eine systematische Untersuchung von DeFi-Angriffen aus dem Jahr 2022 analysierte 181 reale Vorfälle und stellte fest, dass die tatsächlichen Angriffsmuster oft von den Schwerpunkten der wissenschaftlichen Forschung abwichen.

Diese Lücke spielt nach wie vor eine Rolle. Das DeFi-Risiko ist nicht statisch. Wenn sich die Architektur ändert, ändert sich auch die Angriffsfläche.

Was Bridge-Nutzer fragen sollten

Die meisten Nutzer können die gesamte technische Architektur einer Brücke nicht im Detail begutachten. Sie können jedoch fundiertere Fragen stellen, bevor sie erhebliche Werte über eine solche Brücke transportieren.

Die erste Frage lautet: Handelt es sich um eine „Custody-Light“- oder eine „Custody-Heavy“-Brücke? Wer kontrolliert die Vermögenswerte während des Transfers? Werden die Mittel gesperrt, geprägt, weitergeleitet, getauscht oder von Liquiditätsanbietern bereitgestellt? Die Antwort darauf beeinflusst das Risiko.

Die zweite Frage lautet, wie das System mit Ausfällen umgeht. Was passiert, wenn ein Solver ausfällt, kompromittiert wird oder sich weigert, eine Einigung zu erzielen? Gibt es eine Ausweichlösung? Gibt es einen Versicherungsfonds? Werden die Nutzer entschädigt? Trägt das Protokoll vertragliche oder wirtschaftliche Verantwortung?

Die dritte Frage lautet, ob das Protokoll über eine klare öffentliche Historie von Vorfällen und eine transparente Kommunikation verfügt. Eine Brücke, bei der Ausfälle klar erklärt werden, ist nicht automatisch sicherer, aber Transparenz verschafft den Nutzern mehr Informationen. Schweigen, vage Informationen und übermäßig eng gefasste Dementis sollten mit Vorsicht betrachtet werden.

Die vierte Frage lautet, ob bei der Bridge ein Konzentrationsrisiko besteht. Wenn eine kleine Anzahl von Solvern, Betreibern oder Schlüsseln große Volumina beeinflussen kann, ist das System möglicherweise anfälliger, als der Begriff “dezentralisiert” vermuten lässt.

Die fünfte Frage lautet, ob der Nutzer die Bridge tatsächlich benötigt. Viele Verluste im Kryptobereich entstehen dadurch, dass Nutzer Vermögenswerte für einen marginalen Gewinn in Systeme verlagern, die sie nicht verstehen. Wenn der Grund für die Nutzung einer Bridge unklar ist, lohnt es sich möglicherweise nicht, dieses Risiko einzugehen.

Welche Protokolle sollten geändert werden?

Was die Protokolle angeht, setzt der Vorfall bei Garden Finance einen höheren Maßstab.

Solver-Netzwerke benötigen eine klarere Steuerung. In den Protokollen sollte festgelegt werden, wie Solver zugelassen, überwacht, eingeschränkt und entfernt werden. Werden Solver als unabhängig beschrieben, sollte die Abgrenzung zwischen dem Solver und dem Protokoll so transparent sein, dass sie für die Nutzer nachvollziehbar ist.

Die Expositionsgrenzen sollten strenger sein. Ein kompromittierter Teilnehmer sollte nicht in der Lage sein, einen großen Betrag abzuziehen, bevor das System reagiert. Obergrenzen, Schutzschalter und die Erkennung von Anomalien können das Ausmaß des Schadens verringern.

Die Reaktion auf Vorfälle sollte einstudiert werden. Im DeFi-Bereich zählt jede Minute. Protokolle benötigen einen Plan für die Aussetzung der Frontends, die Benachrichtigung der Nutzer, die Rückverfolgung von Geldern, die Koordination mit Börsen und die Einbindung von Sicherheitsfirmen. Eine improvisierte Reaktion kann einen schlimmen Vorfall noch verschlimmern.

Die Kommunikation gegenüber der Öffentlichkeit sollte präzise sein. Die Nutzer brauchen keine theatralischen Beschwichtigungen. Sie müssen wissen, was passiert ist, welche Fonds betroffen sind, welche Risiken weiterhin bestehen, welche Systeme vorübergehend außer Betrieb sind und welche nächsten Schritte das Team unternimmt.

Schließlich sollten Protokolle die Betriebssicherheit als Teil der Produktqualität betrachten. Die Solver-Infrastruktur, die Schlüsselverwaltung, der Cloud-Zugriff, interne Berechtigungen und Überwachungssysteme sind für das Protokoll nicht zweitrangig. Sie sind Teil der praktischen Sicherheit des Protokolls.

Die übergeordnete Erkenntnis für DeFi

Der Hack bei Garden Finance gehört historisch gesehen nicht zu den größten Krypto-Vorfällen. Er ist weitaus kleiner als der Angriff auf die Ronin-Bridge, der Exploit bei Poly Network oder der Diebstahl bei Bybit. Die Hack-Datenbank von DeFiLlama weist nach wie vor kumulierte Verluste in Milliardenhöhe bei DeFi- und Bridge-Vorfällen aus, was verdeutlicht, wie hartnäckig dieses Problem nach wie vor ist.

Die Bedeutung liegt eher im Detail. Es zeigt, dass mit zunehmender Abstraktion und Benutzerfreundlichkeit von DeFi die Risiken immer schwerer zu lokalisieren sind. Der Nutzer interagiert zwar nicht mehr direkt mit jedem technischen Schritt, aber jemand oder etwas führt diese Schritte dennoch aus. Wenn dieser Akteur kompromittiert, unterkapitalisiert, unzureichend überwacht oder schlecht geführt ist, kann das System versagen, selbst wenn die Benutzererfahrung auf den ersten Blick einwandfrei erscheint.

Das ist die nächste Herausforderung für die DeFi-Infrastruktur. Bessere Schnittstellen werden nicht ausreichen. Effizientere Solver werden nicht ausreichen. Schnellere Brücken werden nicht ausreichen. Die Branche braucht eine klarere Verantwortungszuweisung für die operative Ebene, die zwischen den Nutzern und den Protokollen liegt.

Das Versprechen von DeFi war schon immer, dass Nutzer nicht auf undurchsichtige Zwischenhändler angewiesen sein sollten. Wenn Brücken jedoch von Solvern, Relayern und Off-Chain-Betreibern abhängig sind, muss die Branche ehrlich zugeben, an welcher Stelle wieder Vertrauen ins System eingezogen ist.

Der Vorfall bei Garden Finance macht deutlich, dass Dezentralisierung kein bloßes Etikett ist. Es handelt sich vielmehr um eine Risikoarchitektur. Wenn die Architektur weiterhin von privilegierten Akteuren abhängt, muss das Sicherheitsmodell dies widerspiegeln. Andernfalls wird DeFi nach jedem Exploit immer wieder dieselbe Lektion lernen müssen: Die größte Schwachstelle liegt nicht immer im Code. Manchmal befindet sie sich in dem Teil des Systems, von dem alle annahmen, er sei lediglich Infrastruktur.