Create a mandate for the Tribe DAO to pay back any valid bug bounties in the scope defined below. This proposal also agrees to pay the most recent bug bounty highlighted here per this DAO agreement (1.1m Fei to the owed party).
Motivation
The Tribe DAO is growing faster than ever and shipping at unprecedented levels. While the DAO has extensive security precautions, its relationship with the white hat community has been extraordinarily valuable. It is more important than ever to grow and maintain this robust relationship with the white hat community.
This proposal intends to do so by creating a public mandate for the Tribe DAO to pay any valid bounty submitted through the Immunefi or directly to the DAO as per the guidelines on the Tribe DAO Immunefi page. It also creates the mandate to engage in surge pricing and to pay out 3x the respective bounties if any are submitted over the next two weeks ending Friday April 15.
Specification
In the future if any valid bug bounty is submitted the Tribe DAO will pay the bounty in full to the owed party(s). The respective rewards per bounties are distributed according to the impact of the vulnerability. The Immunefi page has more details on the classification of each tier.
Smart Contracts:
Critical Up to USD 1,100,000
High USD 40,000
Medium USD 5,000
Low USD 1,000
Websites and Apps:
Critical USD 15,000
High USD 10,000
Medium USD 1,000
Pay out 1.1m Fei to the individual who submitted the vulnerability highlighted above. Engage in surge pricing over the next two weeks.
Voting
The proposal will use simple choice voting. Voting options:
Yes, create this mandate and pay the most recent bug bounty
No, more discussions are needed
I’m in favor of this proposal with one caveat: I think the surge pricing should only apply to the “high” and lower categories. A payout of $1.1m should be sufficient for the critical categories, and surge pricing on this should we have 3-4 critical bugs clustered in some set of contracts could be very expensive to the Tribe DAO. @JackLongarzo thoughts on this?
Some of the DAO’s smart contracts contain billions of dollars. I come from the perspective that a critical bounty is definitely worth $3.3m. Other bug bounty programs, MakerDAO for example, have critical bounties at $10m. This temporary surge should help to get more eyes on the Rari and Fei codebases and attract more attention from white hats. It is unlikely that a critical bounty will be found, but in the case that it is I believe $3.3m is a small price to pay.
some of the DAO’s smart contracts contain billions of dollars
The total TVL of both Rari & Fei is less than $2bn, so I think the phrasing of “some contracts contain billions of dollars” is a bit misleading.
MakerDAO is much bigger than us. I’m fine with a temporary surge for all categories but critical, but the assumption that if we do so, we’ll only have to do a single $3.3m payout, doesn’t make sense to me. This could be several $3.3m payouts and total many millions of dollars - respectfully, doesn’t make sense to commit to this.
(Edit: if the surge pricing does end up being a controversial aspect, I would suggest we change voting to an approval-style with surge being one of the options. If I’m in the vast majority here in this concern then nbd)
Just wanted to drop by and express my thanks to the Tribe DAO on behalf of myself and everyone else involved in finding and reporting this.
However, I also wanted to propose a change to this FIP, which is to retroactively apply whatever surge pricing that the DAO ends up landing on to our bounty. I have two reasons for this:
We plan on splitting the bounty among ourselves and, to not beat around the bush, I want to look out for everyone (myself included)
It seems unfair that even though our report was one of the primary motivators behind the bounty program refresh, we’re not eligible for the bonuses that everyone else will be. Speaking more generally, this structure sets a precedent that a security researcher who has a valid report should hold onto it until some form of surge pricing is applied, because if they report it themselves then they won’t be eligible
I’m relieved that most of us learned about a critical bug from a FIP, not from a Rekt headline. $3.3m sounds like a lot of money, especially if we pay it multiple times for multiple critical bugs, but it’s an absolute bargain compared to the catastrophic impact of even a single exploit. Smart contract risk is the greatest threat to the protocol, and it’s worth perpetual investment. Let’s not be penny wise and pound foolish.
I support the 3x surge pricing and making it retroactive for samczsun.
First a tremendous thank you to Sam and the other security researchers highlighted in this post.
Noticing some concerns about surge pricing. To simplify everything and make the bounty more competitive, I propose a permanent 2x increase on the bug bounty that will retroactively apply to to the individuals who submitted the vulnerability highlighted above.
I think this is a great idea and fair outcome. I’m very open to being at the top of the charts for crypto bug bounties. In my eyes this is both the right thing to do and will likely have positive ROI.
Yeah, I like this plan a lot (of permanent 2x & no surge pricing), seems like a win-win proposal for everyone topping the charts for crypto bug bounties make sense because the Tribe DAO is managing a huge amount of PCV and user funds.
I believe the best way to move forward is to change the voting format and split this topic into two separate snapshot votes.
Vote 1
The first vote is on the DAO’s obligation to pay a minimum of a $1.1m bounty to Samczsun and others. Upon the acquisition of RGT the Tribe DAO became obligated to pay out valid Rari Capital bounties. There is obviously no option to not pay out this bounty, but there is an option to increase the bounty retroactively. This vote will be simple choice voting with two options.
Pay 1.1m to the owed parties
Pay 2.2m to the owed parties
I am strongly in support of doubling this bounty retroactively. The continued support and patience from Samczsun and other white hats involved in this bounty is a testament to their commitment to be active members of the Tribe. I believe this is a case where we should go above and beyond to return the favor, show our support to these individuals, and build a reputation for being generous.
Vote 2
The second vote will be about the future of bounties at the Tribe. This vote will be to create the mandate for the Tribe DAO to pay back valid bug bounties per the Immunefi scope. Bug bounties will be paid by the DAO and enforced by the Tribal Council. Per the governance structure implemented in FIP: 82 the DAO will always have the ability to veto any decisions made by the Tribal Council. This vote will use approval style voting and have three choices.
Pass the proposed bounty program with current bounties (1.1m for a crit)
Pass and double rewards on the proposed bug bounty program (2.2m for a crit)
Continue discussions
If either option 1 or 2 passes, the DAO will assume the obligations of the new bug bounty program and the Rari Capital and Fei Protocol individual bug bounties will be deprecated.
I’m looking forward to hearing the community’s thoughts on these two votes and continuing to promote healthy discussions and decentralized governance within the Tribe.
I will be strongly in support of paying out 2.2m in Vote 1, as it’s an industry standard payout based on funds at risk, well worth it to ensure that the Tribe’s 700m+ PCV will benefit from white hat actions in the future.
Regarding number two, also in favor, even a MakerDAO tier of 10m bounty for a critical vulnerability affecting all system funds would not be excessive in my view.
There is a world where Vote 1 passes with option 2, and Vote 2 passes with option 1, which would be weird. Maybe wait for end of vote 2 before posting vote 1.
I’ve considered this possibility but think it is unlikely. In the strange that it did occur the DAO would execute a one time 2x bounty payout and commit to paying 1x bounties in the future. I do however doubt that this will happen as it is likely only a subset of voters for option 2 on vote 2 will vote for option 2 on vote 1. If this is a major concern I can post vote 2 first and then subsequently vote 1 if vote 2 passes with option 2.
I agree that likelihood of contradicting proposals passing is small, but I don’t see any downside to doing vote 2 first and then vote 1 as JackLongarzo and Eswak suggest.