Do you need a smart contract audit?

If your contract holds user funds, controls access to funds, or governs protocol parameters that affect funds, you need an audit. That's the short answer. The rest of this post helps you figure out what kind of audit fits your situation and when to get one.

Not sure what a modern audit involves? Read what to expect from a smart contract audit in 2025 for the full breakdown.

Request an audit with Recon if you already know you need one.

The short answer

Any contract that manages value on behalf of others needs independent security review. It's about the asymmetry between audit cost and exploit cost. A typical engagement runs $50K-$200K. A single critical vulnerability regularly drains $1M-$100M+. The math isn't close.

Even contracts that don't hold funds directly can create risk if they govern access control, upgrade paths, or oracle integrations that downstream contracts depend on.

When you definitely need an audit

You should get an audit before deploying to mainnet if any of these apply:

• Your protocol will hold user deposits. Vaults, lending pools, staking contracts, or anything where users send tokens they expect to get back.
• You're handling more than $100K in TVL. The economics of exploitation scale with value locked. Past $100K, you're a viable target.
• Your contracts are upgradeable. Proxy patterns and UUPS introduce storage collision risks and admin key attack surfaces that don't exist in immutable contracts.
• You integrate with external protocols. Composability means your contract inherits the risk profile of every protocol it calls. Oracle dependencies and flash loan surfaces both need review.
• You're launching a token. Token contracts with minting authority, transfer restrictions, or fee mechanisms are high-value targets.

When you might not need one

Not every contract needs a full audit:

• Personal projects and learning exercises. If nobody else's funds are at risk, you don't need external review.
• Testnet-only deployments. Contracts that will never touch mainnet don't carry financial risk.
• Contracts with no fund handling and no access control. A pure view-only data contract or an immutable registry with no admin functions has a smaller attack surface.
• Forks of well-audited code with zero modifications. If you're deploying an exact copy of audited code at the same compiler version, the existing audit applies. The moment you change a line, it doesn't.

The decision checklist

Run through this table. If you answer "yes" to any row, you should get professional security review.

Question	If yes
Does it hold or transfer user funds?	Audit required
Does it have admin or owner roles?	Audit required
Is it upgradeable (proxy, UUPS, beacon)?	Audit required
Does it integrate with external contracts?	Audit required
Does it have token minting or burning?	Audit required
Will it govern more than $100K TVL?	Audit required
Does it use assembly or low-level calls?	Audit required
Is it a fork with modifications?	Audit the diff

Zero "yes" answers and you're probably safe without one. One or more and the question isn't whether to audit, it's what type of audit fits.

What type of audit fits your situation

Different situations call for different approaches:

Situation	Recommended approach
New protocol, pre-mainnet launch	Full audit with invariant testing
Upgrade or migration to existing protocol	Diff audit focused on changed code
Pre-launch with tight timeline	Invariant testing engagement + targeted manual review
Live protocol adding features	Incremental audit of new code + regression fuzzing
Ongoing development with regular deploys	Continuous fuzzing via CI + periodic review

A full smart contract audit isn't always the right starting point. For teams early in development, an invariant testing engagement can surface critical bugs before the code is stable enough for a formal audit.

Common mistakes teams make

Waiting until after launch. Auditing post-deployment means any critical finding requires an emergency migration. Pre-launch fixes are cheap. Post-launch fixes are expensive and risky.

Auditing before code freeze. If you're still changing the code, the audit findings may not apply to the final version. Auditors review a snapshot. Changes after that snapshot are unreviewed.

Choosing the cheapest option. Audit quality varies enormously. A firm that delivers only a PDF report without executable tests is running a 2020 process. Demand invariant test suites as a deliverable.

Not demanding test suites. An audit report becomes stale the moment you push a new commit. An invariant test suite keeps protecting you through every change.

Auditing only once. Every code change, upgrade, or new integration needs review. Continuous fuzzing in CI catches regressions between formal audits.

Related

• Smart contract audit overview — what an audit covers and how it works
• What to expect from a smart contract audit in 2025 — the six phases of a modern engagement
• The true cost of not auditing — real data on prevented losses
• Invariant testing explained — why executable properties beat static reports
• Smart contract audit services — scope and deliverables

Ready to protect your protocol? Request an audit with Recon and we'll scope the right engagement for your situation.