Bug Bounty Program Checklist for Token Projects: Scope, Rewards and Response

A crypto bug bounty program is a standing, public offer to pay independent security researchers who responsibly report vulnerabilities in your contracts and infrastructure instead of exploiting them. To run one well, you need a defined scope, reward tiers tied to the funds at risk, a funded payout pool, a written safe-harbour and disclosure policy, and a triage runbook your team has rehearsed. This checklist covers each stage in order, including the part most security guides skip: what a disclosed or exploited bug does to your token's liquidity, and who you need to call.

Bounties Complement Audits, They Do Not Replace Them

An audit is a time-boxed review by a chosen team of a fixed code snapshot. A bounty is open-ended, crowd-sourced and continuous. The audit asks whether the code you are about to ship has known classes of flaws. The bounty asks whether anyone, at any point after launch, can find something that slipped through, including issues introduced by later upgrades or integrations.

Treat the audit as the entry ticket and the bounty as the long-term safety net. A bounty on unaudited code mostly pays for flaws a standard review would have caught, and it draws public attention to a codebase that is not ready. If you have not scoped your review yet, start with smart contract audits before launch.

Phase 1: Before You Launch the Program

• In-scope contracts are audited, and critical and high findings are fixed and re-verified.
• A named security owner and a backup have authority to pause contracts and approve payouts.
• Admin and pause powers sit behind a multisig, not a single key.
• Monitoring and alerting exist for unusual contract activity, so you can detect an exploit nobody reports.
• A private reporting channel is ready, such as encrypted email or a platform submission form. Public chat is not acceptable for vulnerability reports.

Phase 2: Define the Scope

Vague scope is the biggest cause of bounty disputes. Write it as a list, not a paragraph.

• In-scope assets are listed by chain, contract address and repository commit or tag.
• Out-of-scope assets are explicit: third-party protocols you integrate with, test deployments, anything you do not control.
• In-scope impacts are defined: loss or freezing of funds, unauthorised minting, permanent lock-up, governance takeover, manipulation of core accounting.
• Out-of-scope issues are listed: findings already in your audit reports, issues needing compromised admin keys, theoretical issues without a working proof of concept, spam, social engineering and infrastructure denial-of-service.
• Testing rules are stated: use a fork or testnet, never mainnet funds or real users.

If your contracts are still in a public test phase, an incentivized testnet can surface functional bugs at low stakes before a mainnet bounty opens. The two programs need different rules and different reward logic, so do not blur them.

Phase 3: Severity and Reward Tiers

Rewards are commonly scaled to the funds at risk. The reasoning is simple: if a flaw could drain the treasury or the liquidity pool, a payout that is trivial next to the potential loss gives a skilled researcher little reason to report rather than exploit. A payout that is a meaningful fraction of what could be lost makes responsible disclosure the rational choice.

• Each tier has a written definition with examples, so researchers and triagers classify issues the same way.
• You state how likelihood and impact combine into severity, who has the final say, and how disputes are handled.
• You do not publish figures you are not prepared to honour. A disputed promise damages trust faster than having no program.

Phase 4: Hosted Platform or Self-Hosted

• Hosted platforms such as Immunefi and HackenProof are generally positioned as web3 bounty marketplaces: an existing researcher community, a standard submission and triage flow and severity frameworks. The trade-off is working within their rules.
• Contest-style platforms in the Code4rena mould run time-limited competitive reviews with a prize pool. They resemble a crowd-sourced audit more than a standing bounty, so they fit pre-launch or pre-upgrade checks.
• Self-hosted programs give full control, but you must attract researchers, triage and pay yourself. This suits teams with strong in-house security.
• Decide whether you want a standing bounty, a contest or both, and when each fits your release cycle.

Phase 5: Fund the Pool and Choose the Currency

