What vulnerability classes does this cover?

The checklist spans the high-impact Solidity classes: reentrancy, access control, delegatecall and selfdestruct misuse, proxy initialisation, oracle and price manipulation, arithmetic overflow, tx.origin auth, front-running, signature replay, denial of service, randomness misuse, and gas and code-quality items. They map to entries in the SWC Registry.

Why is reentrancy listed first?

Because it is both common and catastrophic. Reentrancy lets an external call re-enter your contract before state is updated, draining funds — the class behind the DAO hack. The fix is the checks-effects-interactions pattern or a nonReentrant guard, so it sits at the top as a critical control.

How is the score calculated?

The tool counts only the controls you mark as applicable, ignoring N/A. The percentage is the number of OK controls divided by the applicable total. Any flagged issues are listed separately and grouped by severity, because a single critical issue matters more than a high overall percentage.

Does a clean checklist mean my contract is safe?

No. A clean self-audit is necessary but not sufficient. Automated tools like Slither, fuzzing with Echidna, and an independent professional audit catch issues a checklist cannot, especially economic and composability bugs that depend on how your contract interacts with others.

What does oracle manipulation mean here?

If your contract reads a price directly from an on-chain pool's spot reserves, an attacker can move that price within a single transaction using a flash loan and exploit your logic. The control asks whether you use a manipulation-resistant source such as a time-weighted average price or a Chainlink feed instead.

Smart Contract Security Audit Checklist

Most smart-contract exploits fall into a small set of well-known vulnerability classes. This checklist lets a developer self-audit a Solidity contract against those classes — reentrancy, access control, oracle manipulation, overflow, front-running, and more — before commissioning a formal audit. Items map to the SWC Registry and common Trail of Bits and ConsenSys Diligence findings.

How it works

Each control is marked OK, Issue, or N/A and carries a severity. The score counts only the applicable controls, and flagged issues are grouped so the most dangerous classes surface first:

applicable = total controls − (controls marked N/A)
score      = OK controls / applicable × 100
issues     → grouped by severity: critical → high → medium → low

A critical issue (reentrancy, broken access control, unprotected selfdestruct, delegatecall, or proxy init) triggers an explicit do-not-deploy warning regardless of the overall percentage.

Notes and example

A lending contract that reads its collateral price from a DEX pool’s spot reserves will pass most controls but flags a high-severity oracle issue, because a flash loan can warp that price within one transaction and trigger bad liquidations. The fix is a time-weighted average or a Chainlink feed. Treat the checklist as the floor: even a fully green run should still go through Slither static analysis, Echidna fuzzing, and an independent professional audit before any mainnet deployment with real value at stake. Everything is computed locally in your browser.