Smart-Contract-Security-Checkliste: 30 Punkte, die wir vor dem externen Audit verifizieren

Wir auditieren nicht. Wir liefern und härten Smart-Contract-Code aus, dann auditieren externe Firmen ihn. Bevor das Audit-Fenster öffnet, fahren wir diese 30-Punkte-Pre-Audit-Checkliste über 6 Kategorien: Compiler und Toolchain, Access Control und Rollen, Arithmetik und Overflow, External Calls und Reentrancy, Upgradability und Storage, Gas und DoS-Flächen. Jeder Punkt unten hat uns oder einen Peer in einem echten Engagement gebrannt. Alle 30 abzuhaken hat die Auditor-Findings-Zahl auf unseren Übergaben um grob 60 bis 80 Prozent in unserer Engagement-Historie gesenkt, was günstigere Audits und schnelleres Mainnet heißt.

Das ist die Liste, die wir uns an Tag eins von Scramble Pay, Quivr, Lightbridge und unserer Account-Abstraction-Arbeit gewünscht hätten. Wir nennen es kein Audit. Es ist ein Hardening-Review, designed, um das Audit langweilig zu machen.

Was prüft ein Smart-Contract-Pre-Audit-Hardening-Review tatsächlich?

Sechs Kategorien, fünf Punkte pro Kategorie, dreißig Punkte gesamt. Wir behandeln die Checkliste als Gate. Wenn ein Punkt fehlschlägt, verlässt der Contract unser Repo nicht, bis er gefixt oder explizit schriftlich vom Kunden mit Begründung gewaivt ist. Wir paaren das mit unserem TDD-Workflow und QA-Service, sodass jeder Fix mit einem Regressionstest landet.

Kategorie 1: Compiler und Toolchain (Punkte 1 bis 5)

1. Gepinnte Solidity-Version. Lock einer einzelnen Compiler-Version in foundry.toml oder hardhat.config. Floating Pragmas wie ^0.8.20 heißen, dass zwei Entwickler zwei verschiedene Bytecodes aus derselben Quelle compilieren können.
2. Optimizer-Settings deklariert und reproduzierbar. Dokumentiere den Optimizer-Runs-Wert. Etherscan-Verifikation scheitert bei Mismatch, und ein Auditor verbrennt eine Stunde, bevor er es markiert.
3. SMTChecker und Slither bestehen mit null unsuppressed Findings. Jede Suppression hat einen Inline-Kommentar mit Auditor- oder Engineer-Namen, der gewaivt hat. Keine stillen Suppressions.
4. Foundry-Fuzz- und Invariant-Tests laufen in CI mit hoher Seed-Anzahl. Wir fordern mindestens 10.000 Fuzz-Runs und 256 Invariant-Runs pro kritische Funktion vor Audit-Übergabe.
5. Dependency-Lockfile committed und auditiert. OpenZeppelin- und Solady-Versionen gepinnt. Keine git-Dependencies, die auf main zeigen. Wir diffen jedes Dependency-Upgrade.

Kategorie 2: Access Control und Rollen (Punkte 6 bis 10)

6. Jede privilegierte Funktion hat einen expliziten Rollen-Check. Nicht onlyOwner by Default. Wir mappen jede Funktion auf eine Rolle und dokumentieren, wer sie bei Deployment hält.
7. Kein EOA hält Admin-Keys bei Mainnet-Launch. Multisig oder Timelock. Punkt. Wir haben Single-Key-Admin-Kompromittierung bei Peer-Projekten gesehen, und es beendet das Projekt.
8. Zwei-Stufen-Ownership-Transfer. Ownable2Step oder Äquivalent. Ein Tippfehler bei einem Ein-Stufen-Transfer ist nicht wiederherstellbar.
9. Role-Renounce- und -Revoke-Pfade getestet. Kann die DEFAULT_ADMIN_ROLE wirklich gerenounct werden, ohne das Protokoll zu bricken? Test es.
10. Initializer-Schutz auf upgradeable Contracts. _disableInitializers() im Constructor jedes Implementation-Contracts, keine Ausnahmen.

Kategorie 3: Arithmetik und Overflow (Punkte 11 bis 15)

11. Solidity 0.8+ genutzt und unchecked Blöcke inline begründet. Jeder unchecked-Block hat einen Kommentar, der erklärt, warum Overflow an der Aufrufstelle unmöglich ist.
12. Division-Reihenfolge verifiziert. Multipliziere vor Dividieren, wo Präzision zählt. Wir greppen / in Finanz-Pfaden und reviewen jeden einzelnen.
13. Fee- und Prozent-Mathematik nutzt Basispunkte oder eine definierte Präzisions-Konstante. Keine rohen Dezimalstellen. Dokumentiere die Konstante und nutze sie überall.
14. Token-Decimal-Mismatches gehandhabt. USDC hat 6 Dezimalstellen, WETH hat 18. Wir testen jedes Paar mit einem Fork-Test gegen Mainnet-Token-Adressen.
15. Casting-Checks. Jedes uint256 zu uint128 oder kleiner hat einen expliziten Bound-Check oder SafeCast.

