1Hive Contract Bug Bounty Program Proposal

This post is to start a discussion around how we should structure a Smart Contract Bug Bounty Program. Note this is not for UI bugs but bugs that can break the expected functionality of the smart contracts.

Funding approaches

Since this is a DAO and the funds are communally governed I see two approaches to organising payments for a bug bounty program:

  1. Bug hunters could be paid via conviction voting proposals once the bug has been fixed, at the discretion of the community. However, note that due to the nature of conviction voting it will not be necessary for a majority of 1hive members to agree on a bug payout but only enough to pass the threshold of the claim amount.
  2. A pot of bounty funds can be created that is used to pay bug hunters at the discretion of the seed group members or a wider set of community members via a multisig.

The issue with the first approach is that there is more uncertainty for bug hunters whether they will get paid. The issue with the second approach is that it doesn’t involve the whole community where community funds are involved. Curious as to your thoughts regarding both approaches, please complete the poll.

  • Bug hunters paid by conviction voting at the discretion of the community.
  • Bounty pot multisig established, managed by selected members within the community.

0 voters

The proposal below is to be considered if we’re interested in the first approach.

Community funded bounties proposal

This approach seeks to determine fair and agreed upon requirements and rates for the responsible disclosure of bugs to the 1hive community. Once responsibly disclosed bugs have been fixed, payouts proposed by bug finders will be voted on by the community via conviction voting proposals. Therefore we must agree as a community to the requirements and rates of the bug bounty program to ensure that bug hunters get rewarded as expected. These requirements and rates are expected to be revisited and iterated over time.

Although payouts will be voted on by the community, bugs will still need to be disclosed directly to seed group members to deal with initially as exposure of the bugs to the community could risk them being exploited. The seed group members should therefore be trusted to make initial decisions regarding the severity of the issue and it’s likely payout. This must be considered when voting on bug payout proposals. As soon as the bug is no longer a threat, details about it will be released for the community to discuss.

Bug Bounty Program Proposal (in the doc)

To create the following bug bounty program I considered Uniswap’s program: https://uniswap.org/bug-bounty/ and the Aragon Network program: https://wiki.aragon.org/association/security/an_bug_bounty/ amongst others. It should be noted that these project’s contracts are audited. Many of 1hive’s contracts are not. For a note on audited contracts please see this separate post: A note on 1hive contract audits

Please make comments where you see fit so we can address them. And please highlight if you think option 1 or 2 for managing funds is more appropriate. Also vote on the max reward amount poll below, if you think some other amount should be considered please include in a comment.

Max reward amount (USD)
  • < 30k
  • Up to 30k
  • Up to 50k
  • Up to 70k
  • Up to 100k
  • .> 100k

0 voters

4 Likes

I think option 2 is more viable for the Bug hunters. Bug hunters will be more likely to try to find some bug if they know what kind of rewards they’ll get. You could categorize the bug depending on the critical vulnerability of it, which could be Critical / High / Medium / Low. The criticality of the bugs could be decide by the seed/fauna.

1 Like

Looks good I need to read this a bit more, but @willjgriff are you able to add a poll for the option 1 & option 2?

1 Like

I prefer option 2, but In terms of the amount to be paid for discovering bugs, that should go to a community vote.

I think a max 1 HNY for low impact/graphical bugs and a max of 5 HNY for serious bugs is fair. I think 50k for a bug no matter how severe is far too high and will invite bad actors to try and misuse the system

I prefer option 2 by far, mainly due to the insight @Felix gave above, if we intend for hackers to look for vulnerabilities in our system I think they will put more effort on it if they already know what they will be given if they success.

Regards, Aitor

I think the poll isn’t giving the community much of a choice since the community are forced to choose from either one of the choices, and the way i see it majority will tilt towards the second option.

I agree with the second approach but with slight modification.

  • Community will vote via poll on how much HNY should be in the bounty pot for starters (can be topped up as it dwindles via another poll or CV, that is of course if it dwindles).
  • A new swarm dedicated to this bug bounty is created made up of seeds or some community members or both.
  • Bounty rewards should be fixed but based on classes of bugs that would be established by this new swarm (eg. low threat, high threat, critical, etc) and any bug reported should be grouped into either of the class by this new swarm so that its appropriate fixed reward can be paid.
  • It will be at the discretion of this new swarm to determine the fixed reward which they feel is appropriate that will be accorded each class of bug. They would also be in charge of the bounty pot once funds have been sent to it from the common pool and will have the power to pay the bounty hunters from it.

I feel this will make the whole process more transparent and will enable the Hive maintain a more disciplined control over its expenditure. Also it’ll eliminate guess work on the part of the bounty hunters because they’ll be able to more clearly know their rewards which will encourage more spirited efforts.

1 Like

