OAK-M32 — Bug Bounty Programs

Description

Bug bounty programs are the continuous, post-deployment vulnerability-discovery layer that operationalises external-researcher disclosure into a market with explicit prices, severity rubrics, and intake SLAs. M32 is the operational mitigation pairing M16 (pre-deployment audit and formal verification): M16 produces an artefact bound to a commit hash at audit time; M32 produces a running market over the deployed bytecode that compensates whitehat researchers to surface findings the audit missed, that the audit could not have caught (runtime-context dependencies, post-upgrade drift, integration-layer interactions), or that emerged after the audit boundary. The structural distinction is load-bearing: a project that has only been audited has obtained a one-shot review against a frozen commit; a project that runs an active bounty has standing financial incentives for adversarial researchers to choose responsible disclosure over private exploitation, for the entire lifetime of the deployment.

The economic model is a price-discovery mechanism between the protocol's funds-at-risk and the attacker's expected-value-of-exploitation. A bounty pays in proportion to severity (Immunefi's industry-canonical scale: critical / high / medium / low / informational, with critical payouts on major DeFi programs reaching $1–10M and platform-wide capacity an order of magnitude higher). When the bounty is calibrated such that paying the bounty is cheaper than absorbing the exploit's expected loss, and the platform's payout reputation is sufficient that the researcher trusts the program's commitment to actually pay, the mechanism converts what would otherwise be a black-market exploitation cohort into a whitehat-disclosure cohort. The recurring industry observation — Immunefi alone reports cumulative payouts of over $100M across thousands of valid reports, with the broader ecosystem (Code4rena, Sherlock contests, HackenProof, Cantina) adding substantial additional volume — is that the bounty surface produces continuous P0/P1 findings on already-audited and already-deployed code.

M32 is the only mitigation in the OAK catalogue that is explicitly post-deployment, continuous, and adversarial-researcher-driven. Audit (M16) is point-in-time; static analysis (M02) is continuous but signature-bounded; bytecode-diff monitoring (M03) is continuous but only catches changes, not pre-existing flaws. Bug bounty is the layer at which novel vulnerabilities — including those that no auditor has yet developed a detector for — surface against the deployed system. The combination M16 + M32 is what defenders should require of any production protocol; either alone is structurally insufficient.

How it applies

• OAK-T9.001 / T9.002 / T9.003 / T9.004 / T9.005 (smart-contract exploit classes): the canonical M32 surface. Every major DeFi protocol with a reported exploit in the 2022–2025 cohort had either no bug bounty program, an underfunded program (max payout an order of magnitude below funds-at-risk), or a program with discoverability and intake-friction problems. Programs scoped on Immunefi at appropriate maximum payouts (typically 5–10% of funds-at-risk, capped at protocol-treasury-feasible levels) convert oracle-manipulation, flash-loan, governance, access-control, and reentrancy classes into whitehat-disclosure outcomes rather than exploitation outcomes.
• OAK-T10.001 / T10.002 / T10.003 / T10.004 / T10.005 (bridge attack classes): bridge bounties typically command the highest critical-severity payouts in the industry, reflecting the concentrated dollar value at the bridge contract. The Wormhole $10M maximum bounty, established post-Feb-2022 incident, and similar large-cap bounties at LayerZero, Across, and other cross-chain infrastructure operators are the canonical reference. M32 at the bridge layer must include the validator-side / signer-side surface (T10.001) as in-scope, not just the contract surface; many programs scope only the on-chain contracts and miss the operational-key surface.
• OAK-T1.001 / T1.002 / T1.003 / T1.004 / T1.005 (token-genesis modifiable authority): M32 is structurally weak at the T1 layer because the launch playbook is fast (token-deploy to rug within days or weeks) and bounty programs require setup time. The mitigation is most effective for established tokens where the modifiable-authority surface is a recognised risk and the protocol has incentive to scope it; for ephemeral commodity-scam tokens M32 is rarely set up at all. Where M32 is run, scoping the modifiable-fee, modifiable-blacklist, and proxy-admin-retention surfaces explicitly is the calibration step.
• OAK-T6.001 / T6.002 / T6.003 / T6.004 (audit-trust evasion): bug bounty programs partially substitute for audit when an audit has not been performed; "audit-pending" claims (T6.004) are sometimes paired with active bounty programs as a transitional control. The structural risk is that bounty existence is invoked as audit-substitution at the marketing layer; a venue or aggregator should treat M32 and M16 as complementary, not interchangeable.

Limitations

• Scope is the binding constraint. A bug bounty program covers only the contracts and surfaces explicitly listed in scope. Out-of-scope surfaces — adjacent treasury contracts, dependency contracts, off-chain signing infrastructure, frontend domain — are not covered. Several major exploits in the 2022–2025 cohort were against surfaces that the affected protocol's bounty program had explicitly excluded. Scope completeness against the M05 authority-graph is the M32 calibration step.
• Maximum payout calibration vs funds-at-risk. A bounty program with a $50K maximum on a $500M TVL protocol structurally underprices the exploit. The whitehat researcher's rational decision is to disclose only if expected bounty value > expected private exploitation value. Underfunded bounties create an adverse-selection effect where only researchers with low private-exploitation capability participate; high-capability researchers route to private exploitation. The Immunefi-published guidance on max-payout-as-percentage-of-TVL is the reference.
• Intake friction and triage SLA. Bounty programs that take weeks to triage P0 reports, that require excessive proof-of-concept materials before engaging, or that have a documented history of disputing or underpaying valid reports leak credibility. The platform's enforcement role (Immunefi, Code4rena, Sherlock, HackenProof acting as escrow / arbitration intermediary) is load-bearing here; programs that try to run their bug bounty internally without platform-side dispute infrastructure routinely fail at the trust boundary.
• No coverage for off-chain operational surfaces. Bug bounty programs are well-suited to contract-layer findings; they are structurally weak at the operational-security layer (T11.001 vendor compromise, T11.002 wallet-distribution compromise) where the discoverable surface is not on-chain and the researcher's investigation surface is constrained by what the vendor exposes externally.
• Adverse-incentive cases. A bounty program does not eliminate private exploitation; it competes with it. In incidents where the researcher attempted responsible disclosure but the program disputed, underpaid, or delayed, the cohort has documented cases of the researcher subsequently exploiting the same vulnerability. The program's reputational discipline at the payout-and-arbitration boundary directly affects the disclosure-vs-exploit decision distribution.
• Contest model vs continuous model trade-off. Code4rena / Sherlock / Cantina audit-contest formats are time-boxed competitions over a frozen scope, structurally closer to M16 than to continuous M32; they catch findings during the contest window but do not provide post-deployment standing coverage. A protocol relying on contest-model coverage alone is exposed to the same point-in-time limitation as audit. The mature posture pairs contest pre-launch with continuous-bounty post-launch.

Reference implementations

• Platform-side infrastructure: Immunefi (the dominant continuous-bounty platform; multi-billion in protected TVL; multi-million critical-severity payouts at major DeFi programs); Code4rena (audit-contest model with whitehat-distribution payouts); Sherlock (audit-contest plus protocol-cover hybrid); HackenProof (continuous-bounty, broader-scope including infrastructure); Cantina (Spearbit-affiliated competitive-audit and continuous-bounty platform).
• Major program reference points (v0.1 OAK observation): Wormhole, LayerZero, MakerDAO, Aave, Compound, Lido, EigenLayer, and the major bridge operators publish maximum-payout figures in the $1–10M range for critical severity; these define the calibration ceiling for the rest of the ecosystem. The Polygon $2M payout (Oct 2021, double-spend vulnerability) and the Wormhole $10M payout commitment (Feb 2022) are canonical reference points for high-severity payout precedent.
• Severity rubric standardisation: Immunefi's vulnerability-severity classification system (publicly published, widely adopted) provides the cross-program rubric for impact-class definitions (critical / high / medium / low / informational) and for payout-tier alignment. The cross-program standardisation is what makes maximum-payout figures comparable across programs.
• Disclosure-coordination tooling: PGP-key publication, dedicated disclosure email / Signal channel, on-chain message-channel disclosure (post-Euler precedent — direct on-chain message to attacker address), and program-side acknowledgement SLAs (typically 24–72h on critical) collectively form the disclosure-pipeline reference architecture. The combination of platform escrow + clear severity rubric + fast acknowledgement SLA is the M32 mature-form posture.

Citations

• [immunefikream2021] — Immunefi forensic write-up exemplifying the platform's role as an industry-standard reference for incident analysis adjacent to its bounty operations.
• [chainalysis2024dprk] — broader cohort context for the post-deployment exploit cohort that bug bounty programs are calibrated to interdict before exploitation.
• [chainalysiseuler2023] — Euler March 2023 case; the on-chain disclosure-and-negotiation channel that emerged as a post-incident analogue of bug bounty disclosure when no formal program existed.
• [zhou2023sok] — academic taxonomy of smart-contract failure modes; supports the breadth-of-coverage claim that M32 scopes against.
• [slowmist2024report] — 2024 ecosystem aggregate including discussion of the bug-bounty-coverage gap across the rug-pull and exploit cohorts.