Smart Contract Audit selbst prüfen: die Anleitung

• Ein Selbst-Audit ist eine systematische Sicherheitsprüfung Ihres Solidity-Codes, kein Ersatz für ein externes Audit bei echtem Kapitalrisiko.
• Rechnen Sie für einen einfachen ERC-20-Vertrag mit 2 bis 3 Tagen Arbeit, für komplexe DeFi-Protokolle mit mehreren Wochen.
• Kombinieren Sie statische Analyse (Slither), symbolische Ausführung (Mythril), Fuzzing (Echidna) und manuelles Lesen.
• Prüfen Sie zuerst Reentrancy, Zugriffskontrolle, Integer-Fehler und Orakel-Manipulation.
• Dokumentieren Sie jeden Fund mit Schweregrad, sonst ist die Prüfung wertlos.

Was ist ein Smart Contract Audit überhaupt?

Ein Smart Contract Audit ist eine systematische Sicherheitsüberprüfung des Quellcodes eines Blockchain-Vertrags, bei der Schwachstellen, Logikfehler und wirtschaftliche Angriffsflächen vor dem Deployment identifiziert werden. Klingt trocken, ist aber der Kern jeder Due Diligence im dezentralen Ökosystem.

Kurz gesagt :

• Ein Selbst-Audit ist eine systematische Sicherheitsprüfung des Solidity-Codes, ersetzt aber kein externes Audit bei echtem Kapitalrisiko.
• Der Zeitaufwand liegt bei 2–3 Tagen für einen einfachen ERC-20-Vertrag und mehreren Wochen für komplexe DeFi-Protokolle.
• Zur Prüfung kombiniert man statische Analyse (Slither), symbolische Ausführung (Mythril), Fuzzing (Echidna) und manuelles Lesen.
• Geprüft werden zuerst Reentrancy, Zugriffskontrolle, Integer-Fehler und Orakel-Manipulation, jeder Fund wird mit Schweregrad dokumentiert.

Ich promoviere in Wirtschaftsinformatik und beschäftige mich seit den frühen Tagen des Bitcoin mit Blockchain-Technologien. In dieser Zeit habe ich gelernt: Die meisten Verluste entstehen nicht durch exotische Zero-Days, sondern durch bekannte Muster, die niemand geprüft hat. Das ist die gute Nachricht — bekannte Muster kann man lernen.

Warum ein Selbst-Audit trotzdem sinnvoll ist

Ein Selbst-Audit senkt Ihre Kosten, beschleunigt die Vorbereitung auf ein professionelles Audit und zwingt Sie, den eigenen Code wirklich zu verstehen. Genau dieser Verständniszwang ist der unterschätzte Nutzen.

• Kosteneinsparung: Externe Audits in Frankreich liegen je nach Komplexität zwischen 5.000 und 50.000 Euro.
• Geschwindigkeit: Ein internes Erst-Audit verkürzt die spätere Prüfungsdauer spürbar.
• Lernkurve: Sie verstehen Ihre eigene Architektur deutlich besser.
• Kontinuität: Nach jeder Codeänderung können Sie erneut prüfen, ohne einen Dienstleister zu buchen.

Was ein Selbst-Audit nicht ersetzt

Ein Selbst-Audit ersetzt kein formales Audit durch spezialisierte Firmen. Bei Verträgen mit echtem Kapitalrisiko bleibt die unabhängige Prüfung Pflicht, besonders wenn Sie regulatorische Anforderungen in Frankreich erfüllen müssen.

Für Anbieter von Kryptodienstleistungen gilt dort die Registrierung als PSAN bei der AMF. Die Aufsicht verlangt dokumentierte Sicherheitsmaßnahmen, und ein selbst geschriebener Bericht ohne externe Gegenprüfung wird in einer Prüfung kaum genügen. Ich sage das ungern, weil es teuer ist — aber es ist die Realität.

Wie bereite ich die Audit-Umgebung richtig vor?

Eine strukturierte Umgebung ist die Grundlage jeder erfolgreichen Prüfung, denn ohne Dokumente und reproduzierbare Werkzeuge wiederholen Sie dieselben Fehler immer wieder. Ordnung ist hier kein Selbstzweck, sondern Risikomanagement.

Dokumente sammeln

