Can I launch a token without an audit?

Technically yes · nothing stops an unaudited deployment. Practically, you're stacking three risks: a bug that drains funds and cannot be patched after deployment, launchpads and exchanges that increasingly require an audit report to list you, and buyers who now check for audits before they ape in. An unaudited launch saves a line item and spends your credibility.

Is an audit needed for a standard ERC-20 token with no custom logic?

A plain OpenZeppelin-based ERC-20 with no tax, reflection, or custom mint logic is the lowest-risk case, and a focused review rather than a multi-week audit is usually proportionate. But the review is still worth doing: most 'standard' tokens turn out to have small modifications, and it's exactly those edits that introduce bugs. The moment there's vesting, taxes, or upgradeability, treat it as custom code.

What happens if I skip the audit and there's a bug?

Smart contracts are immutable by default · a bug found after deployment usually can't be patched, only mitigated or migrated, and any funds already lost are gone. On top of the direct loss, an exploit publicly kills trust in the token and the team. This asymmetry · a bounded audit cost versus an unbounded failure cost · is the whole argument for auditing before mainnet.

Are automated scanners enough instead of an audit?

No. Tools like Slither and Echidna are essential hygiene and catch a real class of bugs cheaply, but they don't understand your business logic · they can't tell that your vesting math unlocks a year early or your fee split lets an admin drain the pool. Automated tooling is the floor, human review is the audit.

Do I Need a Smart Contract Audit Before Launching?

Q: Do I need a smart contract audit before launching?

If your contract will hold, move, or control real value on mainnet · yes, some level of independent review before launch. The tier of review should match the value at risk: a focused review for a simple standards-based token, a full external audit for anything with custom logic, and a top-tier engagement for DeFi protocols, bridges, or anything custodying serious funds. The only honest exceptions are testnet experiments and contracts that never touch value.

Short answer: if your contract will hold, move, or control real value on mainnet · yes, you need independent review before launch. The real question isn't whether, it's how much: a focused review is proportionate for a plain standards-based token, a full external audit for anything with custom logic, and a top-tier engagement for protocols custodying serious funds. The only honest "no" cases are testnet experiments and contracts that never touch value. Below is the framework we use to place projects on that spectrum · then send us your scope and we'll tell you straight which tier you actually need, including when you don't need the expensive option.

Why this question is different in Web3

In normal software, you ship a bug, you patch it Tuesday. Smart contracts invert that: deployed code is immutable by default, holds money directly, and is attacked by anonymous adversaries the moment it's live. A bug isn't a bad review on the App Store · it's an open vault door. That's why the audit question can't be answered with the intuitions you'd use for a web app. The cost of review is bounded and known; the cost of a missed bug is unbounded and unrecoverable. Any framework that ignores that asymmetry is just cost rationalization.

The decision framework · value at risk × custom logic

Two questions place almost every project correctly. One: how much value will this code hold or control at peak? Two: how far does the code deviate from battle-tested standards?

Your situation	Proportionate review
Testnet experiment, no real value ever	None required. Run Slither for hygiene and move on.
Plain ERC-20 / SPL, no custom logic, modest raise	Focused independent review + automated tooling. Cheap, fast, worth it.
Token with tax, vesting, airdrop, or custom mint logic	Full external audit. Custom logic is where token bugs live.
DeFi protocol · DEX, lending, staking, perps	Full audit from a strong firm, invariant testing, possibly a contest on top.
Bridge, RWA, or anything custodying large value	Top-tier firm engagement + ongoing review. This is not the place to economize.

Note what's not in the table: your launch deadline and your budget mood. Those are real constraints, but they change when you launch, not whether the code needs review. (For what each tier costs and why, see the smart contract audit cost breakdown.)

What skipping it actually costs

