TL;DR

  • Eine kleine Gruppe wiederkehrender Fehlerklassen ist für den Großteil der Verluste auf Vertragsebene verantwortlich: Reentrancy, Orakelmanipulation, Fehler bei der Zugriffskontrolle, Rechen- und Validierungsfehler sowie fehlerhafte Geschäftslogik, die genau so funktioniert, wie sie geschrieben wurde. Jede Klasse hat einen berühmten „Leichnam“ an sich, wodurch die Branche gelernt hat, sie zu benennen.
  • Ein Audit prüft eine festgelegte Momentaufnahme des Codes anhand bekannter Schwachstellenklassen und der vom Team erklärten Absichten, und zwar im Rahmen eines Budgets an Expertenstunden; fast alles andere – Wirtschaftlichkeit, Orakel, Governance, Betrieb, Abhängigkeiten, die Zukunft – liegt außerhalb des Rahmens. Das Lesen des Abschnitts zum Umfang eines Auditberichts ist aufschlussreicher als das Betrachten seines Badges.
  • Weil die Verlustverteilung genau den Bereichen folgt, die bei Audits außer Acht gelassen werden: Änderungen nach dem Audit, ausgeschlossene Komponenten, protokollübergreifende Interaktionen, kompromittierte Abläufe und wirtschaftliches Design – zusätzlich zu den verbleibenden Fehlern, die bei der Stichprobenprüfung zwangsläufig übersehen werden. Die Liste der geprüften und dennoch gehackten Protokolle ist lang genug, um ein eigenes Genre zu bilden.
  • Mehrschichtig und unter der Annahme von Fehlern: mehrere unabhängige Überprüfungen, formale Methoden und Fuzzing dort, wo sie am wirksamsten sind, kontinuierliche Überwachung, wirtschaftliche Schutzmechanismen, zeitgesteuerte Änderungen, Bug-Bounties und ein einstudierter Plan für den Fall, dass doch einmal etwas durchrutscht. Jede Schicht fängt ein anderes Fehlerprofil ab – genau darin liegt der Sinn der Schichtung.
In einem Block

Ein Smart-Contract-Audit ist eine strukturierte Expertenprüfung des Vertragscodes, bei der vor der Bereitstellung nach bekannten Schwachstellenklassen, Abweichungen von der Spezifikation und gefährlichen Mustern gesucht wird. Es handelt sich um eine zeitpunktbezogene Bewertung einer Code-Version unter festgelegten Annahmen.

Was geht bei Smart Contracts tatsächlich schief?

Schnelle Antwort

Eine kleine Gruppe wiederkehrender Fehlerklassen ist für den Großteil der Verluste auf Vertragsebene verantwortlich: Reentrancy, Orakelmanipulation, Fehler bei der Zugriffskontrolle, Rechen- und Validierungsfehler sowie fehlerhafte Geschäftslogik, die genau so funktioniert, wie sie geschrieben wurde. Jede Klasse hat einen berühmten „Leichnam“ an sich, wodurch die Branche gelernt hat, sie zu benennen.

Reentrancy ist der Klassiker. Ein Vertrag sendet einen Wert an eine externe Adresse, bevor er seinen eigenen Zustand aktualisiert, und der Empfänger – ebenfalls ein Vertrag – ruft zurück, bevor die Aktualisierung wirksam wird, und entzieht so in einer Schleife den Wert. Der DAO-Hack von 2016, bei dem damals rund 60 Millionen Dollar verloren gingen, etablierte diese Fehlerklasse und spaltete Ethereum in zwei Teile. Ein Jahrzehnt später taucht Reentrancy immer noch auf, manchmal in exotischen Formen: Der Curve-Vorfall von 2023, bei dem über verschiedene Pools hinweg rund 70 Millionen Dollar verloren gingen, entstand durch ein Versagen der Reentrancy-Sicherung in bestimmten Versionen des Vyper-Compilers selbst – das heißt, Verträge, deren Quelllogik fehlerfrei war, wurden zu fehlerhaftem Bytecode kompiliert. Prüfer, die den Quellcode lasen, konnten das Problem sofort erkennen.