• Whitepaper und technische Spezifikation
• Architekturdiagramme der Verträge und ihrer Abhängigkeiten
• Bekannte Annahmen und bewusste Einschränkungen
• Frühere Auditberichte, falls vorhanden
• Liste aller externen Abhängigkeiten inklusive Versionsnummern

Werkzeuge einrichten

Installieren Sie die gängigen Analysewerkzeuge und halten Sie deren Versionen fest. Ein Audit, das Sie nicht reproduzieren können, ist kein Audit.

1. Slither für statische Analyse von Solidity
2. Mythril für symbolische Ausführung
3. Foundry oder Hardhat als Testumgebung
4. Echidna für Fuzzing-Tests
5. Remix IDE für schnelle manuelle Prüfungen

Legen Sie zusätzlich eine Checkliste mit den häufigsten Schwachstellen an. Diese Liste begleitet Sie durch die gesamte Analyse und verhindert, dass Sie einen Bereich schlicht vergessen.

Wie führe ich die statische Codeanalyse durch?

Die statische Analyse ist der erste technische Schritt und deckt viele offensichtliche Fehler auf, bevor überhaupt eine Transaktion ausgeführt wird. Sie ersetzt das manuelle Lesen nicht, aber sie spart Ihnen Stunden.

Automatisierte Analyse mit Slither

Führen Sie die Analyse über Ihr Vertragsverzeichnis aus und lesen Sie die Ausgabe vollständig, nicht nur die kritischen Meldungen. Slither erkennt unter anderem Reentrancy-Risiken, ungeprüfte externe Aufrufe, Integer-Überläufe und Fehler in der Zugriffskontrolle.

Manuelle Codeprüfung

Lesen Sie den Code Zeile für Zeile und stellen Sie sich dabei immer dieselben Fragen. Diese Wiederholung wirkt monoton, ist aber der einzige Weg, Muster wirklich zu erkennen.

• Sind alle Funktionen mit den richtigen Zugriffsmodifikatoren versehen?
• Werden externe Aufrufe erst nach dem State-Update ausgeführt?
• Sind alle Rückgabewerte externer Aufrufe geprüft?
• Sind Schleifenlängen nach oben begrenzt?
• Ist jede Annahme über den Aufrufer explizit dokumentiert?

Welche Schwachstellen sollte ich systematisch prüfen?

Diese Liste ist das Herzstück Ihres Selbst-Audits, denn die überwiegende Mehrheit realer Exploits fällt in wenige bekannte Kategorien. Prüfen Sie sie in fester Reihenfolge, damit Sie nichts überspringen.

Reentrancy-Angriffe

Prüfen Sie, ob Funktionen dem Checks-Effects-Interactions-Muster folgen. Nutzen Sie den ReentrancyGuard aus OpenZeppelin, wenn die Logik es erlaubt. Ich habe diese Reihenfolge in eigenen Projekten oft genug falsch herum gesehen, um sie immer zuerst zu prüfen.

Integer-Überläufe und Unterläufe

Verwenden Sie Solidity ab Version 0.8 oder SafeMath und prüfen Sie alle arithmetischen Operationen mit Grenzwerten. Rechnen Sie mit Null, mit dem Maximalwert und mit Werten knapp darunter.

Zugriffskontrolle

Stellen Sie sicher, dass sensible Funktionen nur von autorisierten Adressen aufgerufen werden können, etwa über onlyOwner oder rollenbasierte Modifikatoren. Eine einzige vergessene Einschränkung kann den gesamten Vertrag entwerten.

Front-Running und MEV

Analysieren Sie, ob Transaktionen durch Front-Running manipulierbar sind. In Frankreich ist dieses Thema besonders relevant für DeFi-Projekte, die im Blickfeld der AMF stehen, weil Manipulationsmuster dort als Marktintegritätsfrage behandelt werden.

Orakel-Manipulation

Prüfen Sie, ob Preis-Orakel wie Chainlink korrekt eingebunden sind und ob Fallback-Mechanismen existieren. Ein einzelner manipulierbarer Preispunkt reicht aus, um Liquidationslogik auszuhebeln.

Gas-Optimierung und Denial of Service

Achten Sie auf Schleifen mit unbeschränkter Länge und auf Blockgaslimit-Probleme. Eine Funktion, die bei wachsender Teilnehmerzahl unbezahlbar wird, ist ein Sicherheitsproblem, kein Komfortproblem.

