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:
- 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.
- 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.
- < 30k
- Up to 30k
- Up to 50k
- Up to 70k
- Up to 100k
- .> 100k
0 voters