Crypto Decoded

The Truth About Audited Smart Contracts: What an Audit Can Miss

Learn the truth about audited smart contracts, including how scope, code changes, dependencies and unresolved findings can limit an audit's assurance.

By Oliver Crane · August 3, 2026

Photo by Pexels contributor via Pexels

The word “audited” may sound like a safety certificate. In fact, an audit is a focused review of stated code at a given time.

The truth about audited smart contracts is simple: an audit can offer useful evidence, but it cannot prove that a whole protocol is safe. Reviewers work with a set scope, time period, code version and list of assumptions. They may find serious faults, yet miss bugs in the reviewed code or risks in connected systems. So do not ask only, “Was it audited?” Ask what was reviewed, when it was reviewed and what changed later.

In this article

The Short Version

An audit searches for flaws, but it cannot promise bug-free code.
Its findings apply only to the stated scope, assumptions and code version.
Outside services and later upgrades may create risks beyond the report.
Read the findings, fixes and follow-up review before trusting an audit badge.

What a smart-contract audit actually does

A smart-contract security audit is a time-boxed review intended to identify vulnerabilities; it does not guarantee that the code is bug-free. Auditors first learn what the contracts should do and how the parts work together. They inspect the supplied code and documents for flaws that could break those rules. A useful report states what was checked, what was found and how the project replied.

The work commonly combines automated tests with manual review. Tools may run static analysis, unit tests, integration tests and fuzz tests. Fuzz tests send many varied inputs into code to reveal odd results. These methods can find known fault patterns and point reviewers towards harder issues. Human review is still vital because business rules and links between contracts depend on context.

Careful human review also has limits. Auditors have a fixed amount of time, so they must focus on likely and serious flaws within the agreed scope. A new attack may rely on a rare mix of system state, timing and outside behaviour. Nobody may think of that mix during the review. An audit therefore shows that specialists searched for problems; it does not prove that none remain.

The truth about audited smart contracts starts with scope

An audit’s conclusions are bounded by its scope: excluded files, external contracts and dependencies may still create exploitable risk for the wider system. A report should name the repository, contracts, files or parts that it includes. It should also note major exclusions. If only one part of a protocol was checked, the audit does not cover every linked part. The wider product may fail through code that the auditors did not receive or assess.

Outside systems need close attention. A contract may rely on another protocol, token, bridge or data service. Their behaviour can affect whether the reviewed logic stays safe. For example, an app that uses prices may suffer if an outside source sends poor data, even when the app’s own maths is right. Our guide to what a crypto oracle does explains this separate trust boundary.

Several audit badges do not solve the scope problem by themselves. Different firms may check different parts, commits or stages of a project. Their reports may not give repeated checks of the same system. Read each scope instead of counting logos. Several narrow reviews can still leave gaps between parts or miss a shared dependency.

Assumptions and documents shape the result

The audit’s assumptions and available documentation matter because auditors need an accurate account of intended behaviour to assess business logic and interpret the code. Code may run exactly as written but still apply the wrong economic rule. Auditors therefore need clear plans, tests and notes about the system’s intended actions. Weak or incorrect documents can lead them to test the wrong idea of correct behaviour.

Assumptions may cover trusted roles, token behaviour, data feeds or limits on user actions. An auditor may check a function on the stated basis that a trusted role acts in a set way. That result applies only while the assumption remains true. Readers should find the assumptions in the system overview. They should then ask whether those assumptions still match the live product.

In Plain English

Picture an inspector checking three named rooms in a large building on Tuesday. The inspection can find bad wiring in those rooms. It cannot tell you much about a locked cellar or work done on Wednesday. The result also relies on an accurate building plan. An audit works in the same way: its value depends on what was checked, the information supplied and whether the system later changed.

Why the code version matters

The audit applies to one state of the code. Post-audit changes or upgrades may make the report inapplicable to the deployed version, so the report’s commit hash should be compared with the deployed code where practicable. A commit hash identifies a set state of a code repository. Some reports instead list a hash for each file. A match helps link the report to the code that auditors checked.

A mismatch needs an explanation, not an instant verdict. A later change might alter only a document. It could also be a checked fix or a major logic update. The report and project records should explain which case applies. Without that link, a reader cannot know whether the live contracts contain the reviewed code.

Upgradeable systems add another issue. A proxy or similar design may let the contract logic change after launch. An old report may then describe an earlier version. Readers should check whether upgrades are possible and whether a later version received review. The presence of an upgrade system does not, by itself, prove that the product is safe or unsafe.

How to read findings and fixes

A useful audit report records findings by severity, proposed mitigations and the project’s remediation response; readers should also check whether the auditor reviewed the fixes. Severity labels help readers sort issues. However, the available evidence does not show that every auditor uses the same scale. A “high” issue in one report may not equal a “high” issue in another. Read the impact and attack conditions, not only the label.