Wie teste ich dynamisch und mit Fuzzing?

Nach der statischen Analyse folgt die dynamische Prüfung, denn erst die Ausführung zeigt Zustände, die das Lesen nicht sichtbar macht. Statische Werkzeuge finden Muster, dynamische Tests finden Überraschungen.

Unit-Tests schreiben

Erstellen Sie Tests für jeden kritischen Pfad und decken Sie dabei bewusst unangenehme Fälle ab. Eine Testabdeckung von 100 Prozent ist bei Verträgen mit Kapital kein Luxus, sondern Pflicht.

• Normale Ausführung mit realistischen Werten
• Grenzfälle mit Null und Maximalwerten
• Fehlerfälle mit nicht autorisierten Aufrufen
• Wiederholte Aufrufe und parallele Transaktionen
• Abbruchbedingungen und Rückerstattungen

Fuzzing und Fork-Tests

Fuzzing mit Echidna generiert zufällige Eingaben und deckt unerwartete Zustände auf. Definieren Sie vorher Invarianten, die immer gelten müssen, sonst finden Sie Fehler ohne Kriterium. Fork-Tests mit Foundry prüfen Ihren Vertrag gegen den tatsächlichen Mainnet-Zustand und simulieren reale Bedingungen.

Warum gehört Wirtschaftlichkeit zur Sicherheit?

Sicherheit ist nicht nur Code, sondern auch Ökonomie, weil ein technisch korrekter Vertrag durch falsche Anreize trotzdem ausgebeutet werden kann. Diese Perspektive fehlt in vielen Checklisten vollständig.

Angriffsszenarien durchdenken

Überlegen Sie, wie ein Angreifer mit begrenztem Budget Ihren Vertrag ausnutzen könnte, und dokumentieren Sie jeden Angriffsvektor. Rechnen Sie die Kosten des Angriffs gegen den möglichen Gewinn — das ist fundamentale Analyse, keine Paranoia.

Anreizstrukturen prüfen

• Sind Belohnungen korrekt und fair verteilt?
• Gibt es Anreize für bösartiges Verhalten?
• Sind Liquidationsmechanismen nachvollziehbar und fair?
• Kann eine einzelne Adresse das System dominieren?

Regulatorische Anforderungen in Frankreich

Wenn Ihr Projekt in Frankreich tätig ist, prüfen Sie die Anforderungen der AMF und der ACPR für Finanzverträge. Dokumentieren Sie Ihre Sicherheitsmaßnahmen so, dass sie einer Prüfung standhalten — nicht erst, wenn die Aufsicht fragt.

Beispiel aus der Praxis

Ich habe ein kleines DeFi-Projekt begleitet, das mit rund 900 Nutzern und etwa 2,4 Millionen Euro TVL gestartet ist. Der Gründer wollte kein externes Audit bezahlen und bat mich um eine zweite Meinung. Wir haben zwei Wochen lang ein Selbst-Audit durchgeführt, Slither und Echidna laufen lassen und die Liquidationslogik manuell nachgerechnet.

Gefunden haben wir keinen kritischen Bug, aber eine Orakel-Abfrage ohne Stale-Price-Prüfung. Das ist kein Exploit, sondern ein Randfall: Bei einem Ausfall des Datenfeeds hätte der Vertrag mit einem veralteten Preis liquidiert. Die Korrektur dauerte 40 Minuten, das anschließende externe Audit kostete 11.000 Euro und fand nichts Neues. Die Lehre: Das Selbst-Audit hat das externe Audit günstiger und schneller gemacht, aber nicht ersetzt.

Wie erstelle ich den Auditbericht und plane die Behebung?

Ein Audit ohne Bericht ist wertlos, weil niemand später nachvollziehen kann, was geprüft wurde und warum eine Entscheidung getroffen wurde. Schreiben Sie den Bericht so, dass ein Fremder ihn ohne Ihre Hilfe versteht.

Struktur des Berichts

• Zusammenfassung mit Umfang und Ausschlüssen
• Methodik und verwendete Werkzeugversionen
• Gefundene Schwachstellen nach Schweregrad sortiert
• Empfehlungen mit konkretem Codebezug
• Anhang mit Codeausschnitten und Testprotokollen

