So bewertest du einen Smart-Contract-Auditbericht
Ein Smart-Contract-Auditbericht ist keine Sicherheitsgarantie. Erfahre, wie du Umfang, Befunde, Korrekturen und die Glaubwürdigkeit des Auditors prüfst – und woran du gefälschte Audits erkennst.
Um einen Smart-Contract-Auditbericht zu bewerten, stellst du sicher, dass er echt ist und vom Auditor veröffentlicht wurde, prüfst, ob sein Umfang die tatsächlich deployten Verträge abdeckt, liest die kritischen und hoch eingestuften Befunde und ob jeder behoben wurde, und notierst, was das Audit ausdrücklich nicht abgedeckt hat. Ein Audit ist eine Momentaufnahme eines bestimmten Codes, keine Garantie dafür, dass ein Projekt sicher oder ehrlich ist.
Projekte werben oft mit „auditiert“ als Vertrauenssiegel. Manche Audits sind gründlich und aussagekräftig, andere eng gefasst, veraltet oder gefälscht. Wenn du weißt, wie man den Bericht liest, erkennst du den Unterschied in etwa fünfzehn Minuten.
Was ein Smart-Contract-Audit ist
Ein Smart-Contract-Audit ist eine Sicherheitsprüfung, bei der Spezialisten den Code eines Projekts lesen, testen und nach Schwachstellen wie Reentrancy, Fehlern in der Zugriffskontrolle, Rechenfehlern und Logikfehlern suchen. Anschließend veröffentlichen sie einen Bericht, der auflistet, was sie gefunden haben, wie schwerwiegend jedes Problem ist und wie das Team reagiert hat. Weiterführend: Smart-Contract-Exploits.
Audits sind wertvoll, weil Smart Contracts nach dem Deployment schwer zu ändern sind und oft große Geldbeträge verwalten. Auditoren arbeiten aber unter Zeitdruck, prüfen nur, was ihnen vorgelegt wird, und können subtile Probleme übersehen. Viele angegriffene Protokolle waren auditiert.
Die Abschnitte eines typischen Auditberichts
| Abschnitt | Worauf du achten solltest |
|---|---|
| Zusammenfassung | Name des Auditors, Projekt, Daten, Gesamtfazit |
| Umfang | Genaue Dateien, Verträge, Commit-Hash oder geprüfte deployte Adressen |
| Methodik | Manuelle Prüfung, automatisierte Tools, Tests, formale Verifikation |
| Befunde | Jedes Problem mit Schweregrad, Beschreibung und Empfehlung |
| Status | Ob jeder Befund behoben, zur Kenntnis genommen oder bestritten wurde |
| Haftungsausschluss | Grenzen der Prüfung |
Schritt für Schritt: So bewertest du den Bericht
1. Prüfe, ob der Bericht echt ist
Gefälschte Audits sind eine bekannte Betrugsmasche. Suche den Bericht auf der offiziellen Website oder dem GitHub des Auditors, die du selbstständig aufrufst. Wenn der Auditor das Projekt nicht kennt oder der Bericht nur als PDF auf der Seite des Projekts existiert, behandle ihn als unbestätigt. Unser Leitfaden zu gefälschten Audits listet gängige Tricks auf.
2. Gleiche den Umfang mit dem Deployten ab
Der Bericht sollte einen Code-Commit oder Vertragsadressen nennen. Prüfe in einem Block-Explorer, ob die deployten Verträge übereinstimmen. Häufige Lücken:
- Das Audit betraf eine frühere Version, und der Code wurde danach geändert.
- Nur der Token-Vertrag wurde geprüft, nicht die Staking-, Vault- oder Bridge-Verträge, die Nutzergelder halten.
- Die Verträge sind upgradefähig, sodass der Code später ersetzt werden kann.
3. Lies zuerst die schwerwiegenden Befunde
Gehe direkt zu den kritischen und hoch eingestuften Problemen. Frage dich bei jedem:
- Ist es als gelöst markiert, und hat der Auditor die Korrektur verifiziert?
- Wenn es nur „zur Kenntnis genommen“ statt behoben wurde: Wie begründet das Team das?
- Betrifft es Admin-Rechte, etwa die Möglichkeit, Tokens zu minten, Transfers zu pausieren oder Gelder abzuziehen?
Zur Kenntnis genommene Zentralisierungsprobleme sind für Investoren oft wichtiger als Code-Fehler. Ein Owner, der unbegrenzt Tokens minten kann, ist ein Risiko, selbst wenn der Code einwandfrei funktioniert.
4. Prüfe die Daten
Notiere, wann das Audit durchgeführt wurde, und vergleiche das mit dem Deployment-Datum und späteren Upgrades. Ein altes Audit eines häufig aktualisierten Protokolls sagt wenig über den heutigen Code aus.
5. Bewerte den Auditor
Achte auf Auditoren mit öffentlicher Erfolgsbilanz, ausführlichen veröffentlichten Berichten und namentlich genannten Sicherheitsforschern. Ein einseitiger Bericht ohne Details von einer Firma, die Hunderte Tokens pro Monat prüft, hat weniger Gewicht.
6. Lies Haftungsausschluss und Einschränkungen
Haftungsausschlüsse besagen meist, dass das Audit weder das ökonomische Design noch Off-Chain-Komponenten, Orakel, Frontend-Code oder künftige Änderungen abdeckt. Genau in diesen Bereichen entstehen viele reale Verluste.
Die Schweregrade verstehen
Die meisten Auditoren nutzen eine ähnliche Skala, auch wenn sich die Definitionen zwischen Firmen unterscheiden:
| Schweregrad | Typische Bedeutung | Wie sehr es dich beunruhigen sollte |
|---|---|---|
| Kritisch | Direkter Verlust oder Diebstahl von Geldern ist möglich | Muss vor dem Start behoben sein; ungelöst heißt: Finger weg |
| Hoch | Schwerer Geldverlust oder defekte Kernfunktionen unter bestimmten Bedingungen | Sollte behoben sein; prüfe, ob der Auditor es bestätigt hat |
| Mittel | Probleme unter bestimmten Umständen oder erhebliche Zentralisierung | Sorgfältig lesen, besonders Befunde zu Admin-Befugnissen |
| Niedrig | Kleinere Probleme mit begrenzter Auswirkung | Meist unbedenklich, wenn zur Kenntnis genommen |
| Informativ | Codequalität, Gas-Effizienz, Best Practices | Für Nutzer selten ein Problem |
Ein Bericht mit vielen Befunden ist nicht unbedingt eine schlechte Nachricht. Er kann bedeuten, dass der Auditor gründlich war und das Team Probleme vor dem Start behoben hat. Entscheidend ist, wie schwerwiegend das ist, was ungelöst bleibt, und wie das Team reagiert hat. Ein Team, das jeden Befund bestreitet oder schwerwiegende stillschweigend ignoriert, verrät etwas über seine Sicherheitskultur.
Warnsignale in Auditberichten
- Keine Angaben zum Umfang, kein Commit-Hash und keine Vertragsadressen.
- Kritische Probleme, die als „zur Kenntnis genommen“ ohne Korrektur aufgeführt sind.
- Befunde zu Owner-Rechten, die das Projekt herunterspielt.
- Der Bericht wird nur vom Projekt gehostet.
- Werbeaussagen wie „100 % sicher“ oder „durch Audit vollständig abgesichert“.
- Das Audit ist lange vor größeren Codeänderungen datiert.
Was ein Audit dir nicht sagt
Selbst ein starkes Audit beantwortet nicht:
- Ob das Team echt und vertrauenswürdig ist – siehe So prüfst du, ob ein Krypto-Team echt ist.
- Ob die Liquidität gesperrt ist oder abgezogen werden kann.
- Ob das Token-Angebot und die Unlocks fair sind.
- Ob das ökonomische Design des Protokolls unter Stress versagen kann.
Kombiniere das Audit mit weiteren Prüfungen, etwa einem öffentlichen Bug-Bounty-Programm, mehreren unabhängigen Audits, Zeit im Produktivbetrieb ohne Vorfälle und transparenten Admin-Kontrollen.
Fazit
Ein Auditbericht ist nur dann ein nützlicher Beleg, wenn er echt und aktuell ist und die Verträge abdeckt, die du tatsächlich nutzt. Prüfe die Quelle, gleiche den Umfang ab, lies die schwerwiegenden Befunde und wie sie gelöst wurden, und achte darauf, was ausgelassen wurde. Nutze ihn als einen Baustein deiner Recherche, niemals als Beweis dafür, dass ein Projekt sicher ist.
Häufig gestellte Fragen
Bedeutet ein Audit, dass ein Kryptoprojekt sicher ist?
Nein. Ein Audit ist die Prüfung eines bestimmten Codes zu einem bestimmten Zeitpunkt durch ein bestimmtes Team. Es kann Fehler übersehen, sagt nichts über die Ehrlichkeit des Teams oder die Tokenomics aus und deckt keinen Code ab, der nach der Prüfung geändert wurde. Viele angegriffene Protokolle waren auditiert. Betrachte ein Audit als ein Indiz unter mehreren, nicht als Garantie.
Wie erkenne ich, ob ein Auditbericht echt ist?
Suche den Bericht auf der eigenen Website oder dem offiziellen GitHub des Auditors, nicht nur auf der Seite des Projekts. Prüfe, ob die Vertragsadressen oder der Code-Commit im Bericht mit dem übereinstimmen, was tatsächlich deployt ist. Manche Auditoren ermöglichen eine direkte Überprüfung ihrer Berichte. Ein PDF, das nur in den Kanälen des Projekts existiert, reicht nicht aus.
Was bedeuten die Schweregrade in einem Audit?
Auditoren stufen Befunde meist als kritisch, hoch, mittel, niedrig und informativ ein. Kritische und hohe Probleme können zum Verlust von Geldern oder zu einem funktionsunfähigen Protokoll führen. Entscheidend ist, ob diese schwerwiegenden Befunde behoben wurden und ob der Auditor die Korrektur in einer Folgeprüfung bestätigt hat.
Reicht ein einziges Audit?
Für große Protokolle, die erhebliche Nutzergelder verwalten, gilt ein Audit oft als Minimum. Mehrere unabhängige Audits, ein öffentliches Bug-Bounty-Programm, formale Verifikation zentraler Komponenten und eine lange Erfolgsbilanz ohne Vorfälle liefern zusammen weit stärkere Belege als ein einzelner Bericht.