Web3··1 min read
An audit is not a guarantee. Here is what auditors look for, what is out of scope, and how to get real value from one.
Once a smart contract is deployed, mistakes are expensive and often permanent. That is why audits exist. But "audited" on a landing page can mean many different things, and founders are sometimes surprised by what was and was not checked.
What an audit usually covers
- Known vulnerability patterns such as re-entrancy, unchecked external calls and integer edge cases.
- Access control: who can call admin functions, upgrade the contract or move funds.
- Whether the code does what the spec says it does.
- Gas usage and obvious inefficiencies.
What it usually does not
- Your tokenomics or economic design, unless you ask for it specifically.
- Off-chain systems: your backend, front end, keys and deployment scripts.
- Code changed after the audit was finished.
How to get more out of it
Freeze the code before the audit starts. Write a clear spec of what each contract is supposed to do. Ship a solid test suite with it, because auditors spend less time on basics and more on the hard parts when tests already exist.
Then treat the report as a to-do list, not a badge. Fix the findings, have the fixes reviewed, and keep the report public so users can see what was found and resolved.
An audit lowers risk. It does not remove it.
Written by Agentive Team