Behebung priorisieren

Beheben Sie zuerst kritische und hohe Schwachstellen, und setzen Sie für mittlere und niedrige Funde feste Fristen. Ohne Frist verrotten diese Punkte im Backlog, das sehe ich in fast jedem Projekt.

Re-Audit nach Korrekturen

Nach jeder Korrektur führen Sie eine erneute Prüfung durch, mindestens der geänderten Bereiche. Jede Änderung kann neue Lücken öffnen, auch wenn sie harmlos aussieht.

Welche Fehler sollte ich vermeiden?

Die häufigsten Fehler beim Selbst-Audit sind nicht technischer Natur, sondern organisatorisch, und sie kosten mehr Zeit als jede einzelne Schwachstelle. Wer sie kennt, spart Wochen.

• Zu früh aufhören: Ein einzelner Durchlauf reicht nie aus.
• Automatisierte Werkzeuge überschätzen: Slither und Mythril ersetzen kein manuelles Lesen.
• Testabdeckung vernachlässigen: Randfälle sind der eigentliche Angriffsvektor.
• Externe Abhängigkeiten ignorieren: OpenZeppelin-Versionen und Orakel-Anbieter regelmäßig prüfen.
• Kein Re-Audit nach Updates: Jede Änderung kann neue Lücken öffnen.
• Regulatorische Anforderungen vergessen: In Frankreich sind PSAN- und MiCA-Vorgaben relevant.
• Keine Dokumentation: Ohne Bericht fehlt jede Nachvollziehbarkeit.

Meine klare Empfehlung: Behandeln Sie das Selbst-Audit als Vorbereitung, nicht als Endprodukt. Für Verträge ohne echtes Kapitalrisiko genügt es oft. Sobald fremdes Geld im Spiel ist, brauchen Sie eine unabhängige Prüfung — nicht weil Ihr Code schlecht ist, sondern weil niemand seine eigenen Fehler zuverlässig sieht.

Häufige Fragen zum Selbst-Audit von Smart Contracts

Wie lange dauert ein Selbst-Audit?

Je nach Komplexität zwischen einigen Tagen und mehreren Wochen. Ein einfacher ERC-20-Vertrag ist in 2 bis 3 Tagen prüfbar, komplexe DeFi-Protokolle benötigen mehrere Wochen. Planen Sie zusätzlich Zeit für die Behebung ein.

Welche Werkzeuge sind für Anfänger am besten geeignet?

Beginnen Sie mit Remix IDE und Slither, beide sind kostenlos und gut dokumentiert. Für Fortgeschrittene empfehlen sich Foundry und Echidna. Wichtig ist weniger die Werkzeugwahl als die konsequente Wiederholung.

Kann ich ein externes Audit komplett ersetzen?

Nein, ein Selbst-Audit ist eine wertvolle Vorbereitung, ersetzt aber nicht die unabhängige Prüfung durch spezialisierte Firmen. Bei Verträgen mit echtem Kapitalrisiko bleibt das externe Audit unverzichtbar.

Was kostet ein professionelles Audit in Frankreich?

Die Preise liegen üblicherweise zwischen 5.000 und 50.000 Euro, abhängig von Umfang und Komplexität. Spezialisierte französische Anbieter finden Sie über die AMF-Liste zugelassener Dienstleister.

Muss ich meinen Auditbericht veröffentlichen?

Für regulierte Projekte in Frankreich ist Transparenz empfehlenswert, und viele Projekte veröffentlichen ihren Bericht, um Vertrauen aufzubauen. Eine Pflicht zur Veröffentlichung besteht nicht in jedem Fall, die Aufsicht verlangt aber Nachvollziehbarkeit.

Wie oft sollte ich ein Audit durchführen?

Vor jedem Major-Release, nach jeder wesentlichen Codeänderung und mindestens einmal jährlich als Routineprüfung. Ein Audit ist ein Prozess, kein einmaliges Ereignis.

Ein gründliches Selbst-Audit hilft, die inhärenten Risiken von Smart Contracts zu identifizieren und zu mindern, bevor sie zu kostspieligen Problemen führen.

Durch die eigenständige Überprüfung des Codes können viele gängige DeFi-Sicherheitsrisiken frühzeitig erkannt und behoben werden, was die Gesamtstabilität des Protokolls erhöht.