Oracle-Manipulationen greifen die Eingaben an. Ein Vertrag, der einem Preis-Feed vertraut, kann durch Verfälschung des Preises ausgeraubt werden, und Flash-Kredite stellen das Kapital für diese Verfälschung innerhalb einer einzigen atomaren Transaktion bereit. Mango Markets – rund 114 Millionen Dollar im Jahr 2022 – ist der klassische Fall, und die Mechanismen sind nach wie vor alltäglich; der Schwerpunkt dieses Clusters analysiert das Muster.

Fehler bei der Zugriffskontrolle sind die peinliche Kategorie: Funktionen, die jeder aufrufen kann, weil ein Modifizierer fehlt, offen gelassene Initialisierer, privilegierte Rollen, die durch Deployer-Schlüssel beibehalten werden. Die Vorfälle mit der Parity-Wallet aus dem Jahr 2017, bei denen mehrere zehn Millionen gestohlen und über 150 Millionen Dollar dauerhaft eingefroren wurden, lassen sich beide auf diese Fehler zurückführen.

Rechen- und Validierungsfehler bestehen trotz sicherer Sprachen fort. Bei Cetus, der größten DEX auf Sui, wurden im Mai 2025 etwa 223 Millionen Dollar ausgenutzt, weil eine Überlaufprüfung mit der falschen Konstante verglichen wurde, wodurch ein manipulierter Wert die Validierung passierte und die Liquiditätsabrechnung verfälschte. Der Vertrag war laut den Nachanalysen des Vorfalls mehr als einmal geprüft worden. Die Folgen sind für die Akten wichtig: Rund 162 Millionen Dollar wurden durch koordinierte Maßnahmen der Validatoren eingefroren und per Community-Abstimmung in einen Wiederherstellungs- und Entschädigungsprozess überführt. Der Brutto-Ausbeutungswert und der eingefrorene oder zur Wiederherstellung weitergeleitete Wert sollten separat ausgewiesen werden, und eine endgültige Nettoverlustsumme sollte erst dann angegeben werden, wenn eine datierte Abrechnung vorliegt, anstatt von Annahmen auszugehen.

Schließlich ein reiner Logikfehler: Code, der kompiliert wird, Tests besteht, das tut, was er verspricht, und dabei das Falsche angibt. Der Verlust von Euler Finance in Höhe von 197 Millionen Dollar im Jahr 2023 entstand durch die Kombination eines Spendenmechanismus mit einer Liquidationslogik auf eine Weise, die aus keiner einzelnen Codezeile ersichtlich war. Für diese Klasse gibt es keinen Scanner, da technisch gesehen nichts defekt ist – außer der Idee selbst.

Was wird bei einem Audit tatsächlich geprüft, und was liegt von vornherein außerhalb des Prüfungsumfangs?

Schnelle Antwort

Ein Audit prüft eine festgelegte Momentaufnahme des Codes anhand bekannter Schwachstellenklassen und der vom Team erklärten Absichten, und zwar im Rahmen eines Budgets an Expertenstunden; fast alles andere – Wirtschaftlichkeit, Orakel, Governance, Betrieb, Abhängigkeiten, die Zukunft – liegt außerhalb des Rahmens. Das Lesen des Abschnitts zum Umfang eines Auditberichts ist aufschlussreicher als das Betrachten seines Badges.

Ein seriöses Audit umfasst eine manuelle Überprüfung durch erfahrene Forscher, statische Analysen, Tests anhand der Spezifikation sowie einen Bericht, in dem die Ergebnisse nach Schweregrad eingestuft werden. Wenn die Spezifikation des Teams falsch ist, vergleicht das Audit den Code mit einem falschen Ziel; wenn die Spezifikation keine Angaben enthält, leiten die Prüfer die Absicht ab. Beides sind stille Ursachen für Übersehen.

Es lohnt sich, die strukturellen Grenzen klar aufzulisten. Ein Audit ist zeitpunktbezogen: Der überprüfte Commit ist das, was untersucht wurde, das drei Monate später veröffentlichte Upgrade hingegen nicht. Es ist im Umfang begrenzt: Periphere Verträge, Deployment-Skripte, Admin-Tools und Integrationen werden aus Budgetgründen häufig ausgeschlossen. Sie ist voller Annahmen: Berichte gehen routinemäßig von ehrlichen Orakeln, soliden Token und vertrauenswürdigen Admin-Schlüsseln aus – genau die Annahmen, die Angreifer nicht teilen wollen. Sie ist wirtschaftlich blind, sofern keine separate wirtschaftliche Überprüfung in Auftrag gegeben wird: Solvenz unter Manipulation, Anreizversagen und toxische Kombinierbarkeit mit anderen aktiven Protokollen sind eine eigene Disziplin. Und sie ist stapeloberflächlich: Der Compiler, die virtuelle Maschine und die darunterliegende Node-Software fallen fast nie in den Untersuchungsumfang – genau dort lag jedoch der Ursprung des Curve-Vorfalls.

