Smart contract audits: method and limits

“Audited by experts” appears on almost every crypto project’s website. The phrase conveys the idea that the code was approved and is safe. Ethereum’s developer documentation says the opposite: audits “won’t catch every bug” and should not be treated as a silver bullet (ethereum.org, Smart contract security).

This article explains how a smart contract audit usually works, which techniques it uses and what its limits are. The goal is to help you read an audit report with a critical eye. What a smart contract is and why an error in one is hard to undo is covered in What smart contracts are and how they work.

What a smart contract audit is

An audit is an independent review of the code of one or more smart contracts, done before or after deployment to the blockchain, to find security flaws and logic errors. The result is a report: a list of findings, each with a description, severity and recommended fix.

Review matters more here than in ordinary software for three reasons, all described in the ethereum.org documentation:

• the code is public: anyone, including an attacker, can study it;
• the code holds value: a contract can control millions in tokens, and an exploited flaw transfers that value immediately;
• the code is, by default, immutable: once deployed, it cannot simply be fixed. Upgrade patterns exist, but they bring risks of their own, as we will see.

The same page estimates that the value lost to security defects in smart contracts “easily exceeds $1 billion”.

How an audit is usually done

There is no single standard governing the work. The description below, in the editorial team’s assessment, brings together the most common steps and the techniques described in the technical documentation.

1. Defining the scope

Everything starts with defining what will be reviewed: which files, in which version. In serious projects, the version is identified by a commit hash, a unique code that points to an exact state of the repository. The scope also says what will not be reviewed, such as interfaces, deployment scripts or third-party contracts. This detail becomes decisive later, when reading the report.

2. Understanding what the code should do

An auditor cannot point out a logic error without knowing what the intention was. That is why they ask for documentation, diagrams and, ideally, a specification: the list of what the system must and must not allow. Example: “no user can withdraw more than they deposited”. At this stage a threat model is also built, that is, who could attack and how.

3. Manual review

This is the core of the audit. People read the code line by line looking for known failure patterns and, above all, errors specific to that project, which no tool knows about. Public catalogs help organize this search:

• the OWASP Smart Contract Top 10, in its 2025 edition, lists the categories most associated with incidents: access control flaws, price oracle manipulation, logic errors, lack of input validation, reentrancy, unchecked external calls, flash loan attacks, integer overflow, insecure randomness and denial of service. According to OWASP, the list was built from 149 incidents that added up to more than US$ 1.42 billion in losses;
• the SWC Registry classifies weaknesses with codes, such as SWC-107 for reentrancy (when an external contract calls back into the function before it finishes updating balances). The site itself warns that it has not been actively maintained since 2020, a reminder that catalogs age.

4. Static analysis

Static analysis examines the code without running it, using representations such as control flow. The best-known example is Slither, an open-source tool for Solidity and Vyper. The repository lists around a hundred detectors, classified by impact, and says the analysis takes on average less than one second per contract. The tool finds patterns quickly, but each alert needs to be checked by a person: some of them are not real problems, and business logic errors go unnoticed.

5. Testing and fuzzing

The ethereum.org documentation states that unit tests alone are “minimally effective” for security, and recommends combining them with property-based testing. In this technique, you write invariants, that is, rules that must always hold, and a tool tries to break them.

Fuzzing is the automated version of this: generating thousands of random sequences of calls and checking whether any of them violates an invariant. Echidna, for example, looks for call sequences that falsify properties written by the developer. If it finds one, it shows the path. If it does not, that increases confidence, but it is not proof that the flaw does not exist.

6. Formal verification

Formal verification uses mathematical methods to prove that the code meets a formal specification. According to ethereum.org’s page on the topic, it can prove the absence of errors relative to that specification, something tests cannot do. It is also expensive, requires a high level of expertise and does not apply to everything: some properties may be impossible to prove, and the tools run into the explosion of possible states. That is why it is usually used on critical parts, not the whole system.

