Skip to content
Financial Context Wiki

How crypto bug bounty programs work

A crypto bug bounty is a versioned disclosure and reward process whose scope, authorization, evidence, severity, remediation, disclosure and payment terms must be audited separately.

Updated

For educational purposes only; not legal, tax or security advice. A published program, safe-harbor statement, severity label or estimated award does not guarantee authorization, immunity, payment or protocol safety.

Direct answer

A crypto bug bounty is a versioned process through which a project invites private reports about specified vulnerabilities and may reward reports that satisfy its current rules. It is not the same as a vulnerability disclosure policy: a disclosure policy can provide a reporting channel and authorization terms without promising payment. Neither is a certification, insurance policy, employment relationship or proof that a system is secure.

The controlling object is a saved program snapshot, not the project name or today’s web page. Record the policy URL, revision and time; exact chains, contracts, proxy implementations, repositories, commits and releases; eligible impacts; excluded systems and methods; reward table and cap; submission and disclosure rules; safe-harbor language; and identity, sanctions, tax and payment conditions. Scope is the intersection of asset, version, chain, impact and permitted testing method.

Safe harbor can express how an organization intends to treat good-faith research that follows its rules. It does not expand scope, bind third parties or law-enforcement bodies, override other jurisdictions, or excuse privacy invasion, disruption, extortion or unauthorized movement of funds. When authorization is unclear, ask through the official channel before testing.

Operate four separate ledgers: authorization and evidence; technical exploitability and economic impact; mitigation, remediation and disclosure; and award, compliance and payment. A critical label does not itself determine a reward, an award decision is not a payment receipt, and a patch passing one unit test is not proof that the affected deployment is safe.

How it works

Testing must remain within the frozen rules. A minimal proof of concept normally progresses from static analysis and unit or property tests to a local fork or another specifically authorized environment. Mainnet, public-testnet, denial-of-service, social-engineering, third-party or personal-data testing may be prohibited. Do not transfer or retain real user assets merely to demonstrate impact, and do not assume an active-exploit rescue is authorized by an ordinary bounty.

A useful report pins the affected chain, address, implementation, commit, state block and policy snapshot. It states prerequisites, exact reproduction steps, expected and actual behavior, transaction or calldata sequence, artifact hashes, technical path, realistic impact bound, attacker capital and privileges, assumptions and a secure contact method. Encrypt weaponizable material and sensitive data, minimize collection, record access and preserve a chronology.

Triage should separate scope, duplicate or known-issue status, technical exploitability, economic impact, severity and award eligibility. A technical class does not determine executable loss. Capital, permissions, competition, liquidity, oracle windows, rate limits, pauses, reorganization risk, repeatability and user interaction can change the outcome. The first message is not necessarily the first complete eligible report; the snapshotted duplicate rule and evidence of prior knowledge control.

Acknowledgement, reproduction, severity decision, emergency mitigation, final remediation, disclosure, award approval and payment are different states and clocks. Targets such as 24 hours or 72 hours are meaningful only if the program or incident plan defines them. Silence is operationally harmful, but no universal response-time rule can be inferred from the words bug bounty.

Emergency action can pause a function, lower a cap, remove a front-end route or change monitoring, but that is not the final fix. An upgrade must verify authorization, timelock or emergency powers, implementation and initializer, storage layout, migration and rollback. Convert the original proof into a regression test, probe adjacent paths and invariants, simulate the deployed state, verify execution receipts and monitor the actual versions on every affected chain.

Disclosure needs a private channel, embargo start, update cadence, extension and emergency-publication rules, researcher credit or anonymity, and evidence retention or deletion terms. Payment needs its own reconciliation: nominal award, formula or discretion, currency and foreign-exchange snapshot, KYC or sanctions checks, tax forms or withholding, destination chain and address, fees, approval status, transaction identifier and amount received.