The exploit itself. A missed bug in immutable code can't be patched · funds lost are simply lost, and history is full of projects that died in a single transaction.
The listing wall. Serious launchpads, CEXes, and even DEX aggregators increasingly ask for an audit report before listing or featuring you. No report, shorter runway.
The buyer check. Retail and funds alike now look for an audit badge before entering. "Unaudited" reads as "team didn't care" · fair or not.
The trust death-spiral. Even a small exploit, fully reimbursed, permanently changes how your community talks about you. Trust is the only non-recoverable asset in crypto.

"But we used OpenZeppelin" · the standard-code trap

Standards-based building blocks genuinely reduce risk · that's why we build on them. But almost no real token ships OpenZeppelin untouched: there's a tax hook here, a vesting schedule there, a custom mint gate for the airdrop. The bugs live precisely in those edits and in the seams between audited components. The base contracts being audited says nothing about what your modifications did to their assumptions. So "we used OpenZeppelin" is a great answer to "how did you build it" and a non-answer to "was it reviewed."

Automated scanners are the floor, not the audit

Run Slither. Run Echidna. We do, on everything · they're free-to-cheap and they catch a real class of mechanical bugs before a human ever reads the code. But scanners don't know your intent: they can't see that the vesting math unlocks a year early, that the fee split quietly lets an admin drain the pool, or that your oracle can be nudged in a sandwich. Business-logic bugs · the expensive kind · are found by humans reasoning about what the code is supposed to do. Tooling is hygiene; review is security. Our smart contract audit checklist shows what a real human pass covers.

When you genuinely can skip it

An honest list, because "always audit everything" is vendor talk. Testnet-only experiments · nothing at risk, iterate freely. Throwaway prototypes built to validate an idea before the real build. Contracts that never custody value · pure on-chain registries or attestations with no funds flow (though even these deserve a tooling pass). And forks deployed unchanged from a heavily-audited codebase are a gray zone · lower risk, but configuration and deployment mistakes have drained "unchanged" forks before. If you're deciding whether you're in a skip case or just hoping you are, that uncertainty is itself the answer.

How to fit an audit into a tight budget

The audit-shaped hole in most budgets is a planning failure, not a money one. Scope the contracts lean · every feature you postpone shrinks the review. Build standards-based so reviewers move fast through familiar code. Match the tier to value at risk · a boutique reviewer or contest is a legitimate choice for a simple token; you don't need a marquee name for an ERC-20. Book early and skip the rush premium. And budget the audit as a launch line-item from day one · in our quotes it's built in, never bolted on, because an audit you're "planning to add later" is an audit that never happens. Where it sits among the other launch costs: the token launch cost breakdown.

How we handle it

Audit-first is the whole studio thesis. Every contract we ship gets a fresh-eyes internal review and a Slither + Echidna pass before any external auditor sees it · so you're not paying a firm to find lint. We then coordinate the external audit at the tier your value-at-risk actually warrants, from boutique reviewers and contests up to Trail of Bits / OpenZeppelin / Spearbit, address findings, and pay for the re-audit of every meaningful change. Fixed scope, fixed quote, audit included. Send a brief · we'll reply within a day with which review tier your project honestly needs.

FAQ

Do I need an audit before launching?
If the contract holds, moves, or controls real value · yes, at a tier matched to the value at risk. Focused review for plain tokens, full audit for custom logic, top-tier engagement for protocols and bridges. Only testnet experiments and no-value contracts are exempt.

Can I launch a token without one?
Nothing stops you, but you stack three costs: unpatchable bugs, listing walls at launchpads and exchanges that ask for reports, and buyers who check. The saving is small; the exposure isn't.

Is a plain ERC-20 exempt?
It's the lowest-risk case, so a focused review is proportionate · but most "plain" tokens carry small edits, and the edits are where bugs live. Vesting, taxes, or upgradeability make it custom code.

Are scanners like Slither enough?
No · they catch mechanical bugs, not business-logic ones. Tooling is the floor; human review is the audit.

What if there's a bug after launch?
Immutable code usually can't be patched · you mitigate or migrate, and lost funds stay lost. That asymmetry between bounded audit cost and unbounded failure cost is the entire argument.