Status words also need care. “Fixed” should point to changed code and, if possible, a note that the auditor checked it. “Acknowledged” may mean that the project accepts the issue but made no change. “Mitigated” may depend on a control or assumption instead of removing the flaw. A low-rated issue may also matter when it joins with another weakness.

A fix can create a new bug, so follow-up review is useful. Yet a check of named fixes is not always a fresh audit of the full system. Look for a final report, an addendum or a clear comment from the auditor. It should state what was checked again. Keep a narrow fix review separate from a full new audit.

What an audit can still miss

Complex flaws can survive both tools and human review. A bug may need an unusual series of steps across several contracts. It may depend on market conditions or on an assumption that seemed sound during tests. New attack methods can also appear after the report. These limits are reasons to weigh audit evidence with care, not to dismiss it.

Dependencies can turn a sound local check into a wider failure. Outside contracts, integrations and oracles may act in surprising ways or change later. An audit may inspect an integration when that work falls within its scope. Readers should trace the key dependencies named in the system plan. They should note which ones the report covers.

Market behaviour can matter as much as code behaviour. A contract may rely on an asset keeping a target price. Trouble can follow if that belief fails, even when every function runs as designed. Our guide to a stablecoin depeg shows how a broken peg can affect linked systems. A report may study this risk, but an “audited” label does not tell you whether it did.

An audit can also leave out code, contracts or external services that are not in its stated scope. Those exclusions may still affect the full system. The key point is not to guess what every audit leaves out. Read the report’s own scope and system overview. Then compare them with the parts and dependencies used by the live product.

Do not confuse a code audit with another form of assurance. An attestation deals with a defined statement or body of information. A smart-contract review searches stated software for security flaws. Our comparison of crypto attestation and audit explains why these labels answer different questions. Neither should be stretched beyond the subject and period that was examined.

A practical worked Example

Imagine a lending protocol called Harbour. It publishes an audit dated 1 March. The report covers three lending contracts at repository commit ABC123. It assumes that a named price feed acts as described. The report lists one high issue, two medium issues and several low issues.

The final page says the high issue was fixed and checked. One medium issue was mitigated. The other medium issue was accepted and left open. These labels give the reader a starting point, but not a final answer. The reader still needs to study the impact of each issue and the conditions needed for an attack.

In May, Harbour deploys commit DEF456 and adds a new collateral token. Its site still displays the March audit badge. The old report does not mention the new token or the May code. A reader cannot conclude that DEF456 was audited because an earlier version was checked. A later report, addendum or clear code map would provide better evidence.

Now suppose the new collateral price comes from an outside oracle. Even if the May lending code has no fault, a bad or late price could affect liquidations. The March review gives no direct evidence about an integration added later. This is how scope, assumptions, dependencies and code history can join together. Each fact changes what the audit can tell the reader.

The open medium issue also needs context. A reader should inspect its likely impact and the steps required to exploit it. The project’s reason for accepting it matters too. Any stated safeguard may rely on another assumption remaining true. This review creates a specific view of the evidence instead of a simple safe-or-unsafe label.

What This Means For You

Treat an audit as one useful input when you judge technical risk. First, link the report to the real product. Identify the checked contracts, version, review period and exclusions. Next, read the serious findings and the project’s reply. Give special attention to accepted risks and later code changes.

Ask whether the report answers the question you care about. A review of stated contracts can find faults in that code, but it cannot support claims about excluded parts. Compare any broad security claim with the report’s exact words. A missing finding is not proof that an unchecked area is safe. This approach gives the audit badge no more weight than the report supports.

A decision checklist for reading an audit

Date and period: Note when the review happened and how long it lasted.
Scope: Find the included contracts and files, then note exclusions and dependencies.
Assumptions: Check what auditors accepted about intended behaviour and integrations.
Code identity: Find the commit or file hashes and compare them with live code where practical.
Findings: Read the impact and attack conditions as well as the severity label.
Response: Separate fixed, mitigated, accepted and open issues.
Fix review: Look for a clear record of which changes the auditor checked.
Later changes: Check whether upgrades or new integrations received another review.

This checklist is a way to read a report, not a universal audit standard. The available sources do not set mandatory qualifications or one shared severity system. They also do not say that every fix must receive a full new audit. This article gives general education about technical risk. It does not state UK law or consumer-protection rules.

The balanced conclusion

An audit can reveal flaws, improve code and record known risks. It has most value when the scope is clear and the reviewed code matches the live code. Clear assumptions and a visible record of fixes also help. Yet an audit remains a time-limited review by people and tools. The truth about audited smart contracts is not that audits promise safety or that they have no value.

Read “audited” as the start of a question. Ask which code, dependencies, period and fixes the report covers. Check what changed after the review and what stayed outside it. This protects the real value of an audit. It also avoids trust that the evidence cannot support.