Request for Comments: Immunefi Bug Bounty Process and Ownership

[Luna5]

This post is aimed to open a discussion about our Bug Bounty processes and the ownership of the different tasks and steps involved in it.

Our Bug Bounty program was approved by the DAO in TIP-041, (Snapshot vote). The DAO, for the purpose of creating a Bug Bounty program, choose to partner with Immunefi. This program was established in Q1, 2023 and officially launched April 28th, 2023. You can visit our program dashboard with Immunefi here: https://immunefi.com/bounty/thresholdnetwork/

From its inception, Threshold’s Integrations Guild Committee was set to own the task to launch and manage the program. During these initial months, several Threshold contributors, the IG and the PM have worked with the Immunefi team to adjust and update the program, introducing lessons learned from the many use cases we have discovered as we go.

Now, as we consolidate our knowledge, we need to step back and create an internal process for us to follow that conveys all these lessons learned, and that makes us all more efficient when dealing this this program:

• Point 1 for discussion: the creation of a Threshold subcommittee of experts, to handle economic assessment with the whitehat hackers, once a bug report has been validated and the impact and severity of the bug have been classified and confirmed. As you can see in our program, each impact has reward range according to the severity and the aim of the threat, the role of this subcommittee would be to assess the exact bounty for each case.

• Point 2 for discussion: Payment execution and holding of funds. As you can see in our Immunefi dashboard, rewards range from $1000 to $500K. We need to earmark funds for paying small bounties and we also have to contemplate the bigger expenses. An earmarked budget can remain within the ownership of the IG, the TG or the Threshold Council, to cover the bounties marked low-medium-high, but we need to decide on the selected body to hold the funds.

• Point 3 for discussion: a possibility to better manage our funds for the higher bounties is introducing an on-chain ratification process to pay critical bug reports that range from $100K to $500K. In this scenario, it would the DAO who makes the payment transfer, instead of maintaining a high amount of funds in one of our Threshold Guilds or Council. This proposal contains a double challenge: (1) the transfer needs to be ratified by the DAO, where our delegates need to agree to vote unanimously to support the transfer payments, which have been agreed beforehand as part of the Immunefi program. (2) the introduction of our on-chain governance delay exceeds the standard SLA time that Immunefi establishes for all bounties, and we would need to make this explicit as part of our Bounty Program, with the disadvantages it may bring.

I would love to hear from our many contributors on these topics, and learn what would be the best way to continue working with the Bug Bounty. Thanks a lot!

[Naxsun]

Thanks for this summary Luna!

• Point 1 for discussion: the creation of a Threshold subcommittee of experts, to handle economic assessment with the whitehat hackers, once a bug report has been validated and the impact and severity of the bug have been classified and confirmed. As you can see in our program, each impact has reward range according to the severity and the aim of the threat, the role of this subcommittee would be to assess the exact bounty for each case.

100% on-board. The initial assumption has been that this would be the TIG, based on an economic impact assessment from the white-hacker & contributors. It makes sense to make this a more cross-functional / cross-guild group.

Another factor to take into account here is that these negotiations can / typically take place in parallel to a containment and/or permanent fix to be in place. Furthermore, in order to assess the impact a certain amount of information regarding the report.

Up to now we’ve decided to make the group in the know on report details as small as possible, on a need to know basis. Where the ‘need to know’ is defined as being able to technically assess the report, and to define and implement a potential containment and fix.

Currently the TIG doesn’t get the report details, until the program admins have decided to share the report.

This new subcommittee would likely need to become program admins as well, which means they would receive each report at the time of submission similar to the contributor teams. I’ve heard the suggestion to make this 1 TG committee member and 1 TIG committee member, and I think this could make sense.

• Point 3 for discussion: a possibility to better manage our funds for the higher bounties is introducing an on-chain ratification process to pay critical bug reports that range from $100K to $500K. In this scenario, it would the DAO who makes the payment transfer, instead of maintaining a high amount of funds in one of our Threshold Guilds or Council. This proposal contains a double challenge: (1) the transfer needs to be ratified by the DAO, where our delegates need to agree to vote unanimously to support the transfer payments, which have been agreed beforehand as part of the Immunefi program. (2) the introduction of our on-chain governance delay exceeds the standard SLA time that Immunefi establishes for all bounties, and we would need to make this explicit as part of our Bounty Program, with the disadvantages it may bring.

Here I have different thoughts, and in any case this would be a significant change to our bug-bounty program.

