Saying a protocol is "audited" is not enough. You still need to know whether those reports cover the release you are shipping, whether anything material changed after the audit, and whether the live contracts match the source people are asked to trust.
Release Audits are for that check. They do not hunt for new bugs from scratch. They review the audit evidence a project already has and turn it into a scored verification page you can share.
What you provide
- Repository URL and target release commit
- Third-party audit report PDFs
- Optional deployed contract addresses
What Guardix checks
- Auditor credibility and what each report actually covered
- Whether the release commit drifted from the audited code, and whether the diff looks security-relevant
- Finding quality - how well-supported the reported issues are, including overlap across firms
- Owner powers and other privileged controls in the release
- Live on-chain state when you add addresses: bytecode match, verified source, proxies, ownership
What you get
A scorecard with a clear verdict, the evidence behind it, and the gaps that still need manual review. If the reports, source, and deployment do not line up, the scorecard says so.
When you are ready, share the same page with a public link. Partners, users, or investors can read the scorecard instead of reconstructing the story from a pile of PDFs.
Start a run from Release Audits, or open the sample scorecard first. You need a Guardix account to start a run; finished scorecards stay shareable.