7. Report, fixes and re-check

Findings are assigned a severity, usually from critical to informational. The project team fixes them, or justifies why it will not, and the auditors check the fixes. Good reports record the final status of each item: fixed, partially fixed or acknowledged without a fix.

What an audit does not guarantee

The limits below are not the flaws of any particular auditor. They are characteristics of the method itself.

It applies to one version, on one date. If the code changes afterwards, the new part has not been audited. In upgradeable contracts, which use an intermediary contract (proxy) to swap out the logic, the code in production may no longer be what was reviewed. ethereum.org also points out that when a single owner controls administrative functions, there is a centralization risk: whoever holds the key can change rules or pause the system. How this shows up in tokenized assets is covered in Smart contracts applied to real-world assets.

It checks the code against an intention, and the intention may be wrong. ethereum.org’s page on formal verification warns that weak specifications lead to the mistaken conclusion that the contract is free of flaws. The same applies to manual review: if no one anticipated a scenario, it was not tested.

It may not cover the economic environment. Oracle price manipulation and flash loan attacks are at the top of the OWASP Top 10. In these cases, every line of code can do exactly what it promises, and the system still loses money, because the economic rules allow abuse. Assessing this requires looking at the protocol together with the market it operates in, as explained in DeFi: what decentralized finance is and Oracles: how a physical asset reaches the blockchain.

The compiler can also be wrong. The code that runs on the blockchain is the result of compilation, not the text the auditor read. The Solidity documentation maintains a list of known compiler bugs, by version, so that tools can check whether the version used is suspect. In Vyper, another contract language, a security advisory from August 2023, rated critical, reported that versions 0.2.15, 0.2.16 and 0.3.0 incorrectly allocated reentrancy locks. Source code that looked protected might not have been.

It usually does not include what is off-chain. Administrators’ private keys, servers, web interfaces, bridge validators and operational processes are generally out of scope. In bridges, for example, there have been large losses caused by compromised keys, with no flaw in the code, as shown in Blockchain bridges: how they work and where they fail. Scams that deceive the user, such as wallet phishing, are not a matter for code audits either.

It does not assess whether the project is a good business. A security audit does not analyze the economic model, token distribution, legal situation or the team’s capability. For that, see Tokenomics: how to analyze it before assessing a project and How to analyze the risks of a tokenization project.

Because of these limits, the ethereum.org documentation treats the audit as one layer among several: well-designed tests, automated analysis, bug bounty programs, with rewards proportional to the value at risk, and monitoring of contract events after deployment, with alerts for unusual activity.

How to read an audit report

If a project says it has been audited, look for the full report, not just the badge. Useful questions:

• What is the date and which version was reviewed? Look for the commit hash and compare it with the verified code on the block explorer. If the project does not allow this comparison, the audit says little about what is in use.
• What was in scope? A report may cover just one contract in a system of ten.
• Which findings remained open? “Acknowledged” items without a fix are still there. Read the justification.
• Can the contract be changed? By whom? Check whether there is a proxy, who holds the admin keys, and whether there is a multisignature requirement and a waiting period before changes.
• Was there more than one review, and is there a bug bounty program? Independent reviews and ongoing incentives to discover flaws reduce the risk, but do not eliminate it.
• Is the report public and verifiable? Be wary of badges with no link to the document or of reports that do not identify the reviewed code.

The editorial team does not recommend audit firms. The quality of a review depends on the scope, the time dedicated and the documentation received, and that shows in the report, not in the brand.

Takeaways

• An audit is an independent review of a specific version of the code, with a defined scope. It combines human reading, static analysis, fuzzing and sometimes formal verification.
• It reduces risk; it does not eliminate it. Later changes, admin powers, economic attacks, compiler bugs and off-chain components can slip through.
• “Audited” is not a seal of security or of investment quality. Read the report: date, version, scope, open findings and who can change the contract.