• Delegates vote according to their own judgement, and anyone / any address can be a delegate
• Hence, with delegates you can’t make a pre-agreement that the delegates would 100% follow the recommendation from the sub-committee.
• The aforementioned sub-committee would imo need to receive the authority to lead the negotiations with hackers, and have the mandate to decide on the compensation

By having the transfer of compensation amounts go through governance votes, we’d imo be basically transferring the economic negotiations between hacker and DAO up to governance. The sub-committee could in this case come to a pre-alignment with the hacker, and a recommendation to the DAO.

Outcome would be something like: ‘The hacker and sub-committee have decided to propose a compensation amount of x T tokens’

For delegates to decide whether they agree with a compensation they’d likely need report details, which often can’t be disclosed while the report is still being worked on.

Overall this would make our bug bounty program less attractive, and with much more uncertainty and hassle for the hackers imo.

I would think the funds for the bounty would be in custody by the Council. Potentially we can utilize these funds as POL. It is also an option to assess changing our program details from compensating in T tokens to any other asset, e.g. tBTC.

In this case there would be a periodic (quarterly?) DAO vote to approve the budget for the bounty program. E.g. the DAO approves a total allocation & reserve of ‘x amount of’ for bug bounties for Q2, unused budget will roll over to the next quarter.

If the DAO no longer approves the budget, the program would stop.

[davidnunez]

Thanks @Luna5 and @Naxsun for taking the lead on this!

Some comments:

• DAO should allocate a global rolling budget for bounty rewards, say e.g., to be able to cover a certain amount of critical, high, medium and low reports. Deciding how many of each is up for discussion. This budget should be topped up as needed, ideally as part of the guilds & council regular budget requests.
• With our short experience with Immunefi, we have already realized that we need to be pretty agile with respect to payments. I personally think that some guilds like the IG are better positioned for this than the Council, so I’d suggest that reports medium or low (which statistically are more frequent) should be handled directly by one of these guilds. High impact reports, on the other hand, are less frequent and imply bounties up to $50,000, so it’s likely that some of them (and of course the Critical) should be managed directly by the Council. This implies that part of the budget for bounties would be allocated with the IG, and the rest with the Council.
• I think that the involvement of someone from the IG in the proposed Bug Bounty Committee is enough.
• Re: point 3, I agree with Nax. Funds for bounties should be always be available; DAO votes could be required to top up the budget, but not for paying individual bounties. It would be responsibility of the IG and the Bug Bounty Committee to monitor the budget and request top ups.
• I also agree that putting this funds as part of POL is valid, but special care must be taken due to smart contract risk and impermanent loss.

[ben]

I agree with the approach of having IG handle small payments and council handle the larger bounties mostly because the guilds have had more signer turn over.

[derek]

It makes sense to me to have the IG multisig handle the payouts for the non-critical bugs. So we could use some sort of heuristic by assuming:

• 2x High (2 x max $50k) = $100k
• 3x Medium (3 x max $5k) = $15k
• 5x Low (5x max $1k) = $5k

Total = $120k
+
Immunefi fee % (for each)- which I believe is 10%.

=
$120k * 1.1 = $132k

Of course this calculation can be fiddled with.

---

The big concern is with the potential max $500k payout for Critical bugs. The total amount allocated for one of them would be $500k + the $50k Immunefi fee, so it is $550k that is needed.

(1) the transfer needs to be ratified by the DAO, where our delegates need to agree to vote unanimously to support the transfer payments, which have been agreed beforehand as part of the Immunefi program. (2) the introduction of our on-chain governance delay exceeds the standard SLA time that Immunefi establishes for all bounties, and we would need to make this explicit as part of our Bounty Program, with the disadvantages it may bring.

I get the concern for (1), but it’s unclear whether it is in the best interest of the members of DAO to not ratify the payout for the bug. The reputational fallout for Threshold as a whole would not be great; the whitehats can publicly publish their findings.

I think I’m less concerned about the governance delay for (2), but perhaps I’m misinformed. My impression was that Immunefi indeed had a standard SLA timeframe, but that modified agreements could be formed directly with the whitehat and Immunefi for payments if needed. I mean $500k is not a small sum, and I don’t think it is unreasonable to expect some delay.

Also, we are making an important underlying assumption that there will only be one max-level Critical bug payout at a time, which could be a reasonable assumption to make, but we still wouldn’t have any recourse if there happens to be more than one around the same timeframe.

