Does a clean audit mean a protocol is safe to use?

No. A clean audit means reviewers did not find certain classes of problems in a specific version of the code within their scope and time. It lowers some risks but does not guarantee safety, and it says nothing about economics, keys, or the front-end.

Why do audited protocols still get hacked?

Common reasons include code changed after the audit, components that were out of scope, economic attacks like oracle manipulation, and off-chain failures such as compromised keys or a hacked website. These fall outside a standard contract audit's scope.

How do I know the audit applies to the contract I am using?

Check that the commit hash named in the report matches the code deployed at the on-chain address you interact with. If the deployed code differs or has been upgraded, the audit's assurances may not apply.

Is a formal verification stronger than an audit?

Formal verification mathematically proves specific stated properties, which is powerful, but it only covers the properties that were formally specified. Anything outside that specification remains unverified, so it complements rather than replaces broader review.

Are multiple audits better than one?

Generally yes. Independent reviewers find different issues, so multiple audits plus bug bounties, fuzzing, and monitoring provide more coverage than any single review. Serious protocols increasingly use several layers rather than relying on one report.

What Smart Contract Audits Do and Don't Prove

An audit is a scoped review of one version of the code, not a safety guarantee. Here is exactly what a clean report supports and what it leaves open.

What an audit is

A smart contract security audit is a time-boxed review of a specific codebase by engineers who look for vulnerabilities, logic errors, and deviations from intended behaviour, and then write a report. The good firms combine several techniques: manual line-by-line review, automated static analysis, property-based testing and fuzzing, and in some cases formal verification of narrowly defined properties. The output is a list of findings, each with a severity rating and a recommended fix, plus a record of what the team fixed or acknowledged.

An audit is genuinely valuable. It catches real bugs, forces the development team to document assumptions, and produces an artefact that others can read. But an audit is frequently misread as a guarantee of safety, and it is not one. Understanding the precise boundary between what an audit demonstrates and what it cannot is one of the most important literacy skills in this space.

What an audit can show

That specific vulnerability classes were searched for within a defined scope. Reentrancy, integer overflow and underflow, access-control gaps, unchecked external calls, and similar known patterns are exactly what auditors are trained to find. A clean report on these is meaningful evidence, within the scope reviewed.
That the code matches, or fails to match, its stated specification. A large share of an audit’s value is checking whether the contract does what the documentation claims. Discrepancies between intent and implementation are a leading source of findings.
A snapshot in time of a particular commit. The report applies to the exact code reviewed, identified by a commit hash. It is a photograph, not a live feed.
The development team’s response. A report showing that high-severity findings were fixed and re-reviewed tells you more than a raw count of issues found.

What an audit cannot prove

This is where careful reading pays off. An audit does not establish the following, no matter how reputable the firm.

The absence of bugs

Auditing can demonstrate the presence of vulnerabilities but not their absence. Reviewers work under time and budget limits, on code of finite readability, against an unbounded space of possible inputs and interactions. Even full formal verification only proves the specific properties that were formally stated; anything not stated is out of scope by construction. A clean report lowers the probability of certain failure modes; it does not drive risk to zero.

Safety after the code changes

An audit covers one commit. If the team ships new code, upgrades a proxy, or changes a configuration parameter after the review, the audited guarantee no longer covers the deployed system. Many incidents involve code that was modified, or a component that was never in scope, after an audit was completed. Always confirm that the deployed address corresponds to the audited commit.

Economic and design soundness

Code can be flawless and the mechanism still be exploitable. Oracle manipulation, flash-loan-funded price distortion, governance capture, incentive designs that unravel under stress, and unhealthy collateral parameters are economic and architectural risks. Some auditors comment on these, but a standard security audit is not a guarantee that the protocol’s economics are safe.

Off-chain and operational risk

A very large share of losses in practice come from outside the reviewed contracts entirely: compromised private keys, malicious or careless admin actions, front-end and DNS attacks, supply-chain compromise of dependencies, and social engineering. A contract audit is scoped to on-chain code and generally does not cover the keys that control it or the website users interact with.

The behaviour of external dependencies

Modern protocols compose. They call other contracts, read external price feeds, and depend on tokens they do not control. An audit of your contract cannot vouch for the integrations it relies on, and an assumption that an external contract behaves a certain way is only as good as that contract.

How to read an audit report

Treat the report as a document to interrogate, not a badge to trust. A practical checklist:

Scope. Which files and which commit were reviewed? What was explicitly excluded? The scope section often matters more than the findings.
Commit versus deployment. Does the audited commit hash match what is actually deployed on-chain today? If you cannot verify this, the report’s assurances are unanchored.
Severity and resolution. How many high and critical findings were there, and were they fixed and re-reviewed, acknowledged, or ignored? Acknowledged-but-unfixed criticals are a signal.
Recency and change history. How old is the review, and has the code changed since? An old audit of heavily modified code offers weak assurance.
Who performed it. A named, reputable firm publishing its methodology carries more weight than an anonymous or undocumented review.
Number of independent reviews. Serious protocols increasingly commission multiple audits, run bug bounties, and add monitoring, precisely because a single review is not sufficient.

Where an audit sits among other techniques

It helps to place a manual audit next to the other assurance techniques, because they answer different questions and are frequently conflated.

Manual audit. Human reviewers reason about intent, edge cases, and interactions that tools miss. Strong on logic and design flaws, bounded by time and reviewer attention.
Static analysis. Automated tools scan source for known dangerous patterns. Fast and cheap, good at flagging suspects, but produce false positives and cannot understand intended behaviour.
Fuzzing and property-based testing. The system is bombarded with generated inputs to see whether stated invariants ever break. Excellent for surfacing unexpected states, but only tests the properties and input space the team defined.
Formal verification. Mathematically proves that the code satisfies precisely stated properties. The strongest guarantee available, but strictly limited to what was specified; unstated properties are simply not covered.
Bug bounties. Ongoing, adversarial, and open-ended, drawing on many independent researchers over time rather than a fixed window. They complement a point-in-time audit rather than replacing it.

No single technique subsumes the others. A protocol that has only a manual audit has tested a narrow slice of its overall risk surface with one method at one moment.

Common misreadings to avoid

Two failure patterns are worth naming explicitly. The first is treating an audit as binary. Reports are not pass or fail; they are structured findings with severities and a remediation history, and the interesting information is in the detail, not in the existence of a report. The second is confusing marketing with assurance. A protocol advertising that it is audited is making a weaker claim than it sounds, because it says nothing about scope, recency, the reviewer, whether findings were fixed, or whether the deployed code matches what was reviewed. The word audited on a landing page is a prompt to ask questions, not an answer to them.

Audits as one layer

The mature way to think about audits is as one layer in a defence-in-depth stack rather than a pass or fail gate. That stack also includes comprehensive test suites, fuzzing and invariant testing maintained by the team itself, formal verification of critical properties, staged rollouts with value caps, live monitoring and circuit breakers, generous bug bounties, and conservative upgrade and key-management practices. An audited contract with none of these other layers is far less reassuring than the audit alone might suggest.

The single-sentence version: an audit tells you that competent reviewers looked for known problems in a specific version of the code and reported what they found. It does not tell you the contract is safe, that its economics hold, that the keys are secure, or that the version you are using is the version they read. Read it for what it is.

Sources

Note: CamoCrypt is security & education only — no prices, no predictions, no investment advice. Verify every address and contract yourself; we cannot recover lost funds and neither can anyone who contacts you claiming they can.

What smart contract audits do and don’t prove