Smart Contract Audit Prep Checklist: What to Lock Before Day One

hydn sushi banner image

TL;DR: Audits go well when scope is frozen, the commit hash is locked, trust assumptions are written down, code is clean, and you left calendar time for fixes and retest. Most wasted engagement days come from prep failures, not exotic bugs.

If you are about to put real money behind contracts, preparation decides how much signal you get per pound spent. This is the day-0 checklist we wish every team completed before kickoff. It aligns with what serious audit firms ask for: a scope document and a frozen commit (Consensys Diligence).

1. Freeze scope in writing

List every contract, library, and upgrade path that is in scope. Explicitly list what is out of scope. Ambiguity is expensive. “One more vault” on day three invalidates half the mental model auditors built on day one.

Deliverable: a one-pager or README section titled Scope with in/out tables and chain targets.

2. Lock the commit hash

Audits target a specific revision. Tag it. Put the full hash in the engagement letter and the report cover.

Industry prep guides are blunt: freeze development for the audit baseline; if you must change code mid-flight, expect a delta review or a restart (Consensys Diligence, Hacken).

Better to delay the start than to audit a moving target.

3. Document intended behaviour and invariants

Include: system overview in plain English; per-contract responsibilities; invariants; economic assumptions (oracles, fees, liquidation rules); known limitations and accepted risks. NatSpec and architecture diagrams help. A threat model paragraph helps more.

4. Write down trust assumptions and privileged roles

Who can upgrade? Who can pause? Who sets risk parameters? Is the owner an EOA, multisig, or timelock? What happens if a signer is compromised? If “admin is trusted” is your whole model, say so explicitly.

5. Clean the codebase

  • Remove dead code, TODOs that are unfinished features, and commented-out experiments
  • Fix compiler warnings
  • Run the formatter and linter you claim to use
  • Make tests pass on a clean checkout with documented commands

6. Ship a usable test and build story

  • Exact toolchain versions (solc, foundry/hardhat, node)
  • forge test / hardhat test that works from README
  • Mainnet fork notes if relevant
  • Deployment scripts and addresses for deployed dependencies

7. Flag your worries early

You know the scary modules: novel math, custom accounting, cross-chain messaging, upgradeable proxies, oracle adapters. Tell the team on day zero.

8. Plan remediation and retest time

Build launch plans with a buffer after the draft report. Criticals can force design changes, not one-line patches. HYDN’s audit process: smart contract audits.

Day-0 questionnaire (copy/paste)

  1. Repo URL + exact commit hash
  2. In-scope contracts and out-of-scope list
  3. Chains and deployment topology (proxies, factories, modules)
  4. Roles and admin controls (with multisig/timelock details)
  5. External dependencies (oracles, bridges, AMMs, keepers)
  6. Invariants and economic assumptions
  7. Prior audits, known issues, bug bounty history
  8. Preferred severity process and disclosure constraints
  9. Remediation window and target launch date
  10. Contacts for architecture questions (with timezone)

If any line is blank, you are not ready.

What prep does not replace

A clean prep package does not make unsafe design safe. It makes the review efficient. After contracts are sound, test the live stack with penetration testing. Mature orgs add red team / adversarial simulation.

For the service choice itself, read blockchain pen testing vs smart contract audits.

FAQ

Can we keep merging to main during the audit?

Not into the audited revision. Freeze the hash. Schedule a delta review for intentional changes.

How long should documentation be?

Long enough that a senior engineer outside your team can explain trust and value flow in thirty minutes. Quality beats page count.

We already have an older audit. Do we still prep like this?

Yes. Scope the delta, lock the new hash, and call out what changed.

Next step

When the checklist is green, you are ready to book. If you want HYDN to audit from a locked commit with clear scope, get in touch.

share