Zeitdruck verschärft all dies noch. Prüfungsfirmen untersuchen nur einen Ausschnitt des Suchraums, während Angreifer nach der Bereitstellung über unbegrenzte Zeit, den Live-Zustand und die Kombinierbarkeit der gesamten Blockchain als Werkzeuge verfügen. Die Asymmetrie ist struktureller Natur: Prüfer müssen im Rahmen eines festgelegten Auftrags an alles denken; einem Angreifer reicht eine einzige Sache, die alle übersehen haben – und zwar für immer.

Nichts davon ist ein Argument gegen Audits. Es ist ein Argument dafür, „geprüft“ als „von Experten unter Einschränkungen stichprobenartig untersucht“ zu verstehen, was das Gütesiegel auf das abstimmt, was es tatsächlich ausmacht.

Diagram of smart contract audit scope showing reviewed code at the centre surrounded by out-of-scope risks including oracles, upgrades, governance, economics, compiler and operations
Abbildung 1. Was ein Smart-Contract-Audit abdeckt und die Fehlerfläche außerhalb seines Rahmens.

Warum verlieren geprüfte Protokolle immer noch Hunderte von Millionen?

Schnelle Antwort

Weil die Verlustverteilung genau den Bereichen folgt, die bei Audits außer Acht gelassen werden: Änderungen nach dem Audit, ausgeschlossene Komponenten, protokollübergreifende Interaktionen, kompromittierte Abläufe und wirtschaftliches Design – zusätzlich zu den verbleibenden Fehlern, die bei der Stichprobenprüfung zwangsläufig übersehen werden. Die Liste der geprüften und dennoch gehackten Protokolle ist lang genug, um ein eigenes Genre zu bilden.

Aktuelle Daten machen das Muster quantifizierbar. TRM Labs zählte im ersten Halbjahr 2026 207 Vorfälle – eine Rekordzahl –, doch die Gesamtverluste lagen unter einer Milliarde Dollar, was einem Rückgang von 58 Prozent gegenüber dem Vorjahr entspricht; Exploits von Smart Contracts machten etwa 60 Prozent der Vorfälle aus, aber nur einen kleinen Bruchteil des Wertes, während Angriffe auf die Infrastruktur, Schlüssel, Signaturumgebungen und den operativen Zugriff etwa 76 Prozent des Geldes aus etwa 15 Prozent der Vorfälle ausmachten. Die Zahlen für 2025 zeigten dasselbe Bild noch drastischer: Rund 3,4 Milliarden Dollar wurden gestohlen, wobei der 1,5-Milliarden-Dollar-Diebstahl bei Bybit dominierte, bei dem ein Signatur-Workflow und nicht ein Vertrag angegriffen wurde. Angreifer verlagern sich auf die schwächste Ebene, und jahrelange Audits haben dazu geführt, dass Fehler in Verträgen im Vergleich zum operativen Bereich schwieriger auszunutzen sind.

Wenn geprüfter Code selbst versagt, erklärt die Taxonomie aus den vorangegangenen Abschnitten in der Regel, warum. Cetus: eine Feinheit bei der Validierung in einem ungewöhnlichen Sprachkontext, die bereits von mehreren Firmen in der Vergangenheit getestet wurde, wobei der größte Teil des ausgenutzten Wertes später eingefroren und der Wiederherstellung zugeführt wurde. Euler: sich über Funktionen hinweg entwickelnde Logik, wobei jede für sich lokal korrekt ist. Curve: die Ebene unterhalb des Quellcodes. Darüber hinaus entsteht ein stetiger Strom kleinerer Vorfälle durch Upgrades, die nach der Überprüfung ausgeliefert wurden, durch Admin-Schlüssel, die trotz makelloser Verträge nachlässig gehandhabt werden, sowie durch Protokolle, die mit Token und Märkten interagieren, die ihr Modell nie vorgesehen hatte.

