Proposal for a Bug Bounty

Written by @Crypterist @Nakamomo
A proposal to reward users who find bugs

Background

The Problem

Bugs are an inevitable part of developing new software products. Today, Inverse relies on internal and volunteer members of the DAO for software development; however, our internal quality assurance processes should also include a way to leverage the skills/resources from contributors who specialize in looking for security-related bugs. Keeping this QA process in-house also carries a high opportunity cost within our engineering team and regardless would require recruiting/ building specialized capability. One crypto industry norm is to offer incentives to appeal to white at code testers in order to encourage them to test Inverse’s smart contracts and other code for security and other vulnerabilities.

Bug Bounty Incentive Programs

A common solution to “bulletproofing” smart contracts and other open source software for crypto DAO’s is a bug bounty program. Any bounty hunter is one who studies our code and business from an adversarial perspective and can make use of their own tools and techniques to identify vulnerabilities in the lookout for a reward or a bounty… 3rd party platforms offer secure bug reporting processes (eg. Immunefi.com, 10% fee). Size of the rewards are based on the bounty’s vulnerability risk rank.

Benefits Of A Bug Bounty Program

  • Identify security-related bugs in a collaborative/friendly manner with white hat researchers
  • Highlights Inverse’s commitment to both security and transparency
  • “Checks a box” for partner and investor due diligence
  • As we aspire to grow to a business 1 Billion DOLA in circulation in 2022, emphasizing our commitment to mitigating risk is of paramount importance.

Costs of a Bug Bounty Program

Bug bounty rewards vary across DAOs. For example:

Name Critical High Medium Low Market Cap
MakerDAO 100,000 5,000 2,500 227,915,977
Olympus $3,333,333 677,344,667
Tokemak 20,000 209,537,167
Sushi 100,000 1,228,366,408
GMX 50,000 25,000 10,000 60,527,582
Spookyswap 50,000 15,000 762,819,332
Median 75,000 15,000 6,250 452,630,322

Bug Severity Examples:

Critical - Empty or Freeze the Smart Contract Holding, Holding Value at Risk

  1. High - Token holders temporarily unable to transfer holdings

  2. Medium - Contract consumes unbounded gas

  3. Low - Contract fails to deliver promised returns, but doesn’t lose value

Following 2 links give helpful information on Risk Rating and Severity Ranking of Vulnerabilities. OWASP Risk Rating Methodology | OWASP Foundation

Managing a Bug Bounty Program

  • One popular website used to post and organize bug bounty programs is ImmuneFi. It offers access to an army of whitehat hackers who hunt for bounties and who when they identify a vulnerability will let us know in a safe and secure workflow that is managed by Immunifi.
  • Crypterist will be managing the bug bounty program for Inverse. He was a Certified Information System Security Professional prior and is experienced working on Software Security and Risk Mitigation. He has worked with Auditors like Grant Thornton to put close to 400 Security controls in his earlier professional career. If a bug is discovered within the Immunifi community, he will help organize the internal effort to validate the alleged vulnerability/workflow, resolve the bug (if necessary), and work with the Growth Working Group (if necessary) should the existence of the bug become public and any external/public messaging is required.

Proposal

There are 3 Goals for this proposal.

1.To establish how much will we agree to pay when setting up a bug bounty
2. How will we pay once we receive the bug report
3. To fund an initial budget allocation for payment of High and Medium severity bounties

We propose the establishment of an official Inverse Finance Bug Bounty program. We will employ a 3rd party vendor for bug bounty services with the following reward rate guidelines:

Severity Critical High Medium
Rewards 50,000+ 5000 2500
  • Reward Payment in DOLA (approx 10% fee to the vendor)
  • 3rd party vendors take a fee in addition to the bounty (Immunefi charges 10%).
  • Critical severity bugs require a DAO vote and case by case consideration.

We consider bug bounties to be a lasting complement to any in-house security audit capabilities that Inverse Finance develops.