So I think either way we need to have an out in the worst case, which we don’t have right now. Regardless of what we decide, the bug bounty program document should probably state that there may be a governance ratification and associated delay for larger payouts for Critical bugs. Note the range for Criticial bugs are $100k - $500k.

The POL point is an interesting one counter to just having a large amount of funds sitting idle in a multi sig, but I agree with @davidnunez here that the smart contract risk and impermanent loss risk are worth considering. Allocating those funds is essentially perpetual and we don’t know when/if this payout ever has to occur.

Perhaps the IG allocation can be structured to provide some buffer for the POL for at least the impermanent loss risk. For example, you could increase the allocation to the IG say ~$200k (up from the $132k mentioned earlier) and then utilize ~$300k as POL, so that if a Critical bug report is filed that warrants a larger payout, the POL could be used to potentially do the payout, with the IG funds providing an additional buffer that may/may not be used. If the payout is too large, then go through the DAO vote.

Funds can be appropriately topped up again after any payouts.

[Eastban]

Thanks for setting this up @Luna5 !
I agree with Nax and David.
To your points:
Point 1: Agreed.

Point 2: IG handling smaller bounties sounds a good idea to me.

Point 3: Council handles POL on the amount of roughly $ 3m. Having 500k more in it wouldn’t make any difference (riskwise) imo.

Adding this $500k POL to the 80%T/20%ETH pool on Balancer will lower at lot the IL problem while generate income from LPing. And can be retrieved via 2 fast tx’s. And we wouldn’t jeopardize our Bug Bounty agreement by being late for payments and even risking delegates not ratifying something already agreed upon on.

[Luna5]

Hello everyone, I would like to thank you for your valuable feedback and insights on this topic.

This is a summary post that compiles the information and comments received for the Bug Bounty process both coming from this governance forum and from the Treasury Guild and Integrations Guild meetings.

Agreements reached with regards to the three points for discussion:

• Point 1 for discussion: the creation of a Threshold subcommittee of experts.

  • We have agreed to create a subcommittee for the Bug Bounty to manage the economic assessment and own the conversations with Immunefi and the different whitehats as representatives of the DAO. This subcommittee would be preferably composed by a member of the TG and a member of the IG, selected or volunteered for the task. These members need to be onboarded within the Immunefi dashboard for Threshold and maintain a fluent conversation with both the Immunefi team and the Threshold group of experts in charge of the technical assessment of the escalated reports.

• Point 2 for discussion: Payment execution and holding of funds.

  • We have agreed that Threshold’s Integrations Guild will maintain $200k in T as a budget earmarked for bounties in the range of Low-Medium severity levels.
  • Additionally, the Threshold Council will maintain a budget of approximately $300k as part of the project’s POL or as part of a diversification strategy guided by the Treasury Guild. This budget would be added to the IG budget to cover those High-Critical bounties, that according to our program range from $100K to $500K.
  • Monitoring of expenses: the Immunefi Bug Bounty expenses will be closely monitored by the Treasury Guild, it is necessary that the Bug Bounty subcommittee notify the TG of the status, preferably providing a monthly report.
  • Top up process: the funds will be topped up as part of the quarterly / half year budget request the guilds submit to the DAO. However, if there are many expenses, or the price of the T token drops significantly, an additional top up will be considered and discussed with the TG when the IG funds reach 60% of the initial budget.
  • Additions to the program: the addition of new code to the scope of the Bug Bounty program is likely to increase the amount of bug reports for Threshold, therefore this circumstance has to be considered to verify if an additional top up of funds is needed.

• Point 3 for discussion : introducing an on-chain ratification to pay critical bug reports.

  • The introduction of an on-chain ratification as the sole tool to create the payment for critical bug reports has been rejected due to very reasonable arguments against it (see comments in this thread). However, in order to better face the payments for bounties in the higher range of our program, i.e., $100K - $500K, the introduction of a budget request via Governor might be needed. Reasons for this need would include budget overrun within the IG, T price drop, etc.
  • For transparency reasons, the Immunefi Bug Bounty description for Threshold will be updated to include a warning for whitehats, to consider that for high-range bounty payments Threshold may exceed the SLA established by Immunefi. Thus the payment for these High-Critical bounties will be delayed by a few hours or days to allow our process of governance to complete the required budget for the payment, which currently is approximately 14 days.

I hope this post has conveyed all that was discussed in our different meetings and forum. All questions and comments are welcome in order to better establish a process for the management of the Threshold’s Bug Bounty.