That’s fair, to anyone reading this, please also share your thoughts regarding reward amounts and vote on the recently added poll. However, see the point below regarding my opinion on the general value of rewards.

I disagree. Firstly this isn’t a proposal for rewarding the uncovering of UI issues. It is exclusively for contracts. Secondly 50k for uncovering a bug that has the potential to derail a technically multimillion dollar network, reducing its value possibly to zero, I consider reasonable. It shouldn’t be common that these issues occur, but if there is a possibility of them occurring we want to incentivise hackers to disclose them responsibly before they can be exploited. If the value of an exploit is much higher than the potential reward, there’s a higher chance that hackers will exploit issues without disclosing them. Also note, our contracts are not audited, most projects which offer similar bug bounty rewards are, for that reason I would consider making the rewards even higher than typical rewards.

3 Likes

Polls aren’t binding although without any alternative suggestions it is likely to have a high impact on the decision.

I think we can make a poll regarding the bounty pot amount once we’ve established that the bug bounty reward amounts are acceptable. I’ll include a poll for the max bug reward amount.

If we create a swarm I believe it should be primarily solidity engineers and seed members who have a good broad understanding of the technical structure of the 1hive network. It could also be bug dependant, the swarm could invite others in to investigate certain issues when they arise if necessary. I’m curious to hear from anyone who might be interested in being part of a bug bounty swam.

Please see and comment on the bug bounty doc. These classifications have been defined but I welcome suggestions on an alternative structure.

I agree. Thanks for the suggestions man.

2 Likes

I think a pot is a great idea we should not have to do conviction vote each time :roll_eyes:

Take a look at a post I did on polling suggestions as well as a link to MakerDAO polling guidelines.

The above isn’t why I am posting. I think the above topic of protocol or software bugs is important. I posted the above so we can get clearer polls that have abstain as a valid option and any costs to have a real range of choices including 0 as well as conditions for poll to close with a successful signal and subsequent actions.

I am posting because I had an experience with MakerDAO where I found a protocol issue that required me talking with someone privately to get it addressed. The point here was I found an issue if I made it public funds would have moved.

My question regarding bug reporting is whether we are going to have a means for people to submit these without doing it in full public view. The example is a bug that potentially compromises funds and then putting out the fix.

As specified in the requirements section of the Bug Bounty Program Proposal document, disclosure must be made directly to one of the seed members and evidence of disclosure to other parties will forfeit the reward. The means by which we receive this communication haven’t decided, open to suggestions. Most projects have a vulnerability disclosure email but we don’t have our own emails so either we must set one up or just trust any hacker is able to come to the discord and DM us.

I’ll add an abstain option to the above polls although it’s probably a bit late. I may also add a completion metric and or actionable result at some point. Thanks for the suggestions.

1 Like

Turns out I can’t change the polls now. I might create new ones, will see how this progresses.

Ah. I guess that kinda covers the point. Implied is this would be done via discord and to a seed role via a DM. One thing we had discussions on in MakerDAO was the concept of ‘secure’ communications as people can often ease drop which would lead to a secure information release. Something to think about is the size of the group involved as well as having multiple mechanisms for secure contact.

Your welcome. No problem on the whole - polling guidelines - I come from Maker and other places were we have had time to refine these with guidelines and rules so they are cleaner.

I consider this bug topic an important one that I would like to be able to talk about and then clear an action. I still need to read the document on this as well.

One thing I wondered is whether the people occupying seed roles will be available 24/7/365 (key bugs that could lose funds need to be addressed rapidly sometimes) and whether they all have technical expertise to verify a bug and then act.

I know a fair bit of work has gone on with the Maker smart contracts so pieces of the system could be halted if bugs or problems are found. I wonder if the same kinds of ideas - (designing systems so they could be halted with least amount of collateral system or PR/user damage) might be prudent as well. Fortunately 1Hive from the code perspective is somewhat more centralized than Maker.

I wanted to thank you @willjgriff for putting together the forum post on this important topic for the community.

One other question. If someone in 1Hive discovers an xDAI bug or problem who should we contact to have that communicated in a secure way to someone in xDAI community.?

I ran into that as well on the Maker forums. No worries if we need to do another poll we can.

This is why I initially suggest the seed group and more specifically the technical members of the seed group as we’ve worked together for long enough to know we can trust each other. I would be hesitant to divulge bugs reported to members outside of this group, before they have been fixed, unless absolutely necessary. I could be convinced otherwise but that’s my current opinion.

We won’t be but we’re pretty close to it. There’s about a 7/8 hour difference between both extremes of the timezones of the technical devs.

See this post: A note on 1hive contract audits it doesn’t go into detail but we have the ability to effectively pause conviction voting and the faucet if we need to.

It would be the xDAI guys, who though I’m not entirely sure, I imagine @lkngtn would know. My understanding of xDAI is relatively minimal so I’m unlikely to be able to address those issues.