The quick version. A smart contract audit is a time-boxed review of specified code, at a specified version, by people hunting for known classes of vulnerability. A serious one genuinely reduces risk and is worth reading. It is not a guarantee, it covers only what was in scope, it says nothing about code changed afterwards, and it cannot tell you what the team intends to do with the powers it kept.
What auditors actually do
An audit starts with a scope. The project hands over a defined set of contract files at a defined commit, plus documentation describing what the code is meant to do. Everything outside that list is simply not looked at.
Reviewers then read the code against that intended behaviour, hunting for the failure patterns the field already knows about. Reentrancy, access-control mistakes, arithmetic and rounding errors, unchecked calls into other contracts, price sources that can be pushed around, initialisation and upgrade flaws, and assumptions that quietly break when a token behaves unusually.
Good teams supplement reading with tooling. Automated analysers catch mechanical mistakes, fuzzing throws unexpected inputs at the code to break stated invariants, and formal methods can prove narrow properties. None of that covers the whole surface, and the interesting bugs usually come from a human noticing that two components disagree about something.
What comes out is an expert opinion produced under time and scope constraints. That is worth a great deal more than nothing, and considerably less than a proof of safety.
How a report is put together
Almost every reputable report follows the same shape, and knowing it lets you read the document in ten minutes rather than skipping it.
The scope section lists the files reviewed, the commit hash, and often the chains targeted. The methodology section says what techniques were applied. The findings section is the substance: each issue gets a severity, a description, a recommendation, and a status showing what the project did about it.
Many reports also carry a section on privileged roles or centralisation risk, describing which addresses can pause the system, mint, upgrade the code or move funds. Read that section first. It usually tells you more about your real exposure than the vulnerability list does.
The last page is a disclaimer saying the review is not a warranty of security. Auditors are consistently more honest about their limits than the marketing built on their work.
The four things an audit does not mean
It is not a guarantee
Reviewers hunt for known classes of bug within a fixed budget. Novel logic errors, economic designs that fail only under particular conditions, and interactions with contracts nobody thought to model can all survive a careful review. Audited code has failed before. Describing something as audited is a statement about process, not outcome.
It covers only what was in scope
A report on a token contract says nothing about the staking contract holding the deposits, the front end that decides which contract your browser talks to, the off-chain keeper triggering actions, or the price oracle everything depends on. Scope is where most of the misreading happens.
It applies to the code that was reviewed
Findings are pinned to a commit. If the code changed afterwards, whether to fix findings or to add features, the deployed contracts are not the reviewed contracts. Upgradeable systems sharpen this, because the implementation behind an address can be swapped for something nobody reviewed.
It says nothing about intentions
An audit checks whether code does what it says. It cannot tell you whether the people holding the admin keys will behave well. A contract can be flawlessly written and still allow whoever controls it to drain deposits; a review that documents that power has done its job by telling you it exists.
How to read one properly
Start by finding the actual document rather than the claim about it. Reports normally live on the auditor’s own site or public repository. If a project links only to a screenshot or a logo, with no counterpart from the auditor, treat that as unverified.
Then check that the scope matches what you would be using. Compare the contract addresses or commit hash in the report against the verified source on a block explorer. If the deployed contract’s source is not verified at all, nobody outside the team can confirm what is running.
Work through the findings by severity and, more importantly, by resolution. “Fixed” with a follow-up commit is a real outcome. “Acknowledged” means the project read the finding and chose to live with it, which is sometimes reasonable and sometimes the most revealing line in the document.
Safety: Treat an audit as one input, never as permission to skip your own checks. Before committing funds to any contract, confirm you reached the site by typing the address yourself, read what token approvals it is asking for, and start with an amount whose loss would not change your week. Our guide to token approvals explains why that middle point matters so much.
Why a badge on a landing page proves nothing
An audit logo is an image file. Adding one to a website takes seconds, requires no permission, and creates an impression of scrutiny that may have no document behind it.
Even when a report exists, the badge flattens all the detail that mattered. It does not tell you the scope, the severity of what was found, whether anything was fixed, or whether the reviewed version is the one you would interact with. Multiple logos are not multiple guarantees either, since several shallow reviews of the same narrow contract add little.
The phrase “audit in progress” deserves particular scepticism, because it turns an unfinished process into a trust signal. So does a review by a firm with no published body of work.
Where audits fit into your own checks
An audit is evidence that a project spent money on scrutiny and published the results, which is a meaningful signal about seriousness. It sits alongside the things you can verify yourself: who controls the upgrade keys, whether there is a timelock, and whether the smart contract source is verified.
The habit that helps most is treating every claim as something to confirm rather than accept, which is the method we set out in how to verify a crypto claim. Our lesson on evaluating a crypto project covers the wider picture, and the piece on why bridges keep getting hacked shows how reviewed systems still fail when one component is weaker than the rest.
Key takeaways
- An audit is a scoped, time-boxed expert review of specified code at a specified commit, not a warranty.
- The scope and privileged-roles sections usually tell you more about your exposure than the headline severity count.
- Findings marked acknowledged rather than fixed are the ones worth reading closely.
- Deployed code can differ from reviewed code, especially in upgradeable systems, so check the addresses and verified source yourself.
Frequently asked questions
If a protocol is audited, is my money safe?
No. An audit lowers the chance of a known class of bug surviving into production, which is worthwhile, but it cannot rule out novel flaws, economic failures or misuse of admin powers. Audited protocols have been exploited. Read the report to see what was checked and what was left out, then decide how much exposure suits you.
What does it mean when a finding is acknowledged rather than fixed?
It means the reviewers raised an issue and the project decided not to change the code. Sometimes that is reasonable, because the fix would cost more than the risk or the behaviour is intentional. Sometimes it means a real weakness is still there by choice. Either way the residual risk transfers to you, so read the stated reasoning carefully.
How do I check the deployed contract matches the audited code?
Look up the contract address on a block explorer for that network and see whether the source code is verified there. Compare it against the commit or addresses named in the report’s scope section. If the contract is upgradeable, find out who can change the implementation and whether a delay applies, since that governs how much the review still tells you.
Sources
Educational content, not financial advice. Never share your seed phrase or private keys with anyone — including anyone claiming to be CoinCrafty.
Last updated Jul 25, 2026