• The pool is funded and segregated from operating funds and sized to your maximum critical payout. An unfunded promise is a liability, not a security measure.
• Decide the payment currency. Stablecoins keep reward value predictable for researchers and your budget. Paying in your own token looks cheaper, but exposes researchers to volatility and can create sell pressure on your own market.
• If any portion is in the native token, set vesting or lock terms in advance rather than negotiating mid-incident.
• Hold the pool consistently with the rest of your reserves. Our guide to treasury management for crypto projects covers structuring a security allocation.

Phase 6: Safe Harbour and Disclosure Policy

• A safe-harbour statement says good-faith testing within scope will not be pursued by the project, subject to program rules.
• A coordinated disclosure policy asks researchers to stay silent until a fix ships or an agreed deadline passes.
• Prohibited actions are stated: accessing user data, moving funds beyond a minimal proof of concept, extortion, disclosure before a fix.
• You describe how you will treat someone who exploits instead of reports, and how a negotiated return of funds would work.
• The policy is reviewed by qualified legal counsel in the relevant jurisdictions. Safe-harbour wording, tax and handling of returned funds are legal questions, not engineering ones, and this article is not legal advice.
• The policy is published somewhere stable and linked from your docs and repository.

Phase 7: Triage and Response Runbook

Write it before you need it, and rehearse it once.

• Acknowledge every report within a stated timeframe.
• Reproduce on a fork using the researcher's proof of concept, never on mainnet.
• Classify severity against your written definitions and record why.
• For critical or high issues, convene a small incident group and limit information to those who need it.
• Decide whether the issue is actively exploitable now. If so, contain: pause, rate limit or move exposed funds as your design allows.
• Build the fix, have it independently reviewed and test it on a fork.
• Update the researcher throughout. Silence is the most common reason disclosures go public early.
• Pay promptly once the fix is verified and record the decision.

Phase 8: Liquidity, Exchanges and Market Impact

A disclosed or exploited vulnerability is a market event as much as a security event. Even a fixed bug where nobody lost money can push holders to exit, liquidity providers to withdraw and market makers to widen spreads, because they cannot price a risk they do not understand.

• Agree in advance who speaks to exchanges and when. Tell them before the public if a pause could affect deposits, withdrawals or trading.
• Tell your market maker early and plainly. They need to know whether to keep quoting, reduce size or step back, and whether inventory on affected contracts is at risk.
• Identify liquidity pools and lending markets that hold your token and notify their operators if the issue touches them.
• Decide in advance whether the treasury will ever support the price during an incident.
• Watch spreads, depth and pool withdrawals in the days after the event, not only during it.

Phase 9: Post-Fix Disclosure and Communication

• Publish a post-mortem after the fix: what happened, impact, timeline, the fix and what changes next. Hold back details that help copycat attacks on forks or sibling deployments that have not yet patched.
• Credit the researcher where they consent. It builds the reputation your program depends on.
• Communicate through official channels only, with one canonical statement, and warn users about scams that follow security news.
• Tell exchanges and your market maker when it is safe to resume normal operations, and confirm books and pools are healthy.

Phase 10: Ongoing Maintenance

• Update scope whenever you upgrade a contract, deploy to a new chain or add an integration.
• Re-audit material upgrades before they go live and enter bounty scope.
• Revisit reward levels as funds at risk grow or shrink, and top up the pool on a schedule.
• Run a tabletop drill periodically, including the exchange and market maker calls.

Common Mistakes

1. A bounty instead of an audit. It is the second line of defence, not the first.
2. Rewards small next to funds at risk. Exploiting becomes more attractive than reporting.
3. No safe harbour. Good-faith researchers walk away; bad-faith ones do not.
4. Slow or silent triage. Ignored researchers disclose publicly.
5. Stale scope after upgrades. The newest code is often the least reviewed.

Security Is a Liquidity Question

Liquidity providers, exchanges and market makers all price in the chance that a contract fails. A visible, funded, well-run bounty program lowers that risk premium and gives you a rehearsed way to respond when something does surface. Fibonacci Capital works with token teams on market making and liquidity, and stable order books depend on exactly this kind of preparation. If you want to talk through how a security incident would affect your market, get in touch.