A protocol announces that its contracts have been audited. A launch page shows a badge with a security firm's logo. Someone online calls the code fully audited, as if that settles the matter. Each of those is a claim about a review that happened somewhere else, on some version of the code, at some point in time.
An audit is a real and useful thing. It is also narrower than the word suggests. Read it as proof that a contract is safe, and you are reading more into it than the report itself claims.
This piece stays vendor-neutral on purpose. It explains what a smart contract audit is, how one usually runs, how to read the report, and where its coverage ends. Once you know those edges, you can treat an audit as evidence you weigh rather than a label you accept.
Key Takeaways
- A smart contract audit is an outside review of a contract's code, looking for flaws before or after it goes live.
- An audit covers a defined scope and a specific version of the code, and nothing outside it.
- A report lists findings and whether each one was fixed; the findings matter more than the badge.
- An audit does not cover later code changes, the people holding admin keys, or whether a platform can pay what it owes.
- You can rely on a report only once you know it matches the code deployed at the address you use.
What a Smart Contract Audit Is
A smart contract is a program that lives at its own address on a blockchain. Once deployed, it runs exactly as written. Anyone can call it, and in most designs nobody can stop it from doing what its code says.
A smart contract audit is a structured review of that code by people outside the team that wrote it. The reviewers read the contracts, test how they behave and look for ways the code could be pushed into doing something its authors did not intend: moving funds to the wrong place, locking them, or letting the wrong party change the rules.
The result is a written report. It lists what was reviewed, what was found and how serious each finding is. It also records what the team did about each one. The report is the audit, not the badge. A logo on a website only tells you that someone says a review took place. The report tells you what it covered.
Why Smart Contracts Get Audited at All
Ordinary software can be patched after release. A bug in a web app can be fixed quietly in the next version, on servers that belong to the company that wrote it. Smart contracts work differently, and that difference is the whole reason audits exist.
First, deployed code is hard to change. A contract can be written so that it cannot be edited at all after deployment. It can also be built to be upgradeable, but only through a specific mechanism that itself needs scrutiny. Either way, a mistake can sit in production with real value attached to it.
Second, the code is public. Anyone can read a deployed contract, including people looking for a way to exploit it. A flaw is not hidden just because nobody has talked about it yet. Public means readable, by everyone.
Third, a contract can hold or move funds directly. When the code is the custodian, a bug is not an inconvenience. It can be a loss. That mix of permanence, public code and money at stake is why teams pay for an outside review before they ask anyone to deposit.
How an Audit Usually Works
The details differ from one review to the next, but the stages below describe the usual shape. Knowing it helps you read a report, because each stage leaves a trace in the document.
- Scope. The team and the reviewers agree on exactly which contracts, and which version of them, will be reviewed. Anything outside that list is outside the audit.
- Manual review. Reviewers read the code line by line, compare it with the documentation and ask what happens at the edges: unusual inputs, unexpected call sequences, calls from other contracts.
- Automated analysis. Tools scan for known patterns of bugs and test the code against generated inputs. They are fast at what they look for, and blind to what they were not built to look for.
- Findings. Each issue is written up with a description, a severity rating and, usually, a suggested fix.
- Fixes and re-check. The team fixes some or all of the findings, and the reviewers check whether the fixes work. Issues the team chose not to fix are marked as acknowledged rather than resolved.
- Report. The final document records the scope, the findings and their status at the end of the engagement.
Notice what that sequence implies. An audit is a snapshot of one version of the code, reviewed for a limited time, by a limited group of people. It is careful work. It is not a guarantee.
How to Read an Audit Report
A report can run long, but you do not need every line to learn the important things. Start with the parts that tell you what the audit covered and how it ended.
Scope and version
Find the list of files or contracts that were reviewed and the code version they refer to, usually identified by a commit hash from the team's code repository. If a contract you care about is not on that list, the report says nothing about it. Out of scope means unreviewed.
Findings and their severity
Findings are usually sorted by severity, with labels such as critical, high, medium, low or informational. The label is the reviewer's own judgment. Labels are a summary. Read the description of each serious finding, not just its label.
Status of each finding
This part is easy to skip, and it should not be. Each finding should show whether it was fixed, partly fixed or acknowledged. An acknowledged finding is one the team knows about and decided not to change. That can be a reasonable call. Acknowledged is not the same as fixed. The report tells you which is which, if you look.
Date and reviewers
Note when the review ended and who carried it out. Dates matter here. A report on code that has changed since describes a contract that may no longer exist in that form.
| Part of the report | What it tells you | What it does not tell you |
|---|---|---|
| Scope | Which contracts and which version were reviewed | Anything outside that list |
| Findings | What the reviewers found and how serious they rated it | What they did not find |
| Status | Whether each issue was fixed or only acknowledged | Whether a fix introduced a new issue |
| Date | When the review ended | Whether the code changed afterwards |
What an Audit Does Not Prove
An audit is evidence about code. Much of what can go wrong around a smart contract is not in the code at all, or not in the part of the code that was reviewed.
It does not prove the code is free of bugs. Reviewers can only report what they found in the time they had. A clean report means no serious issue was found in scope, which is a weaker statement than no serious issue exists.
It does not cover later changes. If the team upgrades a contract or deploys a new version, the old report describes the old code. Whether the new code was reviewed is a separate question with its own answer. Ask it separately.
It does not cover the people with special powers. A contract can include admin functions: pausing it, upgrading it, changing parameters, moving funds in an emergency. An audit can tell you these functions exist. It cannot tell you how carefully the keys that control them are held, or how the people holding them will act.
It does not cover the outside world. A contract can depend on price feeds, on other protocols or on an off-chain system that feeds it data. If one of those inputs is wrong, carefully reviewed code can still do the wrong thing.
It does not prove solvency. Whether a platform holds enough to cover what it owes is a balance-sheet question, not a code question. Code cannot answer it. That gap is the one explained in our piece on what a proof of reserves can and cannot show.
And it does not tell you who you are dealing with. An audit reviews code, not intentions. A team can commission a genuine review and still make choices later that the review never saw.
Matching the Report to the Code You Actually Use
A report is only useful if it describes the contract you are about to interact with. That link is not automatic, and it is the step that is easiest to leave out.
Start with the address. A contract you use lives at a specific address on a specific chain. The report should name the contracts it reviewed, and ideally the deployed addresses or the exact code version that went live.
Then check the deployed code. On a block explorer, a contract can show source code marked as verified, meaning the published source matches the code at that address. Verified is not audited. Our guide to reading on-chain data with a block explorer explains what that label does and does not mean. What it gives you is readable code you can compare with the version named in the report.
Finally, check for upgradeability. A contract can sit behind a proxy: the address you use stays the same while the logic behind it can be swapped. In that setup, the question is not only whether the current logic was audited. It is also who can swap it, and under what conditions.
None of this requires reading code yourself. It requires treating the audit claim as the start of your check, not the end of it.
Why This Matters When You Trade With a Prop Firm
When a platform holds money through smart contracts, the code is part of the deal you are making. You are trusting it with funds, or relying on it to route them, alongside whatever the platform tells you in its terms.
That does not mean you need to read the contracts. It means you should know which contracts matter, whether anyone outside the team reviewed them, and whether that review still matches what is deployed today. An audit claim without a report is just a claim. A report without a matching address is a document about something else. Ask for both.
That list is where the questions in this article become practical. The transparency and on-chain proofs documentation names each contract with a short description of its role.
Conclusion
An audit does not make a contract safe. It puts part of the risk on the record. A good report tells you which code was reviewed, what was wrong with it and what the team did about each problem. That is valuable, and it is narrower than the badge suggests.
The real decision is how much weight to give it. Give it weight for the code it covered, at the version it names, if that version is what runs today. Give it none for upgrades it never saw, keys it never assessed and balances it never counted. Ask for the report before you deposit, not after something breaks.
FAQ
Who pays for a smart contract audit, and does that matter?
In the usual setup, the team that wrote the code hires and pays the reviewers. That is not a scandal; it is how the work gets paid for. It does mean the report is a commissioned document. Read it for its substance: the scope, the findings and their status. Those are harder to dress up than a summary sentence or a logo.
What is a bug bounty, and how is it different from an audit?
A bug bounty is a standing offer to pay outside researchers who report a flaw responsibly. An audit is a single engagement with a defined scope and an end date. A bounty keeps running after launch and covers the deployed code as it is now. The two complement each other; neither replaces the other.
Can the same contract be audited more than once?
Yes, and for code that holds a lot of value that is a sensible choice. Different reviewers bring different methods and can catch different things. A new review is also needed whenever the code changes in a meaningful way. When you find more than one report, check which one matches the version deployed today.
Where should I look for an audit report?
Start with the project's own documentation; that is where a team would put the link. A reviewer may also publish the report on its own site. If you can only find a badge or a sentence saying the code is audited, ask for the report itself. A real review leaves a document behind.
What does formal verification add to an audit?
Formal verification uses mathematical methods to prove that code meets a written specification for specific properties, such as a balance that can never go negative. It is strong for exactly the properties it checks. It says nothing about properties nobody wrote down, and the proof is only as good as the specification behind it.
