What does an "audited" badge guarantee?
DeFi websites often display an "audited by" badge from a security firm. Being audited is a positive sign, but it is not a promise that users cannot lose funds. Several large exploits have hit services that had been audited.
This guide explains what a smart contract audit actually examines, why scope and code version matter, which flaws an audit can miss, and which risks lie outside the code entirely. It ends with the parts of an audit report that non-developers can check for themselves.
What an audit does
An audit is a review by security specialists of code at a specific point in time, looking for known vulnerability patterns, logic errors, and permission problems. Ethereum.org's guide to security tools describes static analysis, fuzzing (testing with random inputs), and formal verification, and auditors combine tools like these with manual review.
Frameworks such as OWASP's smart contract security standard organize what should be checked. Whatever the method, an audit reports problems found; it does not prove there are none. A report with few findings means the auditors found no more within that scope and time.
What audits usually cover, and what they don't
When reading an audit report, start by separating what was in scope from what was left out.
| Area | Usually in scope | Usually out of scope |
|---|---|---|
| Code | Contracts and commit listed in the report | Later changes or upgrades, excluded contracts |
| External dependencies | How oracle calls are made | Accuracy of oracle data, bugs in other protocols |
| Operations | Existence and structure of admin functions | Actual key management, team decisions, insider risk |
| Economic design | Sometimes reviewed in limited form | Incentive failure in market stress, large capital attacks |
| User interface | Rarely included | Tampered front ends, phishing sites |
Scope varies from audit to audit. Check the "scope" and "commit hash" sections at the start of the report first.
Versions and fixes
An audit covers a specific commit, one version of the code. Consider a hypothetical case: if version 1 was audited in March and version 2 with new features was deployed in June, the code that changed in version 2 has not been audited. You can compare the verified source of the deployed contract in a block explorer with the commit hash listed in the report.
How findings were handled matters too. Auditors typically rank issues by severity and record the team's response: fixed, partially fixed, or acknowledged. A serious issue left as "acknowledged" deserves an explanation.
Risks outside the code
Many incidents start outside the code. Leaked admin keys, manipulated price feeds, or the failure of a connected protocol can all harm audited contracts. Ethereum.org's smart contract security documentation treats access control and external dependencies as major risk areas.
Economic design is another gap. Code can behave exactly as intended while a market shock, or someone borrowing large sums to move a price for a single block, produces losses the designers did not anticipate. Code review alone rarely catches these.
Easy mistakes
"A well-known firm audited it, so it's safe" skips over scope and timing. The depth of an audit depends on how long it ran, how many reviewers were involved, and what was included, even at the same firm.
"It has several audits, so it's safer" is true only under conditions. Several audits looking at the same version from different angles help; several audits each covering part of a different version may mean no audit has examined the code that is actually deployed today.
What users can read in an audit report
Audit reports are technical, but these items can be checked without being a developer.
- Note the report date, the list of contracts in scope, and the commit hash.
- In a block explorer, check that the deployed contract's verified source matches the audited commit.
- Count high- and critical-severity findings and check each one's status: fixed, partially fixed, or acknowledged.
- List anything the report explicitly excludes, such as oracles, admin keys, or economic design, and check those separately.
- Find out whether the contracts were upgraded after the audit and whether the changes were audited.
What remains after an audit
An audit is one part of reducing risk, not a way to remove it. Bug bounty programs, staged rollouts, deposit caps, and emergency pause mechanisms are further clues to a service's security posture.
The version example is hypothetical. When using a real service, check the latest audit reports and official documentation with their dates, and, audited or not, only commit amounts you could afford to lose.