An audit is a manual and tool-assisted review of a codebase by engineers who did not write it, looking for logic errors, economic flaws and deviations between what the code does and what the documentation says it does. It is genuinely valuable — most serious findings are found this way — and it is routinely presented as something it is not.
Start with scope, which is stated on the first page of every honest report and read by almost nobody. An audit covers named files at a named commit hash. Anything outside that boundary was not examined: the deployment scripts, the upgrade mechanism, the off-chain components, the oracle the contracts depend on, the front end that users actually interact with, and any dependency pulled in as a library. A protocol drained through a component outside the scope was, technically, audited.
Then the commit. Code changes after an audit, and a single line altered after review is unreviewed code in a contract holding funds. The meaningful question is whether the deployed bytecode corresponds to the audited commit, which is checkable on a block explorer and rarely checked. A badge on a website carries no version.
Then the findings. A useful report lists issues by severity, states which were fixed, which were acknowledged and not fixed, and why. The acknowledged-and-not-fixed section is the most informative part of any audit and the least read: it is where the team's risk appetite is written down in someone else's words. A report with no findings at all is not reassurance; it usually means a narrow scope or a shallow review.
Finally, what audits structurally cannot catch. Economic design flaws that only appear under market conditions the reviewers did not model — oracle manipulation under a flash loan being the classic case. Governance risk, where the code works exactly as written and the people controlling it change the parameters. Composability risk, where the contract is correct and the protocol it integrates with is not. And key management, which is not in the code at all and has caused more losses than logic bugs.
The practical reading is a short checklist. Who audited it, and do they publish their reports? Which commit, and does it match what is deployed? What was in scope, and does that scope include the parts holding money? What was acknowledged and not fixed? Is there a live bug bounty, which is a continuous version of the same review and often a better signal than a one-off report? A protocol that answers all five is not safe, but it is a protocol whose risks somebody has written down.