Smart Contract Audits: What Founders Must Demand Before Launch

A founder's checklist for smart-contract audits — selecting auditors, scoping the engagement, reading the report, and the post-audit discipline that actually matters.

An audit is not insurance. It is a snapshot.

A clean audit report does not mean the contract is safe. It means a specific firm reviewed a specific commit hash on a specific date. Every change after that date is unaudited. Founders who treat audits as insurance, rather than as one input into a security posture, lose user funds.

Selecting auditors

Tier-one firms: OpenZeppelin, Trail of Bits, Spearbit, Cantina, Sigma Prime, Quantstamp. For higher-stakes deployments, run two independent audits in parallel — different firms catch different classes of bug. Never accept a 'cheap' audit from a firm with no public report history.

Scoping the engagement

Commit hash frozen for the duration. Auditors get full documentation, test suite, and architecture diagrams up front. Scope is the contract code AND the surrounding deployment scripts, upgrade mechanisms, and admin functions — most exploits in 2023–2025 came from the surroundings, not the core logic.

Reading the report like a founder

Every Critical and High finding must be remediated and re-reviewed. Mediums must be addressed or explicitly accepted with reasoning published. Lows can be triaged. Informational findings should still be reviewed — they often hint at design weaknesses worth fixing.

Post-audit discipline

Monitoring (Forta, OpenZeppelin Defender, custom). Bug-bounty programme (Immunefi or equivalent), funded at a level that actually attracts senior researchers. Incident-response runbook written before launch, not after the exploit. Multisig with real signer hygiene, not a 2-of-3 with all keys on the founder's laptop.