An audit is not a guarantee
A smart-contract audit is an independent review of a defined code scope for defects and design risks. It is an important quality step before launch, but it is not a guarantee that every bug is absent or that losses will be reimbursed. Ethereum's security guidance explicitly warns against treating an audit as a silver bullet.
Check scope and version
Read the repository, commit hash, contract address, date, and exclusions on the report's opening pages. A site can display an audit badge even when the live deployment differs from the reviewed version. If oracles, bridges, administrative scripts, or the frontend were excluded, the entire application was not audited.
Undiscovered defects
Auditors work under limited time and assumptions using people, tools, and tests. Static analysis, fuzzing, manual review, and formal verification find different classes of problems, yet no one method covers every execution path and economic attack. No critical findings is not equivalent to no risk.
Risks outside the code
Correct code can still lose funds through a compromised administrator, bad price data, a depegged token, captured governance, or insufficient liquidity. In a composable application, the safety of each individual contract differs from the safety of the combined system. Operational and market risks need separate treatment.
Remediation and review
Check whether each finding was fixed and whether the changed version was reviewed again. Confirmed, mitigated, and accepted are different dispositions, and a project may knowingly retain a risk. After an upgrade, look for review of the new code and verify the actual onchain deployment.
What a user should read
Users gain more from reading scope, version, high-severity findings, unresolved items, privileged roles, bug bounties, and monitoring than from recognizing the auditor's name. Test deposit and withdrawal with a small amount and avoid concentrating an unaffordable sum in one protocol. An audit is one layer of risk management, not a final verdict.