Kategorie 4: External Calls und Reentrancy (Punkte 16 bis 20)

16. Checks-Effects-Interactions durchgesetzt. State-Updates passieren vor jedem External Call. Wir reviewen jeden External Call von Hand.
17. ReentrancyGuard auf jeder Funktion, die einen External Call macht und State modifiziert. Default an, Opt-out nur mit Begründung.
18. Cross-Function-Reentrancy getestet. Ein reentrant Call in eine Schwester-Funktion mit geteiltem State ist der klassisch übersehene Vektor. Wir fuzzen es.
19. Untrusted Token-Callbacks gehandhabt. ERC777, ERC1155 onERC1155Received, ERC721 onERC721Received. Nimm an, jeder externe Token ist feindlich.
20. Return-Data-Länge bei Low-Level-Calls geprüft. (bool ok, ) = target.call(...) ohne Return-Data-Check ist ein stiller Failure, der nur wartet.

"Hardening ist, was das Audit langweilig macht. Langweilige Audits liefern aus."

Kategorie 5: Upgradability und Storage (Punkte 21 bis 25)

21. Storage-Layout dokumentiert und bei jedem Upgrade gediffed. Wir fahren forge inspect-Storage-Layout vor und nach und lehnen jeden umgeordneten Slot ab.
22. Storage-Gaps auf jedem upgradeable Parent reserviert. uint256[50] private __gap; pro OpenZeppelin-Konvention.
23. Constructor-Logik für Proxies in Initializer verschoben. Alles in einem Constructor auf einem upgradeable Contract ist ein Bug.
24. UUPS-authorizeUpgrade hat einen Rollen-Check. Default-OpenZeppelin-Scaffolding lässt es abstrakt. Stell sicher, dass es implementiert und geschützt ist.
25. Upgrade-Pfad End-to-End auf einem Fork getestet. Deploye V1, befülle State, upgrade auf V2, verifiziere State intakt. Pflicht.

Kategorie 6: Gas- und DoS-Flächen (Punkte 26 bis 30)

26. Unbegrenzte Loops entfernt oder paginiert. Jeder Loop über ein Array, das Nutzer wachsen lassen können, ist ein DoS-Vektor. Wir refaktorieren zu Pull-basierten Mustern.
27. Block-Gas-Limit-Headroom verifiziert. Keine einzelne Funktion sollte grob 30 Prozent des Block-Gas-Limits unter realistischer Statusgröße überschreiten.
28. External-Call-Gas-Stipends gehandhabt. Alles Gas an untrusted Contracts weiterzuleiten kann Griefing ermöglichen. Wir capen oder nutzen try/catch.
29. Storage-Writes in Hot-Paths minimiert. Heiße Storage-Slots werden gepackt. Wir messen mit forge snapshot und lehnen Regressionen über 5 Prozent ab.
30. Front-Running- und MEV-Fläche dokumentiert. Commit-Reveal, Slippage-Params oder Deadline-Params, wo relevant. Wenn das Protokoll Sandwich-Angriffen ausgesetzt ist, weiß der Nutzer es vor Mainnet.

Warum existiert diese Checkliste, statt einfach einen Auditor einzustellen?

Auditoren rechnen pro Codezeile und pro Tag ab. Ungeharden Code in ein Audit zu schicken, heißt, Senior-Engineers €2.000 bis €4.000 pro Tag zu zahlen, um Bugs zu finden, die dein eigenes Team mit Slither und einem Fuzz-Harness hätte fangen können. In unserer Engagement-Historie kamen Projekte, die alle 30 Punkte vor Audit-Übergabe abschlossen, mit Auditor-Findings im einstelligen Bereich zurück, die meisten informational. Projekte, die die Checkliste übersprangen, kamen routinemäßig mit 30+ Findings inklusive Criticals zurück, was dann ein Re-Audit zu vollen Kosten erforderte.

Das ist der Unterschied zwischen Wavect und einem Generalisten-Shop. Siehe Wavect vs eine klassische Dev-Agentur für den vollen Kontext. Wir bauen Web3-Systeme mit einem Security-First-Rhythmus, der in unseren Blockchain-Service eingebacken ist, sodass das Audit zur Abnahme statt zur Rettung wird.

Wer ownt die Checkliste auf einem Projekt?

Der Wavect-Tech-Lead auf dem Engagement. Er zeichnet jeden Punkt mit Commit-Referenz und Test-Referenz ab. Der Kunde erhält die unterzeichnete Checkliste als Teil des Audit-Übergabe-Pakets, das der externe Auditor zusammen mit dem Code erhält. Auditoren lieben das, weil es ihnen sagt, wo sie ihre Aufmerksamkeit fokussieren sollen.