Smart Contract Audits: What They Do and Do Not Prove
A smart-contract audit reviews a defined codebase or system for security issues within a specified scope and time. It provides evidence about that review, not insurance or proof that a deployed application is safe.
How it works
Read the auditor, repository, commit, deployment addresses, scope, assumptions, findings and remediation status. Determine whether the live code is upgradeable and who can change it. An audit of token code may exclude a website, bridge, oracle, administrator key or economic mechanism that ultimately causes a loss.
Worked example
A report reviews commit A and notes an unresolved high-severity permission issue. A site displays the auditor’s logo next to a later contract at address B. Before relying on the report, match the code and deployment, inspect the unresolved issue and identify changes after A. A logo alone establishes none of those facts.
Amounts, prices and scenarios are fictional teaching examples. They exclude any effects not explicitly stated and are not trade recommendations.
Limits and common mistakes
Audits can miss bugs, economic attacks and operational failures. Formal verification proves properties under a model, not every desirable real-world outcome. Multiple reports help only when their scope and quality address the relevant risks.
Knowledge check
Does a completed audit guarantee reimbursement after a hack?
Read the explanation
No. Any reimbursement would depend on separate enforceable arrangements or insurance terms, not on the mere existence of an audit report.
References and further reading
These sources explain the underlying concepts and specifications. They do not endorse QBMFX Academy. Check the relevant market, protocol version and reporting rules before applying an example.