Use this workflow:

  1. Save the program snapshot: URL, revision and time, exact assets, chains, addresses, implementations, commits, eligible impacts, exclusions, reward terms, safe harbor and disclosure policy.
  2. Establish written authorization for the actor, system, environment, method, rate, data handling and third-party boundary; stop and ask when any element is unclear.
  3. Build the smallest non-harmful proof in the specifically allowed environment; pin code and state, quantify prerequisites and impact, and stop once sufficient evidence exists.
  4. Submit through the authorized secure channel with report ID, timestamps, encrypted artifacts, hashes, reproduction steps, impact ledger, assumptions and contact history.
  5. Determine scope and duplicate or known status, then assess exploitability, economic impact, severity and award eligibility separately under the saved rules.
  6. Track mitigation, patch or migration, upgrade and storage review, regression and invariant tests, deployment receipts, monitoring and coordinated disclosure as distinct states.
  7. Reconcile the approved award, currency and exchange rate, KYC, sanctions, tax, chain, address, fees and payment receipt; retain an auditable record without unnecessary sensitive data.

Examples

  • Scope is narrower than name matching. A saved program lists 12 assets. A report mentions 9; only 7 match the specified chain and deployed version, while one is a third-party oracle and one is an unreleased commit. Name match is 9 / 12 = 75%, but authorized in-scope coverage is 7 / 12 = 58.33333333%. The snapshot, not the percentage, decides eligibility.
  • Impact, severity and candidate award are different. Reproducible direct value at risk is $8,000,000. A hypothetical saved rule pays 10%, with a $50,000 floor and $500,000 cap. Raw calculation is $8,000,000 * 0.10 = $800,000, so the candidate after the cap is $500,000. A privileged-signer prerequisite could move the report to another severity or reward tier; the calculation is not an entitlement or universal formula.
  • Each response clock measures a different state. Submission is 2026-08-13 09:00; acknowledgement at 11:30 takes 2.5 hours; triage at 2026-08-14 16:00 takes 31 hours; a temporary cap at 21:00 takes 36 hours; patch deployment at 2026-08-16 21:00 takes 84 hours; coordinated disclosure at 2026-08-23 09:00 takes 240 hours, or 10 days. Fast acknowledgement does not imply fast remediation or payment.
  • Nominal award and settlement are separate. An approved $500,000 award is paid in USDC at a fixed $1.002 per USDC, so units due are $500,000 / $1.002 = 499,001.996008 USDC. If the project pays an $18 network fee separately, the researcher still receives 499,001.996008 USDC; if it deducts the fee from the award, received fiat value is $499,982 at the fixed rate. Tax and withholding remain separate entries.

Risks

  • The policy page changes and no dated snapshot exists.
  • The tested asset, version, chain, address or implementation is outside scope.
  • A proxy upgrade changes the affected code during research or remediation.
  • Safe-harbor language is mistaken for universal legal immunity.
  • Testing reaches an excluded vendor, oracle, user account or other third party.
  • Mainnet or public-testnet activity violates the program’s environment rules.
  • The proof moves real funds, disrupts service or accesses personal data.
  • Automation exceeds load limits or becomes denial-of-service testing.
  • Social engineering, phishing, coercion or extortion exceeds authorization.
  • The proof collects or exposes more weaponizable evidence than necessary.
  • An insecure submission channel leaks secrets, user data or exploit details.
  • Evidence hashes, timestamps, code versions or chain state cannot be reproduced.
  • Duplicate, prior-knowledge or first-eligible-reporter evidence is incomplete.
  • A vulnerability name anchors severity without testing prerequisites and reachability.
  • Theoretical value at risk is mistaken for realizable loss or attacker profit.
  • Reward floor, cap, discretion, currency or eligibility rules are misread.
  • KYC, sanctions, tax, invoice or payment-chain conditions delay or block settlement.
  • Silence, ambiguous clocks or premature disclosure increases exploitation risk.
  • Emergency pause, cap, upgrade, storage change or migration causes new harm.
  • A bounty, audit, formal proof or monitoring system is treated as a security guarantee.

Common misconceptions

  • “A public program authorizes testing of every related asset and method.” Authorization is limited by the saved asset, version, impact, environment and conduct rules.
  • “Safe harbor guarantees immunity in every jurisdiction.” It is conditional policy language and cannot bind every third party or authority.
  • “A critical label or impact percentage automatically fixes the payout.” Severity, eligibility, reward terms, caps, discretion and settlement conditions remain distinct.
  • “The first message always wins a duplicate, and moving funds proves impact.” Programs can require the first complete eligible report, while unauthorized harm can disqualify the submission and create legal exposure.
  • “A bounty and an audit prove there are no bugs once the patch passes tests.” Audits, formal methods, testing, bounties, monitoring and incident response cover different versions, assumptions and failure modes.

Sources

Navigation

Search the wiki...