6. Economic Model6.6 Bug Bounty — Immunefi (5%)

6.6. 5% Bug Bounty (Immunefi)

The 5% Bug Bounty allocation formalizes the protocol’s commitment to proactive, community-driven security. Receiving 5% of the net fee distribution (equivalent to 0.015% of the winning bid), this fund is exclusively dedicated to rewarding ethical hackers and security researchers who responsibly disclose critical, high, or medium-severity vulnerabilities before they can be exploited maliciously.

Hosted on the Immunefi platform, the program operates as a continuous vulnerability disclosure program (VDP) that complements external audits, automated monitoring, and the Insurance Fund. By aligning financial incentives with proactive threat discovery, the protocol ensures that its cryptographic, economic, and infrastructure layers remain hardened against emerging attack vectors.

Core Allocation Mechanics

ParameterSpecification
Funding SourceNet Fee Distribution (5% of the 0.3% remainder after Keeper Bounty).
Allocation Rate5% of Net Fee (equivalent to 0.015% of the winning bid).
Distribution TriggerAtomic split executed during the submitResolution() or settlement phase.
PlatformImmunefi (Official Vulnerability Disclosure Program).
Usage PolicyStrictly limited to verified, in-scope security reports. Payouts scale with severity (Critical/High/Medium) per Immunefi standards.

Economic Flow Example

For an auction with a winning bid of 100 ETH:

  1. Success Fee (0.5%): 0.5 ETH collected.
  2. Keeper Bounty (0.2%): 0.2 ETH paid to the executor.
  3. Net Fee: 0.3 ETH remains for distribution.
  4. Bug Bounty (5% of Net): Receives 0.015 ETH. (The remaining 0.285 ETH is split among Treasury, Insurance, and Developer Grants).

️ Technical Implementation & Payout Workflow

1. Deterministic Routing (BugBountyVault.sol)

The allocation is mathematically enforced at the contract level, ensuring continuous vault accumulation without discretionary overrides.

// Conceptual Bug Bounty Routing Logic
function _allocateNetFees(uint256 netFeeAmount) internal {
 require(netFeeAmount > 0, "No fees to allocate");
 
 // Bug Bounty receives 5%
 // Calculation: (netFee * 5) / 100
 uint256 bountyShare = (netFeeAmount * 5) / 100;
 
 // Route to dedicated Bug Bounty Vault (Multisig/Immunefi Controlled)
 bugBountyVault.deposit(bountyShare);
 
 emit BugBountyAllocation(bountyShare, block.timestamp);
}

2. Immunefi VDP Integration

Payout execution follows a secure, multi-step verification process managed through Immunefi’s infrastructure:

  1. Discovery & Submission: Researcher submits report via Immunefi platform with reproducible Proof-of-Concept (PoC).
  2. Triage & Validation: Immunefi security engineers verify impact, scope, and reproducibility.
  3. Severity Assessment: Classified as Critical, High, or Medium per CVSS/Immunefi Impact Matrix.
  4. Payout Execution: Approved amount is disbursed from the BugBountyVault via governance multisig or Immunefi’s treasury bridge to the researcher’s verified wallet.
  5. Post-Resolution: Vulnerability is patched, audit matrix is updated, and optional responsible disclosure is published.

Severity Tiers & Scope Alignment

SeverityTypical ImpactPayout Range (Example)Protocol Coverage
CriticalDirect fund loss, SlashedPot drain, FHE.lte bypass, EmergencyHalt manipulation5,000 – 50,000+ USDCCore contracts, Proxy logic, Settlement routing
HighTemporary fund freeze, Keeper spoofing, AVS signature forgery, session key extraction1,000 – 5,000 USDCKeepers, AVS integration, ERC-4337 session management
MediumUI/UX manipulation, non-critical state bypass, logging of sensitive metadata250 – 1,000 USDCFrontend, Dashboard, Non-critical event emissions
Out of ScopeTheoretical attacks, social engineering, gas optimization, third-party API failuresN/ANexus Mutual, FHEOS uptime, Metamask UI, L1/L2 consensus

Security Note: The Bug Bounty program explicitly excludes “Funds Over Privacy” emergency triggers from bounty eligibility, as EmergencyHalt is a designed safety mechanism, not a vulnerability.

️ Security & Economic Guarantees

  1. Pre-Exploit Incentivization: By offering competitive payouts, the protocol ensures that white-hat researchers report vulnerabilities before malicious actors can discover and exploit them, reducing systemic risk.
  2. Scope-Driven Validation: Only in-scope, reproducible vulnerabilities are eligible. Theoretical, non-actionable, or out-of-scope findings are explicitly excluded to prevent bounty farming.
  3. Governance-Gated Disbursement: All payouts require verification by Immunefi triage + protocol multisig approval, preventing fraudulent claims or automated vault drainage.
  4. Continuous Hardening Loop: Every validated bug triggers an update to the Audit Readiness Matrix, Slither/Mythril rules, and CI/CD linters, ensuring the same vulnerability class cannot be repeated.
  5. Transparency & Trust: While researcher identities may remain pseudonymous, Immunefi’s public leaderboard and payout history provide verifiable proof of the protocol’s commitment to security accountability.

Audit Gate Compliance (P1 - Pre-Mainnet)

Progression to Mainnet deployment requires the Bug Bounty module to pass the following verification gates:

  • [] Deterministic Math Verification: Unit tests confirm (netFee * 5) / 100 is precise and handles dust correctly.
  • [] Vault Ownership & Access: owner() of the Bug Bounty Vault points to the Governance/Multisig address, not an EOA.
  • [] Immunefi Program Live: Official program page published with clear scope, severity tiers, and payout ranges.
  • [] Event Transparency: BugBountyAllocation event is emitted and indexed for every settlement.
  • [] Responsible Disclosure Policy: Published SECURITY.md and Immunefi VDP guidelines explicitly outline submission, triage, and patch timelines.
  • [] Zero Discretionary Overrides: No single address can sweep the Bug Bounty vault without multisig approval + timelock.

Unresolved Points & Explicit Gaps

Gap / Unresolved PointImpactCurrent StatusRecommended Action
Payout Automation LevelWill payouts be fully on-chain via Immunefi oracle, or require manual multisig execution?Docs imply multisig governance; on-chain automation not specified.Implement Immunefi’s Treasury Bridge or multi-sig automated payout router post-audit.
Severity Cap DefinitionsExact USDC/ETH ranges per severity tier are not codified in the KB.Mentioned conceptually; no fixed caps in P0/P1 matrices.Define explicit payout caps in docs/security/immunefi-policy.md and align with Treasury liquidity.
Vault Replenishment StrategyIf vault is depleted during a critical vulnerability surge before fees accumulate, how is liquidity restored?Not explicitly documented.Establish a Treasury-backed liquidity bridge with 48h timelock for emergency bounty top-ups.
Cross-Component ScopeDoes the bounty cover only contracts/, or also keeper/, frontend/, and FHEOS API endpoints?KB emphasizes smart contracts; infrastructure scope is ambiguous.Expand Immunefi program scope to explicitly include Keeper services, ERC-4337 session hooks, and CoFHE API endpoints.

Fact vs. Analysis Distinction: The 5% allocation rate, Immunefi platform integration, severity-driven payout structure, and governance-gated disbursement are verified facts from the official Whitepaper and Technical Specification. The exact payout caps, automation architecture, and infrastructure scope extensions are unresolved operational gaps requiring explicit definition before Mainnet launch.


Next Steps