Smart Contract Pre-Audit Checklist for Web3 Teams

An independent audit is most useful when reviewers can spend their time reasoning about the protocol instead of reconstructing its intended behavior. A little preparation improves review quality, shortens feedback loops, and makes findings easier to verify.

1. Define the review scope

List the contracts, libraries, compiler version, dependency versions, and deployment configuration that are in scope. Identify the commit or release tag the reviewers should use. Document trusted roles, upgrade mechanisms, external integrations, and any contracts that are intentionally excluded.

Write down the protocol's critical invariants in plain language. Examples include who may move funds, how liabilities are calculated, whether an operation can be repeated, and what must remain true after an upgrade. This gives reviewers context without prescribing their conclusions.

2. Make the build reproducible

Pin the Solidity compiler and dependency versions. Include a short command sequence that installs dependencies, compiles the contracts, and runs the tests from a clean checkout. Avoid relying on local files, undocumented environment variables, or mutable dependency references.

Record any expected compiler warnings and explain why they are acceptable. Unexpected warnings should be resolved before review rather than buried in build output.

3. Test behavior and invariants

Unit tests should cover normal flows, boundary values, authorization failures, and revert conditions. Add integration tests for important interactions between contracts and external protocols. Where practical, use fuzz tests for arithmetic and state transitions, and invariant tests for properties that must hold across sequences of actions.

Tests are evidence, not proof of security. Keep them deterministic, assert meaningful outcomes, and avoid tests that merely mirror the implementation line by line.

4. Review access and asset flows

For every privileged function, identify its authorized caller and the consequences of misuse. Check initialization and reinitialization behavior, ownership transfers, role administration, pause controls, and upgrade authorization.

Trace assets through deposits, withdrawals, fees, refunds, and emergency paths. Consider rounding, token behavior that differs from the standard assumptions, and what happens when an external call fails. Confirm that accounting uses the actual received amount when transfer fees or rebasing are possible.

5. Run automated analysis and triage results

Static analyzers, compiler checks, and test tooling can quickly reveal suspicious patterns and regressions. Run them on the exact scoped revision, keep the output, and investigate each relevant result. A clean tool report is not a substitute for manual review, and suppressions should include a specific rationale.

6. Prepare deployment and operations details

Document constructor or initializer parameters, expected chain IDs, deployment order, role assignments, and verification steps. Explain how upgrades are proposed and executed, including any timelock or multisig controls. Keep secrets out of source control and provide a plan for monitoring and responding to incidents.

Before handing over

• Share the exact commit and reproducible build instructions.
• Provide architecture notes, invariants, and known limitations.
• Include passing unit, integration, fuzz, and invariant test results where available.
• Identify privileged roles, external dependencies, and asset flows.
• Keep automated scan output and explain intentional suppressions.
• Confirm the review scope and the process for fixing and retesting findings.

Preparation cannot guarantee that a contract is secure. It gives reviewers a clear, testable starting point and helps a team act on findings before deployment.