[GIP-16] Bug Bounty Upgrade and 08.2022 Payout

This proposal is aimed at harmonizing and upgrading the bug bounty and consists of:

  1. Getting an approval for the bug bounty critical issue payout, discovered by an Immunefi whitehat in August 2022. The amount is $150,000 + 10% for Immunefi. The same proposal intends to grant ad-hoc power to financial multisig to grant bug bounty payouts in cases when developers overseeing the bug bounty program confirm & fix the issues if presented. That is, to avoid redundant governance voting procedures.
  2. The bug bounty program for V2 going further should be upgraded in order to adhere to the highest possible security standards. Payouts up to $200,000 USD +.

Part 1: August Bug Bounty Payout

On August 12.08.2022, all 4 Credit Managers were paused by the pause function - due to a reported bug on Immunefi. That happened quickly after developers confirmed the bug and tested the vulnerability. A week later (inexcusably long pause which should never happen again, especially as the protocol grows) - the fix was made, tested, soft-audited & deployed. The protocol was thus unpaused. Post-mortem is to follow soon, see Discord for more info.

As per the program details set up previously, the payout is:

  • $150,000 as CRITICAL ISSUE to the designated addresses confirmed by the whitehat: 0xEab01F3A309f680B08a28B9ED3aFF417ca0E4345
  • 10% of that is Immunefi’s fee aka $15,000 to the designated addresses confirmed by the Immunefi team: immunefi.eth

As the DAO now controls the protocols & all its operations, this vote is to approve the payout of the bug bounty as confirmed by the protocol developers. Next to that, the second part of the vote (1.2) is to allow financial multisig to release payments according to the bug bounty structure in cases when developers overseeing the bug bounty program confirm & fix the issues if presented. That is, to avoid redundant governance voting procedures.

Part 2: new V2 bug bounty structure

As the DAO treasury now has more funds, security spending could be increased in order to reflect the growing complexity of Gearbox Protocol. Current composition is:

Current Program:

Low: Up to $5’000
Medium: Up to $10’000
High: Up to $25’000
Very High: Up to $75’000
Critical: Up to $150’000

NEW Suggested Program:

Low: Up to $5’000
Medium: Up to $25’000
High: Up to $75’000
Critical: Up to $200’000

V1, as currently being unable to open new accounts or borrow more leverage - has very isolated risks, so does not need an upgrade. There are likely only a few weeks up until the end of September left when it would be functional (as the deprecation is already ongoing by Credit Account users). As such, the upgrade only concerns V2 once launched.

As V2 is deployed and is live, developers shall communicate the relevant scope (all protocol aspects) to the Immunefi team & update the protocol docs accordingly. The scope shall stay the same as V1 as well as the rules, while the contracts deployed will naturally be different.

PS: General Security Approach

Since we are on the topic of security, there are a few things non-dev community members & DAO contributors might want to point out and discuss. As you can see from the audits & spending, from the bug bounty and open approach - Gearbox previously as a team, and now as a DAO - spends a lot of time, efforts, and capital - on improving protocol security. That is, doing everything humanly possible to secure user funds and prevent hacks. However, no number of audits can ever guarantee full safety. As such, there are multiple concurrent programs live:

  1. Audits (V2 incoming) for every protocol update or new adapter implemented
  2. Risk Committee now also assisted by Risk DAO temporarily
  3. Multisigs with tech-savvy members across the globe and from different social circles, helping cross-check every transaction
  4. Automatic pause system able to pause (only pause) different protocol pieces
  5. Live bug bounty on Immunefi incentivizing whitehats
  6. Transparent communication throughout all updates & decisions (hopefully)
  7. Etc… please ask and suggest policies to be checked & implemented.

Let’s have this discussion for a few days, and then vote on the snapshot if we reach rough consensus at least on the first point as the whitehat is pending a payment. Other topics suggested can be turned into different proposals in next stages.

4 Likes

Hi @Van0k ,

Looking to Gearbox Bug Bounties | Immunefi
I can see the different numbers

Would be nice to have TLDR on Postmortem as a part of the proposal wdyt?

I also suggest to release a postmortem before releasing such a payment

1 Like

