Disclosure: This post contains affiliate links; we may earn a commission at no extra cost to you.
“Audited” gets slapped on project websites like a food-safety sticker, but an audit is a snapshot of one version of the code reviewed by one firm — it isn't a guarantee. Euler Finance was audited by multiple reputable firms and still lost around $197 million to a donation-attack/self-liquidation exploit in March 2023. Knowing how to actually read a contract's real risk matters more than checking whether a PDF exists.
What an audit actually covers — and doesn't
A smart contract audit is a manual and automated code review looking for known vulnerability classes: reentrancy, integer overflow, access-control mistakes, oracle manipulation paths, flash-loan attack surfaces. Firms like CertiK, Trail of Bits, and OpenZeppelin publish reports rating severity of findings. What an audit does NOT cover: bugs introduced in code shipped after the audit date (a shockingly common cause of exploits), economic/game-theory attacks the auditors didn't model, and admin-key risk — if the deployer can upgrade the contract or drain a treasury with a multisig, no amount of clean Solidity protects you from that key being compromised or misused.
Real exploits, and what actually went wrong
| Incident | Approx. loss | Root cause |
|---|---|---|
| Poly Network (2021) | ~$611M | Cross-chain contract's keeper-permission check was bypassable — not a reentrancy bug, a design/access-control flaw |
| Ronin Bridge (2022) | ~$625M | Compromised validator private keys, not a code exploit — 5 of 9 signer keys taken |
| Euler Finance (2023) | ~$197M | Donation attack manipulated the protocol's own health-check logic to allow self-liquidation for profit |
| Curve Finance (2023) | ~$70M+ | Reentrancy bug in specific Vyper compiler versions, affecting several pools using those versions |
The pattern: half of the biggest losses in crypto history weren't “the audit missed a bug” — they were key custody failures (Ronin) or economic-logic exploits auditors don't always model well (Euler). A clean audit report tells you less than most people assume.
A practical risk checklist before you interact with any contract
- Check contract verification on Etherscan/BscScan. If the source code isn't verified, you're trusting a black box — walk away, no exceptions.
- Look at who can upgrade or pause it. Search the verified source for owner-only functions like
upgradeTo,pause, orsetFeeRecipient. A single EOA (not a multisig) holding owner privileges on a protocol holding real TVL is a red flag regardless of audit status. - Check TokenSniffer or RugDoc for newer/smaller tokens. These scan for common rug-pull patterns: honeypot sell restrictions, mint functions, ownership not renounced.
- Look up the audit firm's actual report, not just a logo. Read the severity findings and whether they were “resolved” or just “acknowledged.” A project that acknowledges a high-severity finding without fixing it is not meaningfully safer than an unaudited one.
- Check DeFiSafety's process-quality reviews. Unlike a code audit, DeFiSafety scores documentation, testing practices, and admin-key controls — a different and complementary risk signal.
- Revoke stale approvals. Every ERC-20 approval you've ever granted is a live attack surface even for protocols you no longer use. Revoke.cash lets you see and cancel every approval your wallet has outstanding, for free.
The custody layer most people ignore
Everything above reduces contract risk. It does nothing for the separate risk of your own private key being phished, malware-stolen, or exposed through a compromised browser extension — which is how a large share of individual-user losses actually happen, separate from any protocol-level exploit. Keeping meaningful balances on a hardware wallet like a Ledger means a malicious dApp or a spoofed approval popup still can't move funds without a physical confirmation on the device, and Ledger's interface shows you exactly what you're approving instead of a wall of hex data.
Our pick: Ledger
Reentrancy, in plain terms
Reentrancy is the vulnerability class behind the original 2016 DAO hack and it's still showing up in 2023's Curve incident, so it's worth understanding in plain terms rather than just as a buzzword. A contract function that sends funds out (say, a withdrawal) and only updates its internal balance-tracking AFTER the transfer completes can be re-entered: a malicious contract receiving that transfer can call back into the same withdrawal function before the balance updates, and withdraw again, and again, in a loop, all within a single transaction. The fix is the “checks-effects-interactions” pattern — update internal state BEFORE sending funds out, not after — and it's one of the first things a competent auditor checks for. When you're evaluating a protocol yourself without reading Solidity, the practical proxy is: has this specific contract (and this specific compiler version) been re-audited since its last meaningful upgrade, not just at launch. Curve's 2023 exploit only hit pools built with certain Vyper compiler versions — the underlying protocol design was fine, but a compiler-level reentrancy guard silently failed to compile correctly in specific versions.
Risk transfer: insuring against a exploit you can't personally audit
Even with every check above, you can't personally verify code the way a professional auditor can. Nexus Mutual and InsurAce offer smart-contract-specific coverage: you pay a premium (often a few percent of covered value per year) against a specific protocol, and if that protocol is exploited and the claim is validated, you get reimbursed in stablecoins. This isn't a substitute for the checklist above — premiums tend to be priced higher for protocols the market itself considers riskier, which is a useful signal on its own — but for meaningful DeFi positions it's a real, working risk-transfer tool, not a theoretical one; Nexus Mutual has paid out real claims on past exploits including bZx and Cream Finance.
FAQ
Does “audited by CertiK” mean a protocol is safe to use?
It means one firm reviewed one version of the code for known vulnerability classes. It doesn't cover admin-key risk, post-audit code changes, or novel economic attacks — treat it as one data point, not a green light.
What's the single highest-signal free check before using a new protocol?
Whether the contract's admin functions are behind a multisig/timelock versus a single wallet. Concentrated admin control has caused or worsened more losses than missed code bugs.
Do audits cover bridges the same way as DeFi protocols?
Bridges carry additional custody/validator risk on top of contract risk (see Ronin above), so a bridge audit typically needs to be read alongside its validator-set design, not in isolation.
Is a higher TVL protocol automatically safer?
Not necessarily — Euler had significant TVL and multiple audits before its exploit. TVL reflects trust and adoption, not code correctness.