In July 1714 the British Parliament passed “An Act for Providing a Publick Reward for such Person or Persons as shall Discover the Longitude at Sea”. It hired nobody. It set a bar and named a price. The History of Parliament’s account records the tiers: £10,000 for a method accurate to “One Degree of a great Circle, or Sixty Geographical Miles”, £15,000 for two-thirds of that distance, £20,000 for half of it.
The same Act did something less famous. Where five or more Commissioners thought a proposal promising, they could direct the Commissioners of the Navy to issue up to £2,000 to conduct trials on it. Parliament bought two things at once. It bought a result from whoever could produce one, and it separately paid for the work of testing the proposals it chose to take seriously.
Three hundred years later, a protocol security budget has the same two halves, and most teams argue about them as if only one can be right.
Quick answer
A security audit is commissioned work: fixed scope, fixed fee, fixed dates, and a report whether or not anything is found. A bug bounty is a standing offer: open to anyone, unbounded in time, and paid only when someone produces a validated finding. The audit buys coverage. The bounty buys outcomes. A protocol holding user funds ends up wanting both, and the sequence is audit first, because a bounty on unreviewed code pays market rate, per bug, for findings a scoped review prices once.
Two ways to buy the same thing
| Manual security audit | Bug bounty | |
|---|---|---|
| What you are buying | A fixed quantity of expert attention on a scope you define | A standing offer to pay for a result |
| Who looks | A named team you contracted | Anyone who decides your programme is worth their weekend |
| When it happens | Before deployment, against a commit hash | After deployment, against live code, continuously |
| Who chooses what gets read | You do, in the engagement | You publish a scope. Researchers pick what inside it looks profitable |
| If nobody finds anything | You still get the report, and the record that the review happened | You pay nothing. That is the deal, and it is also the risk |
| What it costs | A fee agreed up front. Fidesium’s manual audits start at $5,000 | A payout per validated finding, plus a platform fee, plus the cost of reading everything else |
| What it produces | Findings with severity, remediation guidance, fix verification, a public report | Individual reports of varying quality, arriving on no schedule |
| What it proves to a third party | An artefact you can hand an exchange, an investor or an enterprise buyer | That you paid for what was found, which is weaker evidence and still worth having |
| Its blind spot | Only what was in scope, only on that day | Only what someone chose to look for, and only what the programme says it will pay for |
Neither of these makes a contract safe. One is a process for finding problems on purpose, the other is a market for finding them by accident, and the honest version of this comparison is about what each one can reach.
You are paying for coverage, or you are paying for outcomes
Everything else follows from this one difference. When you commission an audit, you are buying hours: you agree what is in scope, the team reads it, and at the end there is a document saying what was reviewed and what was found. If the answer is “not much”, you have still bought something, a record that competent people looked, with their names on it. That record is what a listing review or a diligence process actually asks for.
When you fund a bug bounty, you are buying results. Nobody is obliged to look at your code, and nobody is obliged to look at the part of it you are most worried about. If a quarter passes and no valid report arrives, you have spent nothing and you have learned nothing, and those two facts are indistinguishable from the outside. A quiet programme tells you nobody has been paid, which is a fact about the market for your bugs rather than about your code.
That asymmetry is why the two are priced so differently, and why the cheap-looking one needs the more careful budget.
The scope problem, and the bug that fell outside it
On 2 February 2022, the security researcher Jay Freeman reported a critical bug in Optimism’s fork of go-ethereum that made it possible to create ETH by repeatedly triggering the SELFDESTRUCT opcode on a contract holding a balance. His own write-up contains the sentence that matters most for anyone choosing between these two products:
“Technically, their Immunefi program did not cover this bug, as it is not in the explicit scope, so I couldn’t go through Immunefi and had to reach out directly. But they have been extremely gracious and immediately said they would cover it equivalently.”
Optimism paid the full maximum, $2,000,042. Boba Network, a fork running the same code, later extended its own maximum award of $100,000, which took the total to $2,100,042 and, by Freeman’s own reckoning, set a record for a single bug.
Read it again. The largest bounty of its moment was paid for a finding the programme’s published scope did not cover, and it was paid because the team decided to pay it, not because the programme obliged them to.
Scope is where a bounty’s coverage actually lives, and you write it before you know what is wrong with your system. An audit scope has the same problem, with one difference that matters: you and the auditors negotiate it together, with the architecture in front of you. A bounty scope is published to strangers and then it is fixed.
What a bounty reaches that a scoped review does not
The counterweight is just as real, and it is why serious protocols run both.
On 24 February 2022, a researcher using the name satya0x disclosed an uninitialised proxy implementation bug in the Wormhole core bridge contract on Ethereum, through Wormhole’s programme on Immunefi. Immunefi’s own bugfix review states what happened next: “Wormhole was amazingly fast in its response to the bug report, verifying and fixing the issue on the same day it was reported.” No user funds were lost. Wormhole paid $10 million, which the same review calls a record.
That bug was in deployed code, on a live bridge, found by one person who chose that target because the reward justified dropping everything else. No commissioned engagement produces that. You cannot buy a month of someone’s obsession at an hourly rate. Bounty payouts look absurd next to audit fees because they are priced against something else entirely: what the same person could earn by not telling you.
What a bug bounty actually costs
The payout is the number everyone quotes and it is rarely the number that hurts.
| Cost | What it is | A published figure |
|---|---|---|
| The payout | Priced against severity and funds at risk | On Immunefi’s own programme board, read on 9 September 2026, 177 live programmes are listed, with maximum bounties in the server-rendered rows running from $30,000 to $3 million |
| The platform fee | A percentage on top of whatever you pay the researcher | Sherlock’s post-launch bounty terms set a platform fee of 10% of the research fee, payable within 10 days of the final resolution |
| Submission friction | Pushed onto researchers to suppress spam, which tells you the spam is real | Code4rena bounties require a 25 USDC deposit on every submission, refunded only if the finding is valid or marked wontfix |
| Triage | Somebody senior has to read all of it, including the noise | Immunefi sells Managed Triage as a product. GMX’s testimonial on that page: it “significantly reduced the time spent reviewing and replying to invalid reports” |
| Your response time | An obligation you take on, not one you impose | On Code4rena, a bounty finding that gets no sponsor response within 14 days is closed by default. On Immunefi’s board, The Graph publishes a median resolution time of 1 day |
Fidesium’s own security services page puts the operational half of this bluntly: “A bug bounty without proper scoping and triage isn’t security, it’s noise. Unmanaged programmes flood your engineering team with low-quality submissions while legitimate researchers get frustrated by slow responses.”
Both halves of that sentence cost money. The first burns your engineers. The second burns the only asset a bounty has, which is its reputation among the small number of researchers capable of finding something serious.
What a bounty is not allowed to find
This is the section that decides the question for most protocols, and it lives in the platforms’ own rules rather than in their marketing.
A bug bounty pays for impacts a programme has agreed in advance to pay for. Immunefi’s Vulnerability Severity Classification System v2.3 sets the four-level scale most Web3 programmes use, Critical through Low, and then lists the impacts it recommends projects mark out of scope by default. Among them:
- Anything requiring access to leaked keys or credentials.
- Anything requiring access to privileged addresses, including governance and strategist contracts.
- Phishing and other social engineering against the project’s employees or customers.
- Centralisation risks.
- Incorrect data supplied by third-party oracles.
- Basic economic and governance attacks, including a 51% attack.
- Sybil attacks, and lack of liquidity.
- Best practice recommendations and feature requests.
The same document prohibits testing against mainnet or public testnet deployments by default. All testing is expected to happen on local forks.
Look at that list next to where money has actually gone in this industry. Keys, signers, permissions granted to solve a problem last quarter, the person in the DMs who turned out to be patient rather than friendly. Greg Bock has written up what adversarial thinking looks like applied to those failures, and the short version is that the contracts held and the humans around them did not.
A bounty is not scoped to find any of that. A penetration test is, and a manual audit reaches the economic and intent questions no default severity table can reason about. Buying one and calling the others covered is how a security budget ends up shaped like a checkbox.
Three models, not two
Half the arguments about bounties are really arguments about audit competitions, which are a third thing.
| Commissioned audit | Audit competition | Bug bounty | |
|---|---|---|---|
| Who reviews | A team you contracted, by name | A large open field of researchers | Anyone, at any time |
| How long | A scheduled engagement | A fixed window. Code4rena’s submission phase typically runs 1-3 weeks | Standing, until you close it |
| Scale | A small number of people, deeply | Code4rena cites over 10,000 registered auditors and an average of 100+ participating per audit | Unknown, and unknowable |
| What triggers payment | The engagement | The prize pool, split by a judged award algorithm | A validated finding, per finding |
| What you get | A report, fix verification, an artefact | A judged report, usually published | Individual disclosures, no report |
| Where it fits | Before launch, and after material change | Before launch, when the codebase is large and the deadline is real | After launch, permanently |
An audit competition is a pre-launch event. A bug bounty is a post-launch posture. They are often sold by the same platforms and they answer completely different questions, which is why treating “we ran a contest” as “we have a bounty” leaves live code with nobody watching it.
The order is not a preference, and the platforms say so themselves
Sherlock’s post-launch bug bounty is described in their own documentation as available to “qualifying customers who have undergone a Sherlock audit”. Their pre-launch bounty page is equally direct that such programmes “are not the default path for most teams”, and are used only when launch timing or deployment sequencing leaves a real gap between fix review and mainnet.
The commercial logic underneath that is simple. Run a bounty on unreviewed code and you are buying findings one at a time, at a price set by the person who found them, for bugs a scoped review would have priced once and found together. You also pay the triage cost on every duplicate, and duplicates are what an unreviewed codebase generates: the obvious problems get found by everyone at once.
There is a timing cost as well. A finding that arrives during a scoped review is fixed in a pull request. The same finding after mainnet is a migration, a governance proposal, or a pause. Code that has never been reviewed and is drifting away from its last known state is the most expensive place to discover anything.
What a bounty needs before it is worth running
If you are going to fund one, fund it properly. The programmes that work share these:
- A scope written down, with the contracts and the impacts stated, so that the Optimism situation above is a decision rather than an accident.
- A pool that is credibly funded and visible, because researchers pick targets on expected value.
- A published severity scale, so that “Critical” is not something you argue about after the fact.
- A proof of concept requirement. Code4rena’s bounties accept Critical and High risk issues only, and require coded runnable proofs.
- A response commitment you can actually keep, with a named person answering.
- A triage layer between submissions and your engineers.
- Safe harbour. Immunefi’s implementation uses the Security Alliance’s Safe Harbor Agreement, which covers active exploitation only and expressly forbids everything else.
If you cannot fund a pool yet, publish a disclosure policy instead. HackerOne’s help centre draws the line at the incentive: a vulnerability disclosure programme gives finders clear guidelines on how and where to report, and is what they call “the ‘see something, say something’ of the internet”. It costs a page, an inbox and a promise to answer. A protocol with no route for a stranger to report a problem is choosing not to be told.
So which do you buy, and when
| Where you are | What to buy first |
|---|---|
| Pre-mainnet, code frozen, launch date set | The audit. It is the only one of the three that produces the artefact a procurement or diligence review asks to see |
| Large codebase, hard deadline, budget for breadth | An audit, then a competition for scale on the same scope. A competition is not a substitute for a report with fix verification |
| Live, audited, holding user funds | A funded bug bounty, sized against what is at risk, with triage in place before you announce it |
| Live, never reviewed, no budget for both | The audit. A bounty here pays retail for problems a review finds wholesale |
| Live, with a bounty already, and no idea whether it is working | Look at what you have paid out and what you have rejected. Both numbers being zero means nobody is looking |
| Worried about keys, signers and deploy pipelines | Neither. That is a penetration test, and the bounty’s own rules put it out of scope |
What Fidesium does with each of these
Fidesium’s manual smart contract audits are line-by-line human review, chain agnostic with an EVM specialism and Solana coverage, taking in logic and economic risk rather than only the code. They start at $5,000 and include two rounds of fix verification, a public report with a badge and an on-chain NFT attestation, and one month of continuous scanning after delivery. The audit portfolio is the work itself rather than a summary of it. Fidesium publishes $250M+ secured across 110+ contracts audited, and the portfolio is where that record is shown.
On the bounty side, the offer is management rather than a platform. Fidesium’s security services cover scope definition and attack surface mapping, reward structures calibrated to your risk profile, first-line triage with severity classification and deduplication, researcher relationship management, and escalation of confirmed findings with remediation context, run across Immunefi, Code4rena, HackenProof, Bugcrowd or a self-hosted programme. Continuous scanning, which keeps the report and the deployed code from drifting apart, starts at $399 a month.
Security is a process, and a process needs somebody to run it. A bounty with nobody answering it is a budget line, not a security layer.
Frequently asked questions
Is a bug bounty a substitute for a smart contract audit?
No. An audit is commissioned work with a defined scope and a report at the end, whether or not anything is found. A bug bounty is a standing offer that pays only when someone produces a validated finding, and nobody is obliged to look at your code at all. The audit buys coverage, the bounty buys outcomes, and only the audit produces the artefact an exchange, an investor or an enterprise buyer asks to see.
What is a crypto bug bounty?
It is a published programme that pays independent security researchers for responsibly disclosing vulnerabilities in a live protocol. The programme sets a scope, a severity scale and a maximum payout, usually on a platform such as Immunefi, Code4rena, HackenProof or Bugcrowd. Most Web3 programmes classify findings on Immunefi’s four-level scale of Critical, High, Medium and Low, and price them against the funds an exploit would put at risk.
How much does a bug bounty programme cost?
More than the payout. On Immunefi’s own programme board on 9 September 2026, 177 live programmes were listed with maximum bounties from $30,000 to $3 million. On top of whatever you pay a researcher, Sherlock’s post-launch terms add a platform fee of 10% of the research fee, and the largest recurring cost is triage: senior engineering time spent reading submissions, most of which are invalid. Immunefi sells managed triage as a separate product for exactly that reason.
Should I run a bug bounty before or after an audit?
After. Sherlock’s post-launch bug bounty is offered to customers who have already undergone a Sherlock audit, and Sherlock’s own documentation says pre-launch bounties “are not the default path for most teams”. A bounty on unreviewed code buys findings one at a time at a price the finder sets, generates duplicate reports of the obvious problems, and surfaces them after deployment, when a fix is a migration rather than a pull request.
What is the difference between a bug bounty and an audit competition?
An audit competition is a fixed pre-launch event: a prize pool, a submission window of typically 1-3 weeks on Code4rena, a large open field of researchers, judging, and a published report. A bug bounty is a standing post-launch programme with no window, no report and no guaranteed participation. A competition replaces or supplements breadth in a pre-launch review. A bounty covers live code afterwards. Running one does not give you the other.
What will a bug bounty not cover?
Whatever the programme’s scope excludes, and the default exclusions are broad. Immunefi’s recommended out-of-scope list includes anything requiring leaked keys or credentials, anything requiring access to privileged addresses, phishing and social engineering against your team, centralisation risks, incorrect data from third-party oracles, basic economic and governance attacks such as a 51% attack, Sybil attacks and best-practice recommendations. Testing against mainnet is also prohibited by default. Several of those categories are where the largest real-world losses have come from, and they are the province of a penetration test rather than a bounty.
Does a small protocol need a bug bounty?
Not necessarily, and an underfunded one is worse than none, because researchers choose targets on expected value and a pool nobody believes in signals that reports will not be paid. If the budget only stretches one way, spend it on a scoped review of the code before launch. Then publish a vulnerability disclosure policy, which HackerOne distinguishes from a bounty by the incentive rather than the process: it costs a page, an inbox and a commitment to answer.
Who runs the bug bounty programme, us or the platform?
The platform hosts it. Someone still has to define the scope, set the reward structure, triage every submission, judge severity, deduplicate, answer researchers and escalate confirmed findings to the engineers who will fix them. That work is the programme. Fidesium runs it as a managed service across Immunefi, Code4rena, HackenProof, Bugcrowd or a self-hosted programme, which is a different purchase from the audit and is quoted per protocol.
