“Audited” is the most over-read word in this industry. It is treated as a binary property of a project, when it is actually a statement about a specific set of files at a specific moment, made by a specific firm, under a scope both parties agreed in advance.
Reading the report rather than the badge takes about ten minutes and changes what you know.
Start at the scope, not the findings
Every credible report has a scope section, usually within the first two pages. It names the repository, the commit hash reviewed, and the list of contract files in scope. This is the single most useful part of the document.
The commit hash matters because it dates the review precisely. Any code written after that commit — including the fix for the findings in the report itself — was not part of what was examined. A project that audited in March and shipped new functionality in June has audited code and unaudited code deployed together, and only the report tells you which is which.
Read what was excluded
Scope sections also say what was not reviewed, and that list is often more interesting than the findings. Common exclusions: the front end, deployment scripts, off-chain infrastructure, oracle configuration, admin key management, and any third-party contract the system depends on.
Those exclusions map almost exactly onto how systems actually fail. A front-end compromise happens in a layer that contract audits do not cover at all, and admin key control — who can upgrade or pause — is frequently out of scope while being the thing that determines whether funds can be taken.
Findings: severity, and what happened next
Findings are usually graded critical through informational. Two questions matter more than the count:
- Was each finding fixed, acknowledged, or disputed? Reports normally record the project’s response. “Acknowledged” means the project read it and chose not to change anything — which may be reasonable, but it is a decision, not a fix.
- Was the fix re-reviewed? A fix written after the review and never re-examined is new unaudited code in the most sensitive part of the system.
What an audit structurally cannot catch
Auditors review code against intent. Where the intent itself is flawed, the code can be correct and the system still lose money — that is a business logic flaw, and it is the class most likely to survive review, because nothing looks wrong line by line. The Euler Finance donation attack is a record of that shape.
Audits also assume the compiler produces what the source says. Where that assumption fails — a toolchain compromise — reviewed source and deployed bytecode diverge, as in the Curve Finance Vyper reentrancy records.
A short checklist
- Is there a report at all, published in full — not a summary or a logo?
- Which commit was reviewed, and does the deployed code match it?
- What was explicitly out of scope?
- Were critical and high findings fixed, and were the fixes re-reviewed?
- Is there also a bug bounty, which covers code as it changes rather than one snapshot?
Not advice. Conisec reports for information only. Nothing in this article is financial, legal, tax or security advice. Verify against the primary sources linked above before acting on anything.
