What a smart contract audit actually checks (and what it doesn't)

"Audited" gets treated as a safety stamp. It's real, useful information — just narrower than most people assume.

A smart contract audit is a firm reading a project's code, by hand and with automated tools, looking for ways it could be exploited: reentrancy bugs, integer overflow, access-control mistakes, logic that lets someone drain funds or mint unlimited tokens. When it's done well, by a reputable firm, it's a genuinely valuable, technical check — this guide isn't arguing against audits.

What an audit does NOT tell you:

• Whether the team is honest. An audit checks that the code does what the team says it does — it can't tell you whether what they say it does is a good idea, or whether they'll keep their other promises (roadmap, fund usage, decentralization timeline).
• Whether the deployed code matches the audited code. Teams occasionally change the contract after the audit and deploy the new version without a re-audit. Worth checking the audit report's date and contract address against what's actually live.
• Whether admin keys are a risk. Code can be exploit-free and still let an admin wallet pause trading, change fees, or mint new tokens at will — an audit will usually note these powers exist, but "audited" doesn't mean "no one has outsized control."
• Anything about tokenomics, VC allocation, or vesting. That's a financial-design question, not a code-security one — a project can have flawless, audited code and still be structured to dump on early buyers.

Why this matters to you specifically: "audited" is one real, positive signal — not a finish line. The useful habit is checking what firm did it (see our guide on red flags for how audit-firm reputation varies), what scope the audit actually covered, and whether the other categories (team, tokenomics, admin controls) got any independent look at all.