[RFC] Establishment of a Bug Bounty Program

2. [RFC] Request for Comment
#1

[RFC] - Establishment of a Bug Bounty Program:

  • Establish The Bug Bounty Program
  • DO NOT Establish a Bug Bounty Program
  • Other (please comment)

0 voters

Name: [RFC] - Establishment of a Bug Bounty Program

Scope: Bug Bounty Programs are one of the best ways to secure projects. This proposal shall lay the foundation for a Bug Bounty Program that will protect and reduce vulnerabilities within our project, through reward of skilled white-hat analysts.

Link to previous [DAO Discussion]: “[DAO Discussion] - Bug Bounty Program”

Objective: Protect Treasury Assets through rewarding white-hat hacking and analysis.

Provide a High Level Overview: Rewarding white-hat hacking and analysis of our project through assets designated in the treasury: we can reduce the risk of black-hat hackers who could steal or wreck us way worse. This is done by establishing a reserve of MIMs used only towards fulfilling bug bounty payouts.

Provide Low Level Details:

Section A (Reserve Basics)
  1. Treasury Managers shall be responsible for ensuring a bug bounty program fund is reserved and slowly accumulated in the treasury. This reserve shall house a maximum of $200,000 and a minimum of $500. The recommended reserve amount is 30% of the maximum.
  2. The reserve maximum shall increase automatically by 10% annually, each month.
  3. The reserve minimum shall increase automatically by 2% every year.
  4. The reserve shall be comprised of Magic Internet Money (MIM), unless an exception is triggered.
  5. Treasury Managers shall delegate the reserve in full towards any form of “safe” stablecoin farming to slowly grow/maintain it.
  6. This reserve may be held in a separate wallet from primary treasury assets, as long as it is published.
  7. In the event the reserve is below its minimum, the bug bounty program shall be halted and no payouts will be permitted.
  8. The Treasury Managers may decide by a majority to raise the treasury maximum if necessary for the program to work properly. The Treasury Managers may also decide to do a maximum based on a percentage of the average treasury holdings, as long as that result is over or equal to the current hard maximum established through the DAO.
  9. All privileges provided in this proposal towards Treasury Managers can be executed by DAO vote.
Section B (Reporting Requirements)
  1. In times of high volatility, or where otherwise deemed appropriate and necessary by Treasury Managers: The bug bounty program reserve may be emptied to the minimum reserve amount and put towards other matters. This includes any infrastructure/contracts required for the bug bounty program.
  2. It shall be the responsibility of Treasury Managers to notify the public within 24 hours if this reserve is emptied to its minimum or less; and reasoning behind such.
  3. All payouts from this reserve shall be maintained on a public spreadsheet or otherwise publicly viewable ledger. Specific details of the vulnerability do not have to be released until it is patched; or work with the white-hat has ceased.
  4. All persons and organizations seeking benefits from any sections of this proposal must be in good standing within the Wonderland and Crypto community as a whole.
Section C (Min/Max Payouts)
  1. Payouts for successful bug bounties shall be determined on a case by case basis by Treasury Managers. However, successful bug bounties shall be rewarded with a $5 minimum, and $25,000 maximum. This maximum shall increase 5% per year.
  2. No individual or entity shall be awarded more than 25% of the current reserve maximum every year.
  3. No person that is a Treasury Manager, or with any financial powers delegated within Wonderland, shall be eligible to receive bug bounty reward payouts.

Business and/or technical requirements of the implementation of the proposal:

  • If a bug bounty program is established, Treasury Managers shall be responsible for controlling or delegating the program, faithfully as established by this proposal and in ways it shall benefit Wonderland. The program managers shall be responsible for privately examining bug bounty claims from white-hats and determining its severity and reward consequently.
  • No funds shall be paid out without approval of the Treasury Managers, despite who is decided to be responsible for the program.
12 Likes
#2

So far i dont think there is a problem, but with more time and if new code its added (it will probably happen) we could have this bug bounty program up for a certain period of time, so things like what happened with the fantom and tomb LP in grim doesnt happen, they were audited for the exact same problem they got exploited, becase of new code (i believe it was like this correct me if im wrong).
Also audits arent cheap, so if we want to make some audits because of new code that we dont know it can be problematic or not we might be using a lot of money that it may be not necesary? like, obvisouly securing wonderland its a top priority always but we might be able to do it ourselves with the bug bounty

4 Likes
#3

That’s a logical step for any serious projects. I don’t know any Olympus forks with such a thing, even Olympus doesn’t have a bug bounty program imo. It will help us to get #1 in this space in terms of security! Easiest vote i’ve ever made so far!

5 Likes
#4

I think Klima DAO has actually introduced it last month, but their bounties are up to $500k, which is pretty cool.

Totally agree that the bounty program is needed for the longevity of the protocol, even if it costs more than what is currently laid out in the proposal. As long as the program protects the main funds in the treasury for everyone.

4 Likes
#5

