When to Launch a Bug Bounty: Before or After Your Audit

By the Guardian team Updated November 2026 4 min read

Quick answer. After. Audit a frozen commit, review the fixes, add a contest for high-value code, then launch the bounty when that code goes live. Earlier, it pays per-bug rates for issues an audit covers for a fixed fee.

Watch: When to Launch a Bug Bounty: Before or After Your Audit 1:36

Video transcript

Should your bug bounty launch before or after your audit? After. Both look for the same bugs, at different prices.

An audit covers the whole agreed scope for a set fee. A bounty pays per finding. After the audit, it hunts what reviewers missed.

Immunefi says 93.9 percent of programs running five years or longer on its platform surface a confirmed Critical. So a bounty helps most on reviewed, live code holding value.

Audit a frozen commit, and have the same team review every fix. Run a contest on the fixed commit for high-value code. Launch the bounty at mainnet, and monitor from the first deposit.

Before the bounty goes live, resolve every Critical and High and deploy the reviewed commit. Publish scope, staff triage, fund the pool and test a pause path.

Tie Critical rewards to funds at risk. GMX's Immunefi program pays 10 percent of funds affected, with a 50,000 dollar minimum and a 5 million dollar cap. The minimum sets the launch reward, then the percentage takes over until the cap binds.

Guardian's Vanguard puts these steps in one engagement: a two-team audit, deployment approval, a defender contest with a Guardian-funded Critical pot, a hosted bounty with Guardian matching your 50,000 dollars on Criticals, and six months of update reviews.

Read the full guide, or talk to Guardian about launching in the right order.

An audit and a bug bounty look for the same bugs, at different prices. Which one meets your code first decides what you pay.

This guide covers the order that works, what to fix before the bounty goes live and how to size rewards as deposits grow.

For running the program itself, see how to set up a web3 bug bounty program.

Why Timing Changes What It Finds

The two pay for different things:

A private audit is priced on scope and time, and covers the whole agreed scope.
A bounty pays per valid finding, wherever researchers choose to look.

Launch the bounty before the audit, and it pays per-bug rates for findings the audit fee would have covered.

After the audit, its job changes. It hunts for what reviewers missed and what new code brings in.

Immunefi frames the difference this way: an audit "is a snapshot", while a bounty runs "for as long as your program runs."

That long tail matters. Immunefi says 93.9% of programs that run five years or longer on its platform surface a confirmed Critical.

So a bounty helps most on code that is reviewed, live and holding value.

The Launch Sequence That Works

Five steps, each on the code the last one approved:

Audit a frozen commit.
Fix review: the same team checks every fix.
Contest on the fixed commit, for code that will hold significant value.
Bounty live when that code reaches mainnet.
Monitoring from the first deposit.

Immunefi gives teams near launch the same advice: "Pair your program with an audit competition before you ship."

The contest is a cross-check, not a replacement. Our comparison of audit contests and private audits explains why.

Monitoring covers what a bounty cannot. A bounty pays for reports before an exploit; it does nothing while one is under way.

During an exploit, the tools are onchain monitoring and SEAL Safe Harbor, which pre-authorizes whitehats to rescue funds.

What to Fix Before Going Live

A bounty opens your code to anyone chasing a reward. Close these first:

Every Critical and High resolved. Guardian's contest terms require this for deployment approval.
Deployed code matching the reviewed commit. Changes made after the audit are not covered by it.
Scope, known issues and trusted roles published, as our setup guide describes.
Triage staffed, with a named owner for each step.
The pool funded. Publish only a cap you can pay now.
A pause path tested, so a valid Critical can be contained before the fix ships.

Our pre-mainnet security checklist covers the deployment side.

Sizing Rewards at Launch and After

Tie Critical rewards to the funds at risk, and the bounty grows with you.

GMX's Immunefi program shows the formula: 10% of the funds directly affected, with a $50,000 minimum and a $5 million cap.

Under that formula, a bug affecting $200,000 still pays the $50,000 minimum. One affecting $20 million pays $2 million.

So the reward moves in three stages:

At launch, 10% of small deposits is small, so the minimum sets the real reward.
As deposits grow, the percentage takes over.
When the cap binds, the reward stops tracking the risk until you raise it.

If you have adopted SEAL Safe Harbor, raise its cap at the same time. SEAL recommends the two match.

Review the table on a schedule, and whenever deposits change sharply.

Common Timing Mistakes

Beyond launching too early, four mistakes recur:

Scope that misses new deployments. A contract not listed is not covered, so add each release.
Shipping unreviewed upgrades. A bounty is not a review of changes; see when you need a re-audit.
Reading a quiet bounty as proof. No reports means no one reported, not that no bug exists.
Freezing the reward table. A launch-day cap can fall far behind the funds at risk.

How Guardian Sequences It

Vanguard puts these steps in one engagement:

Audit by two cross-checking teams: manual review with fuzzing, and Helix, Guardian's AI auditor.
Deployment approval after Guardian reviews the final code, with every Critical and High resolved.
Defender contest on the audited scope, by invitation, with a Guardian-funded $100,000 Critical pot.
Hosted bounty, with Guardian matching your $50,000 on Criticals.
Update reviews for six months after launch, up to 2,500 onchain SLOC.

The contest runs for a set window of a few weeks and does not block deployment.

After launch, Managed Security monitors your contracts on every block, from privileged calls and upgrades to large fund movements.

Frequently Asked Questions

Should I launch a bug bounty before or after my audit?

After the audit and its fix review, when the reviewed code goes live. Launching earlier pays per-bug rates for issues an audit covers for a fixed fee.

Can a bug bounty replace a smart contract audit?

No. Researchers report only what they happen to find, and nobody is assigned the whole codebase. Run the bounty after an audit, to catch what reviewers missed and what new code adds.

Do I need a contest between the audit and the bounty?

For code that will hold significant value, it helps. Immunefi advises teams near launch to pair a bounty program with an audit competition before they ship. Run it on the fixed commit.

How big should bug bounty rewards be at launch?

Set a Critical minimum worth a researcher's time while deposits are small, plus a percentage of funds at risk that takes over as they grow. Raise the cap before deposits outgrow it.

Sources

Launch with the audit, contest and bounty in order

Vanguard runs the audit, a $100,000 Defender contest and a hosted bug bounty in one engagement.

Get a quote Explore Vanguard