seems typo. anyway new limits seems good for me.

1 Like

My bad on this actually: the Gearbox docs version was made based on one example, while the Immunefi version only specify 4 tiers. In any case, given the most flow is via Immunefi - we should just stick to the 4 tier version as they are “up to” anyway. So the “NEW” plan seems to be fully correct then.

1 Like

I see thanks!
Can’t see a rationale behind the increase tbh. I mean, 150k to 200k rise doesn’t look big enough to make a difference for a whitehat. 150k to 1M would be substantial increase for instance, but 1M is too much for the treasury at the moment, of course. 150k to 200k looks rather like a marginal increase (no wow-effect anyway). I might be wrong though, did you get a request from a whitehat for the increase?

Also critical vulnerability spending (150k-200k) seems too big to spend without voting. Lower tiers (3k-50k) is ok-ish in that respect, but critical vulnerability should happen relatively rare, should’n it?

1 Like

So far the 2 reported were critical as they were literally “money pooef out of the system, huge losses”.

That’s afaik pretty much how it is defined in Immunefi and across the board?

But as for the increase from 150K to 200K… indeed agree it’s actually very marginal. Maybe just visually subjectively looks nicer & more serious? I really don’t have a good answer to this. From all the security discussions I have ever seen, whitehats either report or they fully take the $$ as blackhats as it will always be a few multiples above the payout. You can ctrl+f on some banteg messages in lobsters.

current update of limits can’t be applied to previous payouts ofc.

I see that the proposal uses the current limit for the payout, the corresponding increase (if it is approved by the dao) applies only to further ones.

My understanding is that we can stably increase this limit as our treasury increases.

I assume amantay meant for V2 itself, not in terms of V1->V2. He means numbers in general.

1 Like

Yeah, just not sure if 150k to 200k rise is making much sense. But I’m not an expert in bug bounties ofc, so might be wrong.

1 Like

Agree. I also have no clue :confused: Will see what others have to say.

not ok with increase, except the max ‘critical’ from 150k to 200k based on being a nice round number (just cosmetics).

second: your idea of complex protocol = higher bounty is flawed. Especially since it is more complex there will likely more bugs to be found, alias actually easier and more frequent bounties to expect. To have a what is the max ‘win’ of a hacker increasing increases changes to pull him on the right side.

Agree to this, increase is marginal and wouldn’t have that effect. Though, can we bench mark to other similar level protocols and see how much they payout? If 200K is higher and gets us the claim of the highest bounty paying protocol, still will be worth it

Seems like the second part needs more time for discussions. How about we move forward with part 1 of the proposal (and part 1.2 which puts the program into the DAO’s hands) - and leave part 2 for later?

Perhaps we should also include part 1.3 in here then: people who have the right to oversee bug bounty submissions. I believe it should be devs only: 0xmikko, van0k, apeir99n, and me (just to help coordinate with auditors and other community members when needed). CC @Van0k

1 Like

agree, let’s do it.

also agree to leave bug bounty program’s number the same as now. we can come back to this issue anytime later.

Maybe put 1.1 and 1.3 to a Snapshot for now? I don’t think 1.3 would be controversial, unless there are any other DAO members would want to also oversee this?

1.2 for “DAO takes over the program” is kinda 1.1 indeed. So idk if you wanna make it as 3 parts, as 1.1 kind of implies 1.2 to happen. Up to you how you wanna phrase that. AGREE!

Hey, regarding the postmortem:

Two auditors have softly confirmed the solution works, and we did internal testing - however, the fix was somewhat rushed, as we couldn’t keep the contracts halted for any longer (the market took a down turn, so there was risk of bad debt). The issue is very isolated and does not affect V2 at all, so the V1 fix is temporary before V1 is fully deprecated and V2 releases.

As such, we (the devs) would prefer not to post a detailed explanation and potentially open a several $M honeypot. We’ll get a full report from ChainSec soon, then we can be fairly sure that it is secure, so the post-mortem can be released publicly.

But meanwhile, the whitehat is pending their payment for quite long and it would be very unfair to them to postpone payment any longer, until we get all the audit reports back. So we’re moving forward with this now.

2 Likes