Hinzu kommt die Ökonomie der Knappheit: Erstklassige Prüfkapazitäten sind begrenzt und teuer, sodass Projekte mit einem Audit veröffentlicht werden, obwohl das Risiko drei rechtfertigen würde, oder mit einer Prüfung auf Marketing-Niveau durch ein Unternehmen, das aufgrund seiner kurzen Bearbeitungszeit ausgewählt wurde. Das Audit-Siegel fasst all diese Unterschiede in einem Wort zusammen, weshalb versierte Investoren die Berichte lesen, die Commit-Hashes mit dem tatsächlich Deployten abgleichen und ein ungeprüftes Upgrade eines geprüften Protokolls als ungeprüften Code behandeln.

Chart comparing smart contract exploits at sixty percent of incidents with a small share of losses against infrastructure and key compromises at fifteen percent of incidents and seventy-six percent of value, per TRM Labs
Abbildung 2. 1. Halbjahr 2026: Anteil der Vorfälle im Vergleich zum Wertanteil nach Angriffstyp.

Wie sieht ein seriöser Sicherheitsstack über das Audit hinaus aus?

Schnelle Antwort

Mehrschichtig und unter der Annahme von Fehlern: mehrere unabhängige Überprüfungen, formale Methoden und Fuzzing dort, wo sie am wirksamsten sind, kontinuierliche Überwachung, wirtschaftliche Schutzmechanismen, zeitgesteuerte Änderungen, Bug-Bounties und ein einstudierter Plan für den Fall, dass doch einmal etwas durchrutscht. Jede Schicht fängt ein anderes Fehlerprofil ab – genau darin liegt der Sinn der Schichtung.

Redundante Überprüfungen decken Lücken auf, die durch die Prüfer selbst verursacht werden: verschiedene Unternehmen, verschiedene Methoden, verschiedene blinde Flecken sowie Wettbewerbsplattformen, auf denen Hunderte unabhängiger Forscher denselben Code unter die Lupe nehmen. Die formale Verifikation belegt bestimmte Eigenschaften – Konservierung, Zugriffsinvarianten – anhand eines mathematischen Modells; ihre Grenze besteht darin, dass sie nur die Eigenschaften verifiziert, an deren Formulierung jemand gedacht hat. Fuzzing und Invariante-Tests durchkämmen den Zustandsraum mechanisch und zeichnen sich besonders bei der Validierung an den Rändern der Cetus-Klasse aus; sie sind so kostengünstig, dass ihr Fehlen mittlerweile ein Warnsignal darstellt.

Bug-Bounties verändern den Markt: Ein dauerhaftes Angebot, dessen Höhe sinnvoll am Risikowert ausgerichtet ist, verschafft dem Forscher, der die Schwachstelle findet, eine legale Belohnung, die mit kriminellen Gewinnen konkurrieren kann. Die größten DeFi-Bounties haben Millionen ausgezahlt und waren dabei kostengünstig.

Laufzeit-Abwehrmaßnahmen gehen davon aus, dass Prävention mit der Bereitstellung endet. Die Überwachung beobachtet Mempools und den Systemzustand auf Anzeichen von Angriffen; Circuit Breaker begrenzen Abflüsse pro Block oder unterbrechen den Betrieb bei Anomalien; Zeitverriegelungen bei Upgrades und Parameteränderungen geben der Community Tage Zeit, um zu prüfen, was die Governance genehmigt hat, bevor es live geht, wodurch heimliche Änderungen in öffentliche umgewandelt werden. Ratenbegrenzungen wandeln vollständige Abflüsse in teilweise Abflüsse um – dieselbe Philosophie des begrenzten Schadensumfangs, die sich durch die Artikel dieser Akademie zum Thema Verwahrung zieht.

Und da die Verlustdaten zeigen, dass der Betrieb mittlerweile mehr Gewicht hat als der Code: Die Schlüssel, mit denen Verträge verwaltet werden, verdienen die gleiche Sorgfalt wie die Verträge selbst. Verteilte Signaturberechtigung, Quorum-Genehmigung, eindeutige Signatur auf unabhängigen Geräten und kein einzelner Betreiber, der einen Treasury-Vertrag allein aktualisieren kann. Der Bybit-Vorfall ist die ständige Mahnung, dass ein perfekter Vertrag, der über einen korrumpierbaren Workflow verwaltet wird, ein perfekter Vertrag mit einer Hintertür ist.

