Already audited and deployed
Ask your audit firm to push the audit, or request a listing.
For protocols
Show users the audit you already paid for.
Users see your audit at the moment they sign, matched to the code that is live, or they see that no audit is on record.
What your users see.
The same panel, with and without a released audit.
Audited and matching
Shortened example. The real panel also shows call counts and the checked block.
No released audit
Shortened example. The real panel also shows call counts and the checked block.
Two paths.
Need an audit
Pre-audit makes the boundary testable, core audit reviews each risk surface at the right depth, post-audit proves remediation, and the scorer explains the approved evidence.
After the audit.
Fixes reach production
Each step is a proof state: remediation, independent decision, reproducible build, deployment match, monitoring, then stale when material conditions change.
Finding
Accepted risk has a bounded owner
The record identifies the exact finding, affected scope, evidence, validator decision, and responsible review boundary.
Remediation
The fixed commit becomes the new candidate
The protocol submits remediation commits and explains intended changes without replacing independent review.
Decision
An independent reviewer decides the outcome
Accepted, incomplete, regressed, and residual-risk states stay separate so a partial fix cannot appear complete.
Build
The reviewed source must reproduce
Compiler settings, linked libraries, and build inputs are recorded before any deployment-match claim is made.
Deployment
The production implementation is compared
Runtime bytecode, proxy targets, libraries, and initialization state are checked as separate evidence surfaces.
Monitoring
Published proof receives a freshness state
Monitors watch registered invariants and the code or authority identities that could invalidate the reviewed state.
Invalidation
Material changes make old proof visibly stale
A changed implementation, upgrade path, authority, or required invariant moves the public record out of the matched state.
Bring an existing audit
Keep prior security work, but separate historical evidence from what can still be reproduced and matched to production.
Yes. The report becomes historical evidence. Proof of Audits then checks the reviewed commit, remediation trail, build reproducibility, current deployment, and material differences before deciding what still applies.
See what determines the funding plan.
Use the public preview for orientation. Final reviewer counts, deposit, schedule, and exclusions require repository evidence and approval.
Questions protocol teams ask before onboarding.
Does a Trust Passport guarantee that a protocol is safe?
No. It organizes current, source-bounded review evidence and makes missing or stale proof visible. It does not eliminate protocol, market, governance, or operational risk.
Can we import an audit from another firm or contest?
Yes. The report becomes historical evidence. Proof of Audits then checks the reviewed commit, remediation trail, build reproducibility, current deployment, and material differences before deciding what still applies.
What makes the Trust Score useful?
The score is paired with evidence status, blockers, confidence, review scope, code identity, authorities, and freshness. The number is not presented as a standalone safety verdict.
What happens after an upgrade?
Material code or authority changes can invalidate the matched state. The public record shows that the reviewed release is stale until the new version is checked and approved.
How is reviewer accountability decided?
Affected code and exploit paths are mapped back to documented review ownership. An independent process then applies the published accountability policy. Assignment alone does not automatically prove negligence.