Smart Contract Pre-Audit Checklist: 30 Questions

Wavect is not presenting this list as an independent audit. It is a pre-audit hardening review for EVM contracts. A checklist can expose missing evidence and common risks, but it cannot prove that a contract is secure, economically sound, correctly integrated, or safe on every chain and deployment.

Scope the review to the exact source, compiler, settings, dependencies, generated bytecode, proxy pattern, chain, addresses, roles, assets, integrations, deployment scripts, and operating procedures that will be assessed. Use current Solidity documentation, known compiler bugs, a threat model, and a broader verification standard. The official Solidity security considerations, known-bugs list, OWASP Smart Contract Security Verification Standard, and EEA's current EthTrust Security Levels specification listing are useful inputs.

How should the checklist be used?

Answer each question with a code reference, test, tool result, deployment artifact, operating control, or an explicit risk acceptance. A pass means the agreed evidence supports the scoped requirement, not that the whole category is safe. A material failure should be fixed, removed from scope, or accepted by an authorized owner with consequence, compensating controls, and follow-up recorded.

Static analysis, fuzzing, invariants, formal methods, fork tests, and manual review find different classes of problems. No fixed seed count or zero-warning rule works for every codebase. Define the properties and coverage that matter, triage false positives, retain tool versions and configurations, and explain residual uncertainty to the independent reviewer.

Category 1: specification and toolchain (questions 1 to 5)

1. Is the intended behavior specified? Identify assets, actors, privileges, trust assumptions, state transitions, invariants, failure modes, and forbidden outcomes.
2. Is the build reproducible? Pin the released compiler, EVM target, optimizer and IR settings, dependencies, generators, and build commands; compare deployed bytecode and metadata.
3. Were compiler risks checked? Review the selected compiler against the current machine-readable known-bugs list and upgrade guidance.
4. Are automated findings resolved? Run appropriate compiler checks, linters, and analyzers; triage every material result and document justified suppressions.
5. Do tests target properties? Combine examples, boundaries, negative cases, fuzzing, invariants, integration, and differential or formal checks where their value justifies the effort.

Category 2: privileges and lifecycle (questions 6 to 10)

6. Is every privileged action mapped? Record who can pause, upgrade, mint, burn, seize, configure, withdraw, rescue, or change dependencies.
7. Does control match the risk? Evaluate key custody, quorum, signer independence, timelocks, emergency authority, liveness, recovery, and operational burden instead of banning one account type categorically.
8. Are grants, transfers, revocations, and renunciations safe? Test intended and mistaken transitions, pending states, lost signers, and the final-admin path.
9. Are initialization and deployment protected? Prevent unauthorized initialization, front-running, wrong parameters, address mistakes, and unverified implementation or proxy state.
10. Are emergency controls bounded? Define triggers, authority, impact, communications, evidence, unpause or recovery, and what happens if the control itself fails.

Category 3: assets, arithmetic, and economics (questions 11 to 15)

11. Are numeric domains explicit? Check units, precision, rounding direction, bounds, casts, signed values, and justified unchecked blocks.
12. Are token assumptions verified? Treat decimals, return values, callbacks, transfer fees, rebasing, pauses, blocklists, and nonstandard behavior as integration-specific.
13. Are value-conservation properties tested? Define how deposits, withdrawals, fees, rewards, debt, collateral, and dust reconcile across every state transition.
14. Are oracle and market assumptions bounded? Test freshness, manipulation cost, decimal conversion, sequencer or market outage, fallback, and liquidation behavior.
15. Was adversarial economic behavior modeled? Examine ordering, MEV, flash liquidity, griefing, governance capture, incentive loops, and profitable states that pure code checks can miss.

Category 4: external calls and composability (questions 16 to 20)

16. Can any external interaction re-enter? Analyze same-function, cross-function, cross-contract, read-only, hook, token, and callback paths rather than relying on one guard mechanically.
17. Are effects and rollback semantics correct? Use checks-effects-interactions or another justified design, and test partial failure and nested-call behavior.
18. Is return data interpreted by the actual interface? Handle success, revert, empty data, malformed data, and nonstandard tokens according to the required contract, not a universal length rule.
19. Can a dependency block progress? Test unavailable, reverting, gas-consuming, malicious, paused, or upgraded external contracts and define isolation or recovery.
20. Are approvals and signatures safe? Review allowance races, nonce and replay domains, deadlines, chain and contract binding, signature malleability, and smart-account validation.

"A pre-audit checklist is useful when every answer points to evidence and residual risk. A row of green boxes is not a security proof."

Category 5: upgrades and storage (questions 21 to 25)

21. Is the upgrade model explicit? Record proxy type, implementation discovery, upgrade authority, delay, rollback assumptions, initialization, and compatibility boundary.
22. Is storage compatibility validated? Diff layouts with tools that understand the chosen pattern, inheritance, packing, and namespaced storage; do not assume one fixed gap size fits every contract.
23. Are implementation contracts protected? For applicable proxy patterns, lock implementation initialization and validate all parent initializers and reinitializers. Follow the current OpenZeppelin upgrade guidance when using that stack.
24. Is authorization correct for the pattern? Test who can select and execute an upgrade, through which proxy or governance path, including cancellation and compromised-authority scenarios.
25. Was the real migration rehearsed? Populate representative state, upgrade through the production path, verify invariants and integrations, test failure and recovery, and retain artifacts.

Category 6: availability, deployment, and operations (questions 26 to 30)

26. Can user-controlled growth exceed execution limits? Bound or paginate loops and batches, and test realistic worst cases against the target chain's current rules.
27. Can gas or revert behavior cause denial of service? Analyze push payments, callbacks, external calls, refunds, batch atomicity, and griefing without relying on an arbitrary percentage of block gas.
28. Is deployment deterministic and verified? Check parameters, salts, libraries, owners, roles, implementations, source verification, chain IDs, funding, and handover.
29. Are monitoring and response ready? Define events, invariant or balance monitors, alerts, owners, key compromise response, pause criteria, communications, and evidence retention.
30. Are launch and exit risks controlled? Set value and rate limits, staged rollout, dependency and chain contingencies, user recovery, upgrade or immutability implications, and decommissioning.

Why not send unfinished code directly to an auditor?

Independent review time is usually more valuable when requirements, build artifacts, tests, known tool findings, privileges, and deployment plans are coherent. That does not justify universal auditor day rates, a promised finding reduction, or a guaranteed cheaper or faster launch. Audit scope, complexity, team, retesting, report policy, and scheduling differ.

Ask prospective reviewers what must be frozen, which artifacts they need, how changes and retests are handled, what chains and integrations are covered, and how findings are classified. Compare the same scope in writing. A pre-audit review can reduce avoidable churn, but the external reviewer must remain free to challenge its assumptions.

Who owns sign-off?

Assign an accountable technical owner for every question and an authorized business or governance owner for accepted material risk. Include commit and bytecode references, test and tool evidence, deployment configuration, unresolved assumptions, and a change log in the handoff. The independent reviewer decides how much reliance to place on that material.

After the review, code and operational changes can invalidate evidence. Define which changes require re-analysis or re-audit, and make deployment conditional on the current approved artifact rather than a stale checklist.