Checking a protocol's audit status
- Author
- CRYPTO PORT Editorial
- Published
- Updated
- Reading time
- 6 min
In short
An audit is a record that outside specialists examined a particular version of the code — not a certificate that no vulnerability exists. What to check is not the 'audited' badge but who looked, when, over what scope, how the findings were handled, and whether the code has changed since. Audited protocols have still been drained.
Key points
- The badge alone carries no information — go to the report itself
- Check whether the audited version matches the code currently deployed
- Read whether findings were fixed, or left open
- Audited protocols have been attacked many times. It is not a guarantee
Definition
Checking, as a user, what a third-party security firm found when it examined a protocol's smart contract code — and when that examination happened and what it covered.
First, be precise about what an audit does. A security firm reads the code it was asked to read and reports known vulnerability patterns and design problems. The engagement has a deadline and a defined scope. An audit is therefore a list of what was found, not evidence that nothing is there. Marketing blurs this constantly, so fix the distinction before anything else.
Practically, start from the project's own site or documentation and look for a link to the report itself. If no report is published, or only the auditor's name appears, then there is very little you can actually verify. Audit firms often publish their own list of engagements, so cross-checking tells you whether the audit even exists.
Once you have the report, only a few things matter: the date, the repository and commit that was examined, the declared scope, and the list of findings with their resolution status. Date and version matter most. If the code changed substantially after the audit, what was examined and what you are about to deposit into are two different things.
There is a way to read the findings too. A high-severity item marked resolved means that issue was addressed. An item marked acknowledged but not fixed deserves your attention: read the stated reason and the impact. Sometimes it is a deliberate design trade-off — but the person carrying that trade-off's risk is you.
Finally, line up the other evidence: whether a bug bounty exists and how substantial it is, how long the protocol has run and how much it holds, and the quality of any post-mortems after past incidents. These show how the operators deal with problems. None of it adds up to proof of safety. Prominent, audited protocols have been drained more than once. Checking widens the basis for a judgement; it does not remove the risk.
Watch out for
- · Audited protocols have lost their entire deposits. An audit guarantees nothing
- · If the code changed after the audit, the report does not describe what is running now. Always check the date and the version
- · Fraudulent projects display the names and logos of audit firms that never engaged with them. Cross-check against the firm's own published record
Frequently asked questions
Is a protocol with multiple audits safe?
More audits mean more of the code was examined, but the count is not a safety score. Protocols audited several times have still been attacked. Reading whether the most recent audit covers the current code, and whether its findings were resolved, tells you more than counting.