Do You Need a Smart Contract Audit Before Launch?

The question is never yes or no

Every founder asks it the same way — "do we need an audit?" — as if the answer were a coin flip. It isn't. Whether you need one, and how deep it should go, comes down to four measurable factors: how much money the contract can touch, whether it can be upgraded after deployment, who holds the keys that can move funds or change rules, and how much real-world exposure the code has already survived. Get honest about those four and the decision makes itself.

I've seen teams spend $40k auditing a static NFT mint contract that held a 0.5 ETH mint price and no admin functions — money that would have been better spent on a security-focused code review of their off-chain relayer instead. I've also seen teams skip an audit on a yield vault that hit $6M TVL in nine days, because "the code was basically a Yearn fork." Both decisions were wrong for the same reason: nobody ran the numbers before deciding.

A four-factor framework

1. Total value at risk, not total value locked today

TVL at launch is the wrong number. What matters is the TVL you're underwriting for the contract's expected lifetime, including the spike after a marketing push, a listing, or an airdrop announcement. A lending pool that opens with $50k but is designed to scale to $10M within a quarter needs to be audited against the $10M scenario, not the $50k one. Auditors price and scope against worst-case exposure, and so should you.

Rule of thumb I use with clients: if peak expected TVL exceeds roughly 50x your total audit budget, skipping the audit is a bet you're financially exposed on both sides of. A $15k audit protecting a contract capped at $200k is a reasonable insurance premium. The same $15k audit protecting a contract that could hold $8M is not insurance, it's a lottery ticket.

2. Upgradeability changes what "done" means

A non-upgradeable contract only needs to be right once. A proxy-based contract — UUPS, Transparent Proxy, Diamond — needs to be right every time someone calls the upgrade function, forever. That's a fundamentally different risk surface, and it's the single most common thing teams underestimate.

// This single function is the entire trust model of an upgradeable protocol.
// If the timelock is 0, or _authorizeUpgrade has no access control,
// TVL is only as safe as whoever holds this key right now.
function _authorizeUpgrade(address newImplementation)
    internal
    override
    onlyOwner
{}

If your contracts are upgradeable, an audit isn't a one-time gate before launch — it's a recurring line item every time the implementation changes. Budget for that up front, or design for immutability instead and accept the tradeoff of never being able to patch a bug post-launch. Either choice is defensible. Pretending upgradeability has no ongoing cost isn't.

3. Admin keys are the audit scope people forget

Most founders think of an audit as "check the math." Auditors spend at least as much time on privilege escalation: who can pause the contract, who can drain the treasury, who can mint unlimited supply, whether that "who" is a multisig with a 48-hour timelock or a single EOA sitting in someone's MetaMask. A contract with a single onlyOwner wallet controlling withdrawals is one phished laptop away from a total loss, regardless of how clean the rest of the logic is.

If your admin structure is a 3-of-5 Gnosis Safe with a timelock, that materially reduces your risk profile and should shrink audit scope and cost accordingly. If it's a single hot wallet, you either need that flagged and fixed before launch, or you need users to know exactly what they're trusting. An audit report that only checks arithmetic and misses the admin key structure isn't a real audit — that's a scoping conversation worth having explicitly before you sign an engagement, something we walk clients through in a strategy consultation before any code review starts.

4. Mainnet history is worth more than testnet coverage

Testnet transactions prove your happy path works. They prove almost nothing about adversarial behavior, because nobody's trying to drain a testnet. A contract that's been live on mainnet for six months with real TVL and no incidents has accumulated something an audit can't fully replicate: exposure to actual MEV bots, actual flash-loan attackers, actual gas-griefing attempts. That's not a reason to skip an audit before the original launch — it's a reason to weight a second audit less heavily than the first one if the logic hasn't materially changed.

New chain, new logic, or first mainnet deployment: full audit, no shortcuts. Same logic redeployed with a config change: a scoped diff review is usually sufficient and considerably cheaper. For a full breakdown of what drives audit pricing across ecosystems, see our guide to smart contract audit costs in 2026.

A worked example: two forks of the same vault

Team A forks a well-audited ERC-4626 vault, changes the fee logic, keeps the same non-upgradeable architecture, and caps deposits at $100k with a hard-coded ceiling. Team B forks the same vault, makes it upgradeable via UUPS, removes the deposit cap, and puts upgrade authority behind a single deployer wallet "temporarily, until governance launches."

Team A can reasonably launch with a focused audit on just the fee-logic diff — a few thousand dollars, a week of turnaround. Team B is running a materially different risk profile: unbounded TVL, an upgrade path that can rewrite any function in the contract, and single-key custody of that upgrade path. That's a full-scope audit, and arguably it shouldn't launch until the deployer key moves to a multisig with a timelock, independent of what the audit finds.

Same starting code. Completely different answer to "do we need an audit," because upgradeability and admin key structure — not the fork itself — determined the risk.

What testing alone never catches

Unit tests verify the code does what you told it to do. Audits look for what happens when someone does something you didn't anticipate — reentrancy through an unexpected callback, integer edge cases at the boundary of your safe-math assumptions, oracle manipulation across a single block, cross-function state assumptions that break under reordering. If you're deploying on TON, the trap categories shift again: bounced messages, gas-accounting across actor boundaries, and jetton wallet logic that doesn't match the jetton and NFT standard's security assumptions. Our breakdown of what TON auditors actually check in FunC and Tact covers those chain-specific failure modes in detail.

None of that shows up in a coverage report. It shows up in an audit, or it shows up in a post-mortem.

If your contract holds meaningful user funds, can be upgraded, or hands privileged control to anything short of a timelocked multisig, get a smart contract audit before mainnet — not after the first big TVL spike makes the decision for you.