Für einen Nutzer oder Allokator lässt sich die Checkliste auf folgende Fragen reduzieren: Wie viele unabhängige Überprüfungen des bereitgestellten Commits gibt es? Was können Admin-Schlüssel tun, mit welcher Verzögerung und welchem Quorum? Was bringt das Protokoll wirtschaftlich zum Scheitern, und veröffentlicht das Team diese Analyse? Wie hoch ist die Prämie? Wie sieht der Pausenplan aus? Protokolle, die diese Fragen in öffentlicher Dokumentation beantworten, geben Aufschluss über ihre Sicherheitskultur; Protokolle, die mit einem Abzeichen antworten, sagen ebenfalls etwas aus.

Wie sollte ein Experte einen Auditbericht lesen?

Schnelle Antwort

Von hinten: zuerst Umfang und Annahmen, dann ungelöste Befunde, an dritter Stelle die Übereinstimmung mit dem bereitgestellten Commit und zuletzt, wenn überhaupt, die Marketingzusammenfassung. Ein Bericht ist ein Beleg für die Prozessqualität und lässt sich am sinnvollsten als Übersicht darüber lesen, was NICHT abgedeckt wurde.

Beginnen Sie mit dem Umfang. Welche Verträge, welcher Commit, was wurde ausgeschlossen, und stimmt der bereitgestellte Bytecode mit dem geprüften Code überein? Block-Explorer machen die Überprüfung praktikabel, und Abweichungen kommen häufig genug vor, um sie routinemäßig zu überprüfen. Ein Audit von Commit A sagt nichts über Commit B aus.

Lesen Sie die Annahmen als Liste der Angriffsflächen. „Wir gehen davon aus, dass der Administrator ehrlich ist“ bedeutet, dass die Kompromittierung des Administrator-Schlüssels ein Risiko darstellt, das Sie einkalkulieren müssen. „Das Verhalten von Oracle liegt außerhalb des Umfangs“ bedeutet, dass das Mango-Muster nicht untersucht wurde. Jede genannte Annahme ist eine Grenze, an der die Überprüfung endete, und Grenzen sind genau die Stellen, an denen Angreifer zuschlagen.

Bewerten Sie die Befunde eher nach der Reaktion darauf als nach ihrer Anzahl. Ein Bericht mit einem Dutzend behobener kritischer Fehler kann auf ein engagiertes Team und gründliche Prüfer hindeuten; ein fehlerfreier Bericht kann hingegen auf eine oberflächliche Prüfung hindeuten. Ein alarmierendes Muster ist, wenn Befunde anerkannt und trotzdem implementiert oder auf eine Weise behoben wurden, die die Prüfer nie erneut überprüft haben. Prüfen Sie, ob eine Nachprüfung der Korrekturen stattgefunden hat; durch die Korrektur verursachte Fehler sind ein häufig auftretendes Phänomen.

Schließlich muss der Bericht in einen zeitlichen Kontext gestellt werden. Wie alt ist er, wie viele Upgrades wurden seitdem veröffentlicht, und berücksichtigt das Changelog des Protokolls den Grundsatz, dass geänderter Code ungeprüfter Code ist? Bei einem Protokoll, das sich in aktiver Entwicklung befindet, ist das aussagekräftige Element eine Sicherheitspipeline – Überprüfungen bei jeder Veröffentlichung, ein dauerhaftes Kopfgeldprogramm, Überwachung – und nicht ein einzelnes Dokument. Ein aussagekräftiger Bericht von vor Jahren ist ein Artefakt, und Artefakte sichern keine live betriebenen Systeme.

Die disziplinierte Zusammenfassung: Audits sind notwendig, informativ und unzureichend, und die Fachleute, die sie in Auftrag geben, würden dasselbe sagen. Ihr eigentliches Ergebnis ist eine Verringerung des Unbekannten, und Unbekanntes wird gemanagt, niemals beseitigt.

Häufig gestellte Fragen

Ist ein auditiertes Protokoll sicher in der Anwendung?

