Disclosure: This post contains affiliate links; we may earn a commission at no extra cost to you.
“Audited by CertiK” gets slapped on a protocol's landing page like a certification badge, and a lot of users treat it as a green light to deposit funds without checking anything further. That's the wrong read on what an audit actually is. Here's what a smart-contract audit actually catches, what it doesn't, and how to tell a real audit from marketing.
What a smart-contract audit actually is
A security audit is a manual code review plus automated static analysis performed by a third-party firm — well-known names include Trail of Bits, OpenZeppelin, CertiK, Quantstamp, and PeckShield — looking for known vulnerability classes: reentrancy bugs, integer overflow/underflow, access-control mistakes (functions that should be restricted to an admin but aren't), unchecked external calls, and flash-loan-manipulable logic. Firms deliver a written report listing findings by severity (critical/high/medium/low/informational), and a legitimate protocol team fixes the critical and high findings before or shortly after launch. That report existing and being public is the actual signal — the badge on the homepage is not.
What audits reliably catch
- Reentrancy vulnerabilities (the class of bug behind the original 2016 DAO hack)
- Access-control errors — a function that transfers funds or changes protocol parameters without proper permission checks
- Integer overflow/underflow in older Solidity versions without built-in overflow protection
- Unchecked low-level calls and improper error handling
- Straightforward logic errors in isolated, well-scoped functions
What audits routinely miss
This is the part that matters most, because it's where real losses keep happening to “audited” protocols. Audits are a point-in-time review of a specific code version — they don't cover code shipped after the audit date, and plenty of protocols push unaudited updates post-launch. They also generally don't catch economic/oracle-manipulation exploits, which have become the dominant hack vector: Euler Finance lost roughly $197 million in March 2023 despite having been audited by multiple firms, because the exploit abused a legitimate-looking sequence of protocol interactions (a donation-then-liquidation logic flaw) rather than a classic code bug. Cream Finance was hacked repeatedly across 2021 despite audits, largely through oracle price manipulation and flash-loan-enabled exploits that fall outside what a standard code review is built to catch. An audit also does nothing to protect against admin-key rug pulls, where the code is fine but the team retains a privileged key that lets them drain funds or change rules unilaterally.
How to check if an “audited” badge is real
- Find the actual report, not just the badge. Legitimate audit firms publish or link the full PDF report. If a protocol claims an audit but you can't find the report on the firm's own site or the protocol's GitHub/docs, treat the claim as unverified.
- Check the audit date against the current deployed code. A protocol audited a year ago that has since shipped major unaudited upgrades is functionally closer to unaudited for the new code.
- Check whether findings were actually resolved — reports list findings and, ideally, a remediation status. “Audited” doesn't mean “passed clean”; some reports show unresolved critical findings the team shipped anyway.
- Cross-reference incident databases like Rekt.news and DeFiSafety's protocol scorecards, which track both hacks and audit-quality assessments independent of what a protocol claims about itself.
Signals beyond the audit itself
A bug bounty through a platform like Immunefi, sized proportionally to the protocol's total value locked, is a stronger ongoing safety signal than a single past audit — it means the team is paying for continuous scrutiny, not a one-time check-the-box review. For the highest-value protocols, formal verification (mathematically proving code behaves as specified, rather than just reviewing it for known bug patterns) goes further than a standard audit; MakerDAO and a handful of major lending protocols have used formal methods on their most critical contracts. Multiple independent audits from different firms is also meaningfully stronger than one, since different firms tend to catch different classes of issues.
Are unaudited protocols always a mistake?
Not automatically avoidable in every case, but the risk math needs to be explicit. Brand-new forks of established, audited protocols inherit some — not all — of the original's tested logic, but any modifications are themselves unaudited by definition. Elevated yield on an unaudited protocol is compensation for real, uninsured risk, not free money; if a farm is paying meaningfully more than an audited, established alternative for a similar strategy, that spread is the market pricing in exactly the risk described above. Position sizing should reflect that: money in unaudited or newly-launched protocols should be sized as risk capital you can lose entirely, not treated the same as an allocation to an established, multi-audited protocol.
Audited vs. unaudited: what the label actually tells you
| Status | What it signals | What it doesn't cover |
|---|---|---|
| Single audit, badge only, no public report | Weak — unverifiable claim | Everything — treat as effectively unaudited |
| Single audit, public report, findings resolved | Baseline code-level review done | Post-audit code changes, economic/oracle exploits, admin-key risk |
| Multiple independent audits + active bug bounty | Strong, ongoing scrutiny | Novel exploit classes, extreme market conditions |
| Formally verified critical contracts | Highest assurance level available today | Still doesn't cover governance/admin-key risk |
| No audit, no bounty, new team | Unverified — highest risk tier | N/A — size accordingly |
Protect the custody layer regardless of audit status
None of this replaces basic custody hygiene when interacting with any protocol, audited or not. Approving a malicious or overly broad token-spend permission is a separate risk from the protocol's own code quality, and it's one a hardware wallet like a Ledger device meaningfully reduces by keeping private keys offline and forcing an explicit physical confirmation for every transaction — including contract approvals, which is exactly the step most wallet-drain exploits rely on users clicking through without reading.
Our pick: Ledger
FAQ
Does an audit guarantee a protocol is safe?
No. It reduces the risk of known code-level vulnerability classes at a specific point in time; it does not cover economic exploits, admin-key risk, or any code shipped after the audit date.
What's the difference between an audit and formal verification?
An audit is a manual + automated review for known bug patterns. Formal verification mathematically proves a contract behaves according to a written specification — more rigorous, more expensive, and generally reserved for a protocol's highest-value core contracts.
How do I confirm an audit claim is real?
Find the actual report on the audit firm's own site or the protocol's official GitHub/docs, check the date against current deployed code, and confirm listed findings were resolved.
Should I ever use an unaudited protocol?
Only with money sized as fully at-risk capital, treating elevated yield as compensation for that specific risk rather than a bonus.
The verdict
An audit is a meaningful but incomplete safety signal — real for the specific bug classes it checks, silent on economic exploits and admin-key risk, and only as current as its last review date. Verify the report exists and is recent, weigh bug-bounty size and repeat-audit history as ongoing signals, and size any position in an unaudited protocol as capital you're prepared to lose outright.