A smart contract audit is a structured review of the code behind a smart contract or set of contracts, performed by security specialists to identify flaws before they can be exploited. Auditors examine the logic, check how the contracts interact with users and with other protocols, and produce a report listing problems by severity, with recommendations for fixes. Projects usually publish the report so that users and investors can see what was checked.
Audits matter because smart contracts often control large sums and, once deployed on a public blockchain, are difficult or impossible to change. A single error can let an attacker drain funds in minutes, with no bank or court able to reverse the loss. Audits are one part of a wider security practice that includes testing, bug bounty programmes and monitoring, and they cannot guarantee that a contract is safe.
Smart contract audits in plain terms
Think of a building inspection before a new office block opens. The architect has drawn the plans and the builders have finished, but an independent inspector walks through, checks the wiring, the fire exits and the foundations, and writes a list of anything that could cause trouble. The owner fixes the problems before tenants move in.
A smart contract audit does the same for code that will hold other people's money. The inspector cannot promise the building will never have a problem, but a careful inspection catches many of the dangerous ones before anyone is hurt.
How an audit works
- Scoping. The project and auditor agree which contracts and version of the code are covered, and the project supplies documentation explaining what the code is meant to do.
- Automated analysis. Tools scan the code for known risky patterns, and fuzzing tools feed in large numbers of random inputs to look for unexpected behaviour.
- Manual review. Experienced auditors read the code line by line, think like attackers and check whether the design itself is sound.
- Reporting. Findings are graded, typically as critical, high, medium, low or informational, and shared with the team.
- Fix review. The team corrects the issues and the auditor checks the changes, often issuing a final report.
Some audits add formal verification, which uses mathematical methods to prove that the code meets precise specifications.
Common vulnerabilities
- Reentrancy. A contract sends funds before updating its own records, letting a malicious contract call back in and withdraw again. A flaw of this kind was exploited in the 2016 attack on The DAO on Ethereum.
- Access control errors. Functions that should be restricted to administrators can be called by anyone.
- Price manipulation. Contracts that trust a single price source can be fooled, often with a flash loan attack or oracle manipulation.
- Arithmetic and logic mistakes. Rounding errors, wrong assumptions about token behaviour and broken upgrade logic.
- Ordering risks. Transactions visible in the mempool can be exploited through front-running and other forms of maximal extractable value.
Who audits and what it costs
Audits are carried out by specialist security firms, by independent researchers and through public audit contests, in which many reviewers compete for rewards based on what they find. Prices depend on the size and complexity of the code and the reputation of the firm, and leading firms can be booked months ahead. Large protocols often commission several audits from different teams, plus a contest and an ongoing bug bounty. The audits are usually written for contracts in Solidity or Rust, the main languages of Ethereum and Solana.
Limitations and criticism
Audited protocols are still hacked. An audit covers a specific version of code at one point in time; later changes, new integrations or flaws in the overall economic design may fall outside it. Auditors work under time limits and can miss subtle bugs. Some projects publicise an audit while ignoring its findings, or use the word "audited" in marketing for a brief or low-quality review, a pattern seen in some rug pulls. Critics also note potential conflicts of interest, since the project pays the auditor. Because of these limits, many teams now treat security as a continuing process: they launch with caps on how much can be deposited, add emergency pause functions controlled by a multi-sig wallet, monitor live transactions for suspicious patterns and commission fresh reviews whenever the code changes. Users are advised to read the report itself, check whether issues were fixed and look at the protocol's track record, rather than treating an audit badge as proof of safety. Losses from hacking of DeFi protocols have remained large in spite of the growth of the audit industry.