An audit badge is a starting point for due diligence. The useful evidence is the report behind it: what code was reviewed, which assumptions were made, which issues remain open, and whether the deployed contracts match that review.
Here is a practical checklist for developers, project teams and community researchers. It is educational guidance, not an assessment of a particular project.
1. Open the original report
Follow the report link from the auditor's official website or the project's official security documentation. A screenshot of a logo does not establish the report's authenticity. Cross-check the project name, auditor, report date and revision. If the original cannot be located, record that gap instead of treating the badge as confirmation.
2. Identify the exact scope
Look for the repository, commit or release identifier, contract files, dependencies and exclusions. A token contract review does not automatically cover a staking module, bridge, website, backend or operational wallet.
Write down both what was reviewed and what was outside the engagement. This prevents a narrow review from being interpreted as a system-wide security claim.
3. Compare the reviewed code with the deployment
A report about source code is not, by itself, proof that the same code is running on-chain. Check the correct network and deployed addresses. For EVM contracts, investigate verified source, compilation settings, constructor arguments and linked libraries where relevant.
For a proxy, identify its implementation and upgrade authority. The proxy address can stay the same after the implementation changes. Source verification helps inspection; it does not mean the contract has passed a security audit.
4. Read findings individually
Severity labels depend on an auditor's methodology. Read the impact, prerequisites and affected functions rather than comparing totals between firms. One issue that permits unauthorized withdrawals can matter more than many informational recommendations.
Check whether an issue requires a compromised administrator, unusual market conditions or an ordinary public call. These are different threat models.
5. Separate fixed, acknowledged and unresolved issues
An acknowledged issue usually means the team has accepted or recognized it; it does not necessarily mean the code was fixed. Read the report's definitions.
For a resolved issue, look for the remediation commit and evidence of retesting. Also check whether the deployed version includes that fix. Do not silently translate 'acknowledged' into 'safe'.
6. Map privileged roles
Who can mint, pause, upgrade, change fees, move funds or grant permissions? Who controls those accounts now?
OpenZeppelin's access-control documentation explains why ownership, role administration and delayed operations matter. A valid privileged action may still expose users to governance or key-management risk. Record multisig thresholds, timelocks and relevant exceptions instead of assuming that an ownership label describes every permission.
7. Read assumptions and external dependencies
Look for oracle sources, liquidity assumptions, token behavior, bridge verification, external protocols and off-chain components. A contract can behave as specified while an assumed dependency fails.
For example, a lending calculation can be implemented correctly but still depend on an inappropriate price source. Ask what must remain true for the reviewed system to behave safely.
8. Understand which methods were used
Static analysis, AI-assisted scanning, manual review, fuzzing and formal verification can provide different kinds of evidence. Look for the methods actually documented, their scope and limitations.
A scanner output should not be presented as a comprehensive manual audit. Formal verification establishes specified properties within a model and its assumptions; it is not a blanket guarantee about an entire product.
9. Check changes since the report
Compare report dates with releases, implementation upgrades, new integrations and permission changes. A historical audit remains evidence about its reviewed scope, but material changes may need further review.
Also look for an incident response process, monitoring and a vulnerability disclosure or bug bounty channel. These complement a review; they do not replace one.
10. Keep a short evidence record
Use this template when reviewing a project's audit claims:
| Item | Evidence to record |
|---|---|
| Original report | Official URL, date and revision |
| Code scope | Repository, commit, files and exclusions |
| Deployment | Network, addresses and proxy implementation |
| Findings | Open issues and relevant preconditions |
| Remediation | Fix commits, retest results and deployed version |
| Control | Admin roles, multisig, timelock and upgrade paths |
| Dependencies | Oracles, integrations and explicit assumptions |
| Follow-up | Changes since review and monitoring process |
Mark missing evidence as unknown. A zero-issue summary, a familiar logo or a high score is not a substitute for these checks.
References and AEGIXE resources
- Solidity: Security Considerations
- OpenZeppelin Contracts: Access Control
- AEGIXE audit report query
- AEGIXE Web3 security services
Disclosure: Published by AEGIXE. This educational article was prepared with AI assistance and is not a project-specific audit report. An audit reduces uncertainty within its scope; it cannot guarantee that a system is free of vulnerabilities.
Top comments (0)