A protocol’s website can look polished, its token can be listed on a major exchange, and its Twitter account can post daily updates, and none of that tells you whether the code holding your deposits actually does what it claims. That’s what a smart contract audit is supposed to check. But most people never open the report, and the ones who do often can’t make sense of it. This piece walks through what an audit actually checks, how to read one without writing a line of code, and why a passed audit is not the same as a safety guarantee.
What a smart contract audit actually checks (and what it doesn’t)
A smart contract audit is a manual and automated review of a protocol’s code, done before or shortly after launch, looking for bugs that could let someone drain funds, mint unlimited tokens, lock up deposits, or manipulate prices inside the contract. Auditors read the code line by line, run automated tools that scan for known vulnerability patterns, and often try to break the contract themselves using test scenarios.
What it checks: logic errors, access control mistakes (who can call which functions), r-eentrancy bugs (a well-known class of exploit where a function gets called repeatedly before it finishes updating its own records), integer overflow issues, and whether the contract matches its own documentation.
What it doesn’t check: the people running the project, whether the team can rug the treasury through an admin key the audit flagged as fine, whether the protocol’s economic model actually works under stress, or what happens when it interacts with other protocols that get hacked later. An audit is a code review, not a background check and not a crystal ball for market conditions.
Who performs audits and how the process typically works
Audits are usually done by independent security firms that specialize in blockchain code. Some names come up often in the space, and part of your due diligence is recognizing which firms have a track record and which are unknown entities that appeared recently with a slick website.
The typical process: the project sends its code to the firm, often before main-net launch. The firm reviews it over a set period, usually days to a few weeks depending on the contract’s size and complexity, and produces a report listing every issue found, rated by severity. The project then has a chance to fix the issues and request a follow-up review, which gets added to the report as a resolution section.
That last part matters more than people realize. A report dated six months before launch, with no record of the findings being fixed, tells you the team paid for a scan and then shipped something else, or shipped the flagged version anyway.
Reading an audit report without knowing how to code
You don’t need to read Solidity to get real information out of an audit report. Most reports follow a similar structure, and you can extract what matters by checking three things in order.
First, read the summary page. Nearly every report opens with a table listing the total number of findings by severity, and whether each one was resolved, acknowledged, or left open. This single table tells you more than the rest of the document combined.
Second, read the plain-English description of each finding, not the code snippet underneath it. Auditors write a short explanation of what the bug does and why it matters before they show the technical detail. If a critical finding’s description says something like “an attacker could withdraw all funds from the pool without authorization,” you don’t need to understand the fix to understand the risk.
Third, check the resolution status of anything rated critical or high. Look for words like “resolved,” “fixed,” or “mitigated” next to those findings. If a critical finding is marked “acknowledged” or “not fixed,” that means the team knew about a serious problem and launched anyway, or hasn’t launched the fix yet.
Severity ratings explained: critical, high, medium, low findings
Audit firms generally use a four-tier scale, though exact wording varies between firms.
-
Critical: a bug that could lead directly to loss of funds, often with no special conditions required. These need to be fixed before you trust the contract with any money.
-
High: a serious bug that could lead to loss of funds or broken functionality under specific but realistic conditions. Treat unresolved high findings almost as seriously as unresolved critical ones.
-
Medium: issues that don’t directly risk funds but weaken the contract’s security, such as missing checks that could cause problems if the protocol is upgraded or extended later.
-
Low / informational: style issues, gas inefficiencies, or best-practice suggestions that don’t represent a real threat on their own.
The number of findings matters less than their severity and resolution status. A report with twenty low-severity notes and zero unresolved critical or high findings describes a contract in much better shape than one with two findings total, if one of those two is a critical issue marked “acknowledged, no fix planned.”
Red flags that signal a weak, outdated, or fake audit
Some warning signs you can check in a few minutes:
-
No report link, just a badge. If a protocol’s site shows an “Audited” badge or logo with no link to an actual report, treat that as a red flag. Anyone can put a badge image on a website.
-
The audit covers an old version of the contract. Check the contract address or commit hash in the report against what’s actually deployed. Projects sometimes get a contract audited, then change the code before launch without a re-audit.
-
Unknown or unverifiable auditor. If you can’t find the firm’s past work, website, or team outside of this one project, be cautious. Established firms have a history of public reports you can cross-check.
-
Critical or high findings with no resolution. Covered above, but worth repeating: this is the single most important thing to check and the one most people skip.
-
Self-audits presented as independent review. Some projects publish an internal security review written by their own developers and label it an audit. It’s not the same thing as a third-party assessment.
-
Audit scope excludes the contracts that actually hold funds. Sometimes only a token contract gets reviewed while the staking pool, vault, or bridge contract, the part that actually holds deposits, is left out of scope entirely. Check which specific contract addresses the report covers.
Why a clean audit still isn’t a guarantee of safety
Even a report with zero unresolved findings from a reputable firm doesn’t make a protocol safe. A few reasons why.
Audits review code at a point in time. If a team deploys new contracts or changes parameters after the audit, through an upgradeable proxy pattern, for example, the audited code may no longer match what’s live. Some of the largest DeFi exploits have hit protocols with clean audit histories, where the bug existed in an interaction between two audited contracts that neither audit covered in isolation.
Audits also can’t catch everything. Auditors work within a time budget, and complex contracts have enormous numbers of possible execution paths. A firm can miss a bug the same way a careful proofreader can miss a typo, not from negligence, but because exhaustive coverage of every possible interaction isn’t realistic within the engagement.
And an audit says nothing about centralization risk. If the team holds an admin key that can pause withdrawals, change fees, or upgrade the contract unilaterally, the code can be flawless and the protocol still unsafe, because the risk isn’t a bug, it’s a person with unchecked control. Check whether admin functions are behind a multisig, a timelock, or a single wallet, and treat that as separate information from the audit itself.
This is the same gap that shows up in yield farming, where the protocol’s contracts can be sound and the real risk sits in token economics, impermanent loss, or a connected protocol failing. An audit narrows one category of risk. It doesn’t close the rest.
Where to check a project’s audit before you connect a wallet
Before connecting a wallet or depositing funds, look for the audit report on the project’s own documentation site, usually under a “Security” or “Audits” page. Reputable audit firms also publish their completed reports on their own sites or public repositories, which gives you a second place to verify the report is genuine and matches what the project links to.
Check the contract address in the report against the address shown in your wallet or on a block explorer before you sign a transaction. If the addresses don’t match, you may be looking at a different version of the contract than the one you’re about to interact with.
If a project has no public audit at all, that’s information too. Plenty of real protocols operate without one, particularly early on, but that shifts the risk entirely onto you and the amount you’re willing to risk should reflect that.
Before putting funds into any DeFi protocol, including yield farming pools, look up its audit report and check it against the red flags in this piece. For a deeper look at what can go wrong even in audited protocols, see the yield farming guide.