We request an allowance of up to $25,000 in 2022 for low or medium-severity bug bounties using an allowance for a SecOps multisig wallet.
Rewards for high or critical severity bugs will require a separate funding mechanism (e.g. from Treasury reserves) that would be requested on a case-by-case basis and which would require a GovMills vote.
Payout to white hats and vendors will be documented as Security Advisory Services to ensure that we don’t signal information of any adversarial attacks to malicious actors.

List of Smart Contracts Eligible for Bug Bounty Program:

Anchor Comptroller Bonds Manager Stabilizer
Treasury Xinv Manager DolaFlashloanMinter
Governor Mills xINV Oracle contract
Escrow INV All contracts used or authorized by on-chain proposals
Dola Fed Anchor Fuse Pool 22f
Policy Committee Fed Fuse6 Fed Scream

Other applications eligible:

inverse.finance website
AnchorPro

Items that are explicitly excluded from the bug bounty program:

  • Any testing with mainnet or public testnet contracts; all testing should be done on private testnets
  • Any testing with pricing oracles or third party smart contracts
  • Attempting phishing or other social engineering attacks against our employees and/or customers
  • Any testing with third party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
  • Any denial of service attacks
  • Automated testing of services that generates significant amounts of traffic
  • Public disclosure of an unpatched vulnerability in an embargoed bounty

Out of Scope & Rules

The following vulnerabilities are excluded from the rewards for this bug bounty program:

  • Attacks that the reporter has already exploited themselves, leading to damage
  • Attacks requiring access to leaked keys/credentials
  • Attacks requiring access to privileged addresses (governance, strategist)
  • Incorrect data supplied by third party oracles
  • Not to exclude oracle manipulation/flash loan attacks
  • Basic economic governance attacks (e.g. 51% attack)
  • Lack of liquidity
  • Best practice critiques
  • Sybil attacks
1 Like

Nice proposal. Some questions:

  • From standpoint of budgeting, what is driving assumption of scenario of 20-30 medium-severity (or all severity levels) issues booked? Seems quite high to me.
  • There is a range of payments amounts for each range - how is final payment amount determined?
  • For high- or critical-severity bugs what is process for determining reward? Is there a link to best practices we can adhere to?
  • How are payments executed? Via multisig? If so, which one? Our largest multisig is Policy Committee and while this kind of reward is outside the scope of Policy Committee responsibilities today, it might be the best interim place for this to reside.
  • Perhaps exclude partner implementations of DOLA lending via DOLA fed, e.g. Scream, from rewards.

Very interested to hear thoughts from @nour and @theAlienTourist on this.

#1. What is driving the assumption.

It is a ball park distribution to help us give a direction to Treasury.
Can there be more: Yes.
How can we best use the information: Prepare for the normal case so at least we are able provision for them. , we don’t pay if there is none.

#2.There is a range of payments amounts for each range - how is final payment amount determined?
Based on actual bugs booked and their severity levels. The range is to help us plan for Treasury Reserves.

#3.For high- or critical-severity bugs what is process for determining reward? Is there a link to best practices we can adhere to?

For Critical ,ImmuneFi recommends 10% of Value at Risk as a bounty (if a hacker can exploit 10 M then 1 M is the tipping point for him/her to do good). For High, we have analyzed bounties and have marked it to an affordable but an enticing level.

#4.How are payments executed? Via multisig? If so, which one? Our largest multisig is Policy Committee and while this kind of reward is outside the scope of Policy Committee responsibilities today, it might be the best interim place for this to reside.

We can do it via multisig. Also as we understand it can be in vested governance tokens provided it is within a reasonable period(say 6 months)

I made edits throughout the proposal after conversations with @crypterist and other core members. Please comment if there are any concerns.

isnt a third goal to fund an initial budget allocation for small bounties?

you mean “plus approx 10% fee to ImmunFi”

"creating an allowance for a new Security Operations multisig wallet within the Operations Working Group.

“Actual payouts to white hats/ImmuneFi will be documented publicly as Security Advisory Services (even to a white hat hacker) to ensure that we do not signal information that may assist future adversarial attacks to malicious actors.”

Thanks for the comments. I will amend the proposal.