Most launch pages say a protocol has been audited. That is useful, but it is not the same as knowing whether the audited code is the code being shipped, whether the reports covered the risky surfaces, or whether the deployed contracts match the source users are asked to trust.
Release audits are built for that gap. Instead of looking for new bugs from scratch, Guardix evaluates the evidence a project already has: audit reports, repository state, target commit, scope, owner powers, finding quality, and optional live deployment addresses.
The question is not "was there an audit?" The question is "does the audit evidence still justify trust in this release?"
Three things have to line up
A release can drift in three different directions. The report can describe an old commit. The repository can change after the audit. The deployed bytecode can differ from both. A useful assurance workflow has to compare all three, not just summarize a PDF.
- Audit reports — auditor identity, audited commit, scope, finding list, remediation status, and evidence gaps.
- Source commit — what changed since the audited version, whether the changes are security-relevant, and which files were in scope.
- Deployment state — contract addresses, verified source, proxy slots, owner powers, and bytecode match when deployment evidence is available.
The pipeline
The release verification pipeline is split into six stages so the final scorecard is grounded in typed artifacts rather than one long model answer.
| Stage | What it checks |
|---|---|
| Report extraction | Every finding, scope note, auditor claim, and remediation status in each uploaded report. |
| Audited-commit diff | Whether the target release changed after the audited commit, and whether those changes touch security-relevant files. |
| Repository assurance | Scope coverage, owner powers, architecture clarity, entry points, tests, docs, and code-quality signals. |
| Finding quality | How well-supported each reported finding is, including duplicate findings and independent auditor overlap. |
| Deployment verification | On-chain bytecode, source verification, proxy metadata, owner() checks, and code hashes when addresses are provided. |
| Synthesis | A scored assessment, evidence ledger, key risks, recommended actions, and public summary. |
What the scorecard looks like
The preview scorecard on guardix.dev uses a real pipeline output from a 1inch Limit Order Protocol / Pessimistic run. The result is intentionally not a green badge: 60/100, Needs manual review, with 4/8 scope coverage, 5 evidence gaps, and 4 key risks.
That is the point. A release audit should not turn incomplete evidence into confidence. It should make the uncertainty visible enough that a team, investor, partner, or user can decide what still needs manual review before the launch is treated as reviewed.
Shareable by default
The output is a public verification page. Teams can review it internally, then share the same evidence-backed scorecard with users or stakeholders instead of asking them to read several audit PDFs and reconstruct the release story themselves.
Release audits do not replace a human auditor. They make the audit evidence around a release inspectable, current, and hard to hand-wave.