Category guide · Web3 security
Web3 auditing: how smart contract audits work (and what they miss)
How Web3 audits and contests work, what they miss after deploy, and how Proof of Audits turns findings into living proof: T4–T1 core, post-audit, scorer, and Trust Passport.
Last updated: 2026-07-12
Take action (product-led)
“Web3 auditing” is mid-funnel when you are choosing how to buy review or prove it after launch. Skip the essay — enter the product path that matches your job:
- Live protocol + existing audits → External Deployed Trust Passport review
- Need structured pre/core audit pipeline → protocol onboarding
- PDF report vs living passport → decision comparison
- You are an auditor → apply for routing eligibility
What is Web3 auditing?
Web3 auditing is the structured security review of blockchain applications — especially smart contracts, bridges, oracles, and protocol economics — so critical bugs can be found and fixed before (and after) capital is live. A typical engagement scopes code at a commit, maps trust assumptions, hunts for exploits, and delivers findings by severity.
When people say “get a smart contract audit,” they usually mean this process: contest platforms, private firms, or specialists reviewing Solidity, Rust, Cairo, or related stacks. Proof of Audits does not replace that work; it makes the evidence durable, matchable to live code, and inspectable by the market.
What a solid Web3 audit usually includes
- Locked source snapshot and explicit in-scope / out-of-scope files
- Threat model: access control, reentrancy, oracle risk, economic attacks
- Manual review plus tooling (static analysis, fuzzing, formal methods where useful)
- Severity-ranked findings and recommended fixes
- Fix review or re-audit of patches when findings are closed
- Written report tied to a commit hash — not just a logo
Where classic audits stop (and risk continues)
| After the report… | What can break trust |
|---|---|
| Proxy upgrade / new implementation | Live code no longer matches audited commit |
| Key compromise or signer change | Authority path differs from what was reviewed |
| Partial scope | User-critical functions never reviewed |
| Unfixed or partially fixed issues | Known residual risk still live |
| No deployment verification | Users trust a PDF, not the bytecode they call |
Audited ≠ matched to live code
Web3 auditing options compared
| Approach | Strength | Limit |
|---|---|---|
| Contest (e.g. public competitive audits) | Breadth and speed of eyes | Variable depth; still a snapshot |
| Private firm / retainer | Deep specialist time | Cost; report can still go stale post-deploy |
| Bug bounty | Ongoing incentives after launch | Not a substitute for pre-launch scope review |
| Proof of Audits layer | Match live code, map authority, publish Trust Passport | Not a replacement for skilled code review itself |
How Proof of Audits fits into Web3 auditing
Proof of Audits is built for the full trust path around audits:
- Pre-audit readiness — cleaner scope before contest or firm spend
- Routed reviewers by skill and reputation
- Post-audit fix verification
- Deployment / bytecode match for live protocols
- Trust Passport investors and users can open
- Wallet-time signals closer to the signature
Checklist: before you trust an “audited” protocol
- Which commit and files were in scope?
- Does live bytecode still match that commit?
- Are upgrade / pause / oracle roles verified and multi-controlled?
- What findings remain open?
- Is there a public proof page — or only a logo?
Start with the investor Trust Index or submit a live protocol for External Deployed review.
FAQ — Web3 auditing
What is Web3 auditing?
Web3 auditing is the security review of smart contracts, protocols, and related off-chain components before and after deployment. Reviewers look for logic bugs, access-control flaws, economic attacks, and integration risks so teams can fix issues before users put capital at risk.
How is a Web3 audit different from a Web2 security audit?
Web3 audits focus on immutable or upgradeable on-chain code, economic incentives, oracle and bridge trust, and irreversible fund loss. Unlike many Web2 apps, a single bug can drain TVL without a simple rollback, so proof of what was reviewed — and whether live code still matches — matters more.
Why do audited protocols still get hacked?
Audits cover a snapshot and scope. Live code can change via proxies, new modules, or key compromises. Incomplete scope, unfixed findings, and missing authority proof all leave residual risk. An audit logo is not continuous proof that today’s deployment still matches the reviewed commit.
How does Proof of Audits improve Web3 auditing outcomes?
Proof of Audits keeps audit evidence usable after the report: live bytecode match, authority mapping, fix verification, Trust Passports, and wallet-time signals so markets can inspect proof and gaps instead of only badges.
What should I look for when hiring a smart contract audit?
Clear scope and commit hash, severity findings with fix status, reviewer expertise match, re-review of patches, and a plan for post-deploy match of live code. Prefer transparent residual risk over marketing claims of perfect safety.
What does “best smart contract audit” or “best Web3 audit” mean here?
This guide is not a ranking of the best audit firms. “Best audit” searches usually mean teams want rigorous scope, skilled reviewers, fix verification, and proof that live code still matches. Proof of Audits focuses on that evidence layer after (and around) the review — not a leaderboard of firms.
My protocol is already audited. What next?
An audit report is point-in-time. Next steps are to match live bytecode and proxies to the reviewed commit, map admin/upgrade powers, track unreviewed changes, and publish inspectable proof. For live protocols with existing audits, start with the deployed Trust Passport path.