How Many Audits Does a Protocol Need?

Video transcript

No standard sets how many audits a protocol needs. The right number depends on your risk.

A working paper on 4,108 DeFi protocols found audits, on average, did not reduce later breaches. Nearly 80 percent of hacks came within six months of launch.

Three factors size the review: novelty of the code, value at stake, and how often you upgrade.

This is our view, not an industry standard. A small fork may need one audit and a fix review. Novel code or large TVL warrants two independent reviews, a contest, then a scaled bounty.

Order matters. Audit, then fix review, then a contest on the fixed commit, then a live bounty.

Two audits are not automatically better than one. If each team lacks time for the whole scope, you get two partial reads.

A second review should add coverage, not halve it. Run teams in parallel for a direct comparison, or in sequence to check the fixes. Either way, close with a fix review.

Vanguard, Guardian's enterprise audit, builds this into one engagement: two independent teams, one using Helix, our AI auditor, a 100,000 dollar Defender contest, a hosted bug bounty, and six months of update review.

Read the full article for the risk table and what major protocols publish, or get a Vanguard quote at guardian.security.

Founders often ask how many audits to buy before launch. No standard sets the number.

What established protocols do is visible. Sherlock, which sells audits, says "most established protocols now combine all three: a firm audit before launch, a contest for breadth," and a standing bounty program afterward.

The right number for you depends on risk. Here is how to size it.

Why One Audit Falls Short

ethereum.org puts it plainly: audits "won't catch every bug." It warns against treating them as "a silver bullet."

A working paper on 4,108 DeFi protocols launched from January 2020 to January 2025 tested what audits change. Its October 2025 draft finds:

• On average, audits "do not reduce the likelihood of future security breaches."
• Audits by top-tier firms, and bug bounty programs, are associated with a lower likelihood of breaches.
• Most hacks come early: "nearly 80% within the first six months of launch."

So the first months carry the most risk, and the quality of review matters more than the badge. For the wider record, see audited vs unaudited exploits.

The Risk-Based Answer

Three factors decide how much review code needs.

• Novelty: new mechanisms, math or integrations, versus a light fork.
• Value at stake: TVL at launch, and how fast it can grow.
• Change rate: how often the code is upgraded after launch.

This table is our view, not an industry standard.

In every row, order matters: audit and fix review first, then a contest on the fixed commit, then a live bounty. Our guide to audit contests vs private audits explains why.

Novel vs integrated designs

Novel code has no earlier reviews to lean on. A fork inherits its parent's audits, but only for the lines it left unchanged.

Integrations add risk of their own. The paper above counts oracle and cross-chain designs as "risk-exposed," and finds those protocols more likely to buy an audit before launch.

TVL at launch

Value at stake sets an attacker's reward. ethereum.org suggests sizing bug bounty payouts "in proportion to the amount of funds at stake."

Apply the same logic to review depth. Plan for the TVL you expect in six months, not on day one.

Upgrade frequency

Every upgrade is new code that the original auditors never saw. Our guide on when you need a re-audit sorts changes by the review they need.

One Deep Audit or Two

Two audits are not automatically better than one. Depth matters more than count.

Each team needs time to cover the whole scope. SEAL's rough guide puts 1,000 to 4,000 lines at 2 to 5 weeks.

Splitting that time across two firms buys two partial reads. A second review should add coverage, not halve it.

Timing changes what a second review adds:

• Parallel: two teams on the same commit, each covering the full scope.
• Sequential: a second firm after fixes, which also reviews the fixed code.

Parallel reviews also show which team found what. SEAL says two auditors on the same code at the same time give "a much better comparison," while comparing sequential audits "can be misleading."

Either way, close with a fix review. Sherlock says "almost every protocol requires at least one remediation review."

What Protocols Publish

Large protocols publish their reviews in their own docs and announcements. Here is what four of them show:

Each lists more than one independent review for its core contracts.

Uniswap's v4 contest drew over 500 researchers, per its announcement.

How Vanguard Covers It

Vanguard, Guardian's enterprise audit, builds the layered answer into one engagement:

• Two independent teams on one scope: manual review with fuzzing, and Helix, Guardian's AI auditor.
• Cross-checks: each team checks the other; only human-verified findings reach the result.
• A $100,000 Defender contest, funded by Guardian, on the audited scope.
• A hosted bug bounty with $50,000 in Critical matching.
• Six months of update review after production.

For why one team is human and one is AI, see hybrid AI and human audits. To compare the layers on their own, see bug bounty vs smart contract audit.

Frequently Asked Questions

How many smart contract audits does a protocol need?

We know of no standard number, so size it by risk. A small fork may need one audit and a fix review. Novel code holding significant value warrants two independent reviews and a contest before launch, then a bug bounty.

Is a second smart contract audit worth it?

For novel code or significant value, yes, if each team has time to cover the whole scope. Splitting one review budget into two shallow audits adds names to the report, not coverage.

Should two audits run at the same time or one after the other?

Parallel reviews give two independent reads of the same commit and a direct comparison of the teams. A sequential second audit also covers the fixes from the first. Either way, finish with a fix review.

Do audited protocols still get hacked?

Yes. A working paper on DeFi protocols launched from January 2020 to January 2025 found that audits, on average, did not reduce later breaches. Audits by top-tier firms and bug bounty programs were associated with a lower likelihood of breaches.

Sources

• Sherlock: Smart Contract Audit Pricing, A Market Reference for 2026 (February 2026)
• ethereum.org: Smart contract security (updated Oct 22, 2026)
• Landsman, Lyandres, Maydew, Rabetti and Zhang: Auditing Smart Contracts, working paper (October 2025 draft)
• Security Alliance (SEAL) Frameworks: Vendor Selection (v0.0.2, accessed Nov 5, 2026)
• Security Alliance (SEAL) Frameworks: What to Expect from a Smart Contract Audit (v0.0.2, accessed Nov 5, 2026)
• Uniswap Labs: Uniswap v4 bug bounty announcement (November 26, 2024)
• Lido docs: Audits (accessed Nov 5, 2026)
• Morpho docs: Audits (accessed Nov 5, 2026)
• Ethereal docs: Audits (accessed Nov 5, 2026)
• Guardian: When Do You Need a Re-Audit? (November 2026)
• Guardian: Audit Contest vs Private Audit
• Guardian: Vanguard