Smart contract audit checklist
Before an audit starts, freeze the code at a commit hash, document what the system is meant to do, write down its invariants, resolve compiler warnings, raise test coverage on every path that moves funds, and list the risks you already worry about. Teams that arrive with these get a faster, cheaper and deeper audit.
Code
- Code frozen at a specific commit hash, shared with the auditors.
- Compiler version pinned, and all compiler and linter warnings resolved.
- Dead code, test helpers and unused contracts removed from the audit scope.
- External dependencies pinned to exact versions, with any modifications to library code called out.
- Contracts in scope listed by path, with anything out of scope stated explicitly.
Documentation
- A plain description of what the protocol does and who uses it.
- An architecture overview showing how the contracts call each other and what external systems they depend on (oracles, DEXs, bridges, tokens).
- The roles in the system, who holds them, and what each can do.
- Invariants: the things that must always be true. Examples are “total shares never exceed total assets in value” or “only the timelock can change fees”.
- Known issues and accepted risks, so auditors do not report them back to you.
Tests
- A test suite that runs from a clean checkout with one command.
- Coverage on every path that moves funds, mints, burns or changes permissions.
- Fuzz or invariant tests for the maths, if you have them.
- Fork tests against real deployments for any integration with external protocols.
Deployment
- Target chains listed. Behaviour differs between chains, especially on L2s.
- Deployment and initialisation scripts included, since a contract left uninitialised is a common way in.
- Upgrade process described: who can upgrade, through which timelock or multisig, and with what delay.
- Admin keys and multisig thresholds documented.
Logistics
- A named technical contact who can answer questions quickly during the audit.
- A realistic launch date that leaves time for fixes and a remediation review.
- Agreement on whether the final report will be published.
What HYDN will ask you
At the kick-off we usually want to know what you are most worried about, which parts of the code are newest, which were copied or forked from other protocols, and what would hurt most if it went wrong. The answers shape where we spend the time.
Frequently asked questions
Do we need full documentation before an audit?
You need enough for an auditor to know what correct behaviour looks like. A short specification, an architecture diagram and a list of invariants are usually enough. Without them, auditors spend the first days reverse engineering your intent.
Should we fix known issues before the audit?
Yes. Paying an auditor to report problems you already know about is wasted time. Fix them, or list them as known issues so the auditors can look past them.
Can we keep developing during the audit?
You can, on a separate branch. The audit covers the frozen commit only, and changes made after it are outside the agreed scope.
Published Updated