In the long term run, especially when new code will be added, this can be a crucial point.

This crypto and defi space is well known for all the hacking which have been done and every week new ones come. Use a part of Dao’s fund to keep the best security on the space is an incentive to invest even more.

Maybe I’m lacking in knowledge about this argument, but to me the security of the protocol is one of the most important point.

2 Likes
#6

So who do you mean when you say “Treasury Managers” ? Sifu ? Or the team in general ?

Not sure I would put the treasury managers in charge compared to a dev that may be better equipped to judge the importance of the bug ?

I’m ok with the team delagating to whoever they feel is best. I Just think the “treasury managers” wording is weird.

When you say no fund can be paid out without the treasury managers, do you mean they have a say on the amount ? Or only confirmation/approval of the payment like the multisig ?

2 Likes
#7

Sifu and Daniele, the people actually making the calls with what is done with the treasury.

They have to agree that it’ll be paid out: amount, conditions, etc.

1 Like
#8

Using an established bug bounty platform may be helpful to us as well. An example: Immunefi

Search for “DAO” to see how others are using it.

#9

I think this is a great idea. Especially since this is literally a digital treasury, you probably have thousands of hackerz trying to find way in.

#11

Yup agree 100%. Bounty programs are always a good idea, it increases the security of the project.

2 Likes
#15

No brainer. I’m open to making the bounty more competitive (ie., higher) as an incentive.

This RFC gets a strong yes from me.

#16

Frog eating the flies. Needs to be rewarded :slight_smile: Easy yes. Would like to have more structure in this proposal. How will the bounty be paid out, who will verify the recommendations? Seems like there needs to be multiple things in place to get this going and this proposal is still not so detailed.

#17

Finding and preventing exploitation of software bugs is necessary. The bigger issue is finding & preventing exploitation of fundamental structural flaws in the financial structures and investments of Wonderland.

#18

What about people who been hacked?

#19

This is a really good idea. I think we need to refine the details before promoting this externally, assuming it passes through governance. For example:

  • What is in scope for bug bounties?

WL Contract?
WL Website?
Discord Bots?
Forum Website?

  • What are tangible examples of security vulnerabilities that would warrant a full 25k$ payout vs a 5$ payout, and as many examples in between?

This is important to be up front about as we want to be as transparent as possible to those who will be probing the platform for vulnerabilities.

  • Georgiy (or another dev on WL payroll) needs to be briefed on this, as they will definitely need to contribute to the review of the bugs discovered and the payout this qualifies for.

In addition to this, there needs to be an understanding that all Severity 1 bugs discovered must be corrected within a pre-determined number of hours.

I like the forward thinking, but this adds operational requirements I feel are going to be a pain point to maintain in the short term. Any time something is not followed to the letter, we generate frustration within the community and lack of trust in the protocol. I would keep it as simple as possible and simply advertise what intend to payout following the discovery of a bug.

Is this really necessary?

Not sure that I would go in this direction personally. Imagine a situation where we halt the program and a Sev 1 bug is discovered which could tank the value of the entire platform.

  • Best case scenario, the discoverer simply waits until the bug bounty program re-launches to raise awareness to WL - leaving us exposed for however long this process takes.
  • Worst case scenario, this information is used for nefarious purposes.

I would argue that no one on WL payroll should be able to benefit from this program. The conflict of interest is obvious here.

I would add a few points here:

We need a way to ensure that bugs discovered and payouts performed are documented and published somewhere for the public (WL Community and hopeful bounty hunters) to see. This increases transparency by demonstrating visible follow-through on the payments, as well as the corrective actions taken by WL. A simple table format somewhere would suffice.

We need to establish expectations with our dev team on how quickly a Sev 1-2-3 bug must be fixed (or a workaround put in place) after reporting. This is something that needs to be taken seriously.

We need an agreement on how the payouts will take place. Perhaps the payout is performed once a workaround or fix is in place? Perhaps the payout is performed immediately following the validation of the bug?

We need a process in place to manage submissions that occur in close proximity - i.e. submitter A shares their findings at 1am submitter B shares the same findings at 2:30am before the protocol has an opportunity to review. Do we want to reward only submitter A or do we want to reward submitter A & B for the full amount? Do we want to split the rewards between A & B? What if something obvious is found and we have submitter A, B, C, D, E, F, G all share their findings in the same 24 hour window?

Once we agree on how to handle these, this needs to be part of the process we expose for this program.

We need people within WL to manage this process. This isn’t something that should fall under the scope of the TM. The TMs role in this is simply to perform the payouts.

I’ve made comments elsewhere about the need for a professional ops team to handle the day-to-day of WL before - this program would clearly fall under the responsibilities of this team. We don’t need to burden Dani or Georgiy with this responsibility; I believe that defining those responsible for this is a pre-requisite prior to us being able to successfully deploy this.

#20

Anyone (including you) who would like to continue governance on this is free to.

I no longer have any financial interest in wonderland, so thus not affiliated with governance.

1 Like