Sicherer, mit großen Fehlermargen. Ein Audit verringert die Wahrscheinlichkeit, dass bekannte Schwachstellenklassen im geprüften Code verbleiben. Es lässt jedoch wirtschaftliche Aspekte des Designs, Orakel, Upgrades, den Betrieb und unentdeckte Schwachstellenklassen außer Acht, und die jüngsten Verlustdaten zeigen, dass der Großteil der gestohlenen Werte mittlerweile über diese Lücken abfließt. Betrachten Sie das Audit als einen von vielen Faktoren neben Richtlinien für Administratorschlüssel, Zeitbeschränkungen, die Höhe von Kopfgeldern, Überwachung und der bisherigen Erfolgsbilanz.

Warum nicht einfach so lange prüfen, bis nichts mehr zu finden ist?

Weil eine Überprüfung unter Budgetbeschränkungen nur einen effektiv unbegrenzten Suchraum abtastet, während Angreifer diesen im Live-Zustand unbegrenzt durchsuchen. Mehr Überprüfungen verringern das Restrisiko mit abnehmendem Ertrag; es kann nicht auf Null sinken, und die Klassen, für die Audits strukturell blind sind – zukünftige Änderungen, neu entstehende Kombinierbarkeit, kompromittierte Betreiber –, lassen sich durch zusätzliche Arbeitsstunden der Prüfer nicht verringern. Deshalb investieren ausgereifte Stacks das letzte Pfund in Kopfgelder, Fuzzing, Überwachung und die Begrenzung des Schadensumfangs, anstatt in ein fünftes identisches Audit.

Was ist der Unterschied zwischen einem Audit und einer formalen Verifikation?

Ein Audit ist eine Expertenprüfung: Menschen und Tools suchen nach Problemen. Formale Verifikation ist der mathematische Beweis, dass der Code explizit festgelegte Eigenschaften unter einem Modell erfüllt. Verifikation ist dort stärker, wo sie anwendbar ist, und nur so gut wie die Eigenschaften und das Modell; ein als korrekt bewiesener Vertrag mit einer nicht festgelegten Eigenschaft oder einer falschen Spezifikation scheitert formal, auch wenn er an sich intakt ist. Die stärksten Pipelines nutzen beides – und zwar bei den Komponenten, auf die es am meisten ankommt.

Funktionieren Bug-Bounties tatsächlich?

Die Anreizlogik ist stichhaltig und die Bilanz untermauert dies: Große Plattformen haben Auszahlungen in Millionenhöhe für kritische Befunde vermittelt, die die Protokolle im Live-Betrieb Hunderte von Millionen gekostet hätten. Die Glaubwürdigkeit eines Kopfgeldprogramms ist wichtiger als seine Schlagzeile: klarer Umfang, schnelle Triage, zuverlässige Bezahlung und keine Vorgeschichte, Forscher zu prellen. Ein nicht finanziertes oder feindseliges Kopfgeldprogramm ist schlimmer als gar keines, da es Forscher dazu bringt, ihre Funde anderweitig zu verkaufen.

Was ist für einen Nutzer der beste Indikator für die Sicherheitskultur eines Protokolls?

Schauen Sie sich an, was mit der Macht geschieht: Was Admin-Schlüssel bewirken können, wer sie besitzt, hinter welcher Zeitsperre und welchem Quorum sie stehen und ob dies öffentlich dokumentiert ist. Teams, die sich sichtbar Einschränkungen auferlegen, Upgrades verzögern, verteilte Signaturen nutzen, wirtschaftliche Analysen veröffentlichen und Kopfgeldprogramme finanzieren, zeigen Ihnen eine Kultur. Die Anzahl der Badges ist die am wenigsten aussagekräftige Zahl auf der Seite.

Quellen und weiterführende Literatur

Wichtige Quellenangaben zu diesem Artikel, Stand: Juli 2026. Schwankende Zahlen werden bei jeder vierteljährlichen Überprüfung erneut überprüft.

Kurzes Quiz: Hat es geklebt?

Ein paar Fragen zur Überprüfung der Grundlagen sind gelandet. Es folgen Antworten mit Erläuterungen und niemand außer Ihrem zukünftigen Portfolio bewertet Sie.

1/5 Frage
Was genau ist ein Smart-Contract-Audit?

War das hilfreich?