A bug bounty is the cheapest security programme a project can run and the one most often designed so that nobody serious participates. The failure is almost always the same: rewards too low to compete with the exploit itself, scope so narrow that the real attack surface is excluded, and a response process slow enough that a researcher gives up before anyone reads the report.
The economics are unforgiving. DefiLlama counts more than $1 billion stolen across 140+ exploits in 2026 alone, with 99 incidents in Q2. A researcher deciding whether to report or to sell is comparing your bounty against a share of that. A four-figure maximum payout on a protocol holding eight figures is not a programme, it is a notice that reporting is the worse option.
What makes researchers ignore a programme?
| Design choice | How it reads to a researcher |
|---|---|
| Maximum reward far below funds at risk | Reporting costs more than it pays |
| Admin keys and multisig excluded from scope | The actual 2026 attack surface is off limits |
| No stated response time | The report may sit unread for weeks |
| Severity decided solely by the team | The payout is whatever they feel like afterwards |
| Legal threats in the terms | Participation carries personal risk |
The second row matters most given what actually happened this year. Privileged access abuse, meaning compromised keys, multisig signer compromise and pre-signed transaction manipulation, has been the leading incident category by count since May. A scope covering only contract logic excludes the category that causes the most incidents.
What a working programme looks like
- Reward scaled to funds at risk, not to a marketing budget. The critical tier has to be plausibly competitive with exploiting the bug.
- Scope that includes key handling and operational access. If admin compromise is out of scope, the programme covers the wrong thing.
- A stated response time and a named contact. Twenty-four hours to acknowledge is a low bar and most programmes miss it.
- A published severity rubric. Deciding severity after receiving the report is how disputes start.
- Safe-harbour language. Researchers need to know that good-faith testing will not produce a legal letter.
Why this is marketing, not only security
Because it produces the one thing a security page cannot fake: a public record of how the project behaves when someone finds a problem. A resolved report, disclosed with the timeline and the payout, is evidence. A badge is a claim. The audience that reads either of those is the audience worth acquiring, particularly for wallets, custody and anything holding user funds.
It also compounds. Every disclosed and fixed finding adds to a history that a new user can check, which is why projects with a visible disclosure record convert better than those with a clean-looking page and nothing behind it. We handle that publication side as communications work: how we publish security and incident material.
What to publish after a report is resolved
The finding at a level of detail that no longer helps an attacker, the severity, the time from report to fix, and the amount paid. Teams frequently withhold the payout figure, which removes the part researchers use to decide whether to look at you next time. Withholding the timeline is worse, because a slow response is exactly what the record is supposed to prove did not happen.
Frequently Asked Questions
How much should a crypto bug bounty pay?
The critical tier should be plausibly competitive with exploiting the bug, which means scaling to funds at risk. A four-figure maximum on a protocol holding eight figures tells researchers that reporting is the worse option.
What should be in scope?
Key handling and operational access, not only contract logic. Privileged access abuse such as compromised keys and multisig compromise has been the leading incident category by count since May 2026.
Does a bug bounty help marketing?
Yes, through the disclosure record rather than the programme itself. A published finding with its severity, timeline and payout is evidence of behaviour, which a security badge cannot provide.
What should be disclosed after a fix?
The finding at a safe level of detail, the severity, time from report to fix, and the amount paid. Withholding the timeline defeats the purpose, since a fast response is what the record exists to demonstrate.