TIP-041: Establish a bug bounty program

Thank you for the proposal @Mr_T.

I completely agree that we need a bug bounty program and am eager to hear from others in the community about their thoughts on this proposal.

Tagging a few contributors to get the ball rolling faster :slight_smile: @jakelynch @JohnPackel @Eastban @Naxsun @Agoristen @PintSizePorcupine @beaushinkle @mhluongo


Agreed on the benefits of this, and thanks for proposing this @Mr_T

These are off-course high numbers, but I believe this is common. It also needs to be seen in the light of potential impact.

  • No bugs found → no cost
  • Bugs found & fixed → cost. But also protecting Product & Project reputation & Users with potentially much higher value.

I have no experience on platforms and height of bounties, and hope the developer Contributors are able to share their thoughts here.

Separate note:
I don’t know if this is already defined, or if this is already planned to work on by others.

If not: I would be able to take charge on listing out a process: e.g. how is a bug reported, to whom, triage & categorization (critical, high etc), patching, disclosure, post mortem, Immunefi (or other) onboarding etc.
Would ofc need to strongly rely on inputs of the experts here, but would be able to tie the pcs together.

Also would like to note that I have no experience here, so there could be more qualified people.


Thanks, @Mr_T. I agree this is important to establish. Andreas Antonopolous made a point in an interview years ago that has stuck with me (paraphrasing): you know a system is secure when there is a large financial incentive to hack it and no one succeeds. If we have a vulnerability our audits didn’t catch we don’t want to find out the hard way, as this could severely damage the Threshold brand.

These incentives look reasonable to me, but will defer to others with more experience with bug bounties on the question of the amounts to offer.


This proposal has been moved to Snapshot


GM @Mr_T !
I would like to invite you or a representative of you, to an Integrations Guild meeting in order to define a strategy for the execution of this proposal.
Meetings are held in Discord in the Hangout voice channel, Tuesdays at 1pm ET.
If you are not able to join a call, or prefer to discuss this async, please drop us a message at the Integrations Guild channel, where we will create the appropriate infrastructure to execute the proposal.

We are willing to join an IG meeting, however, we are currently blocked from joining the server due to the phone number requirement.

Proposal passed November 16th, 2022.

Hello @Mr_T, the Snapshot has passed, congratulations to all!

Additionally, the Discord server’s configuration has been modified, so you would be able to join now.

1 Like

It appears Discord as a platform is requiring phone number verification, and it was not the Threshold server. In the interest of making progress, let’s continue the conversation here until we’re able to come up with a solution.


Thanks for taking the time to create this proposal @Mr_T !
What in your mind is the next step now that it has been approved by the DAO - Would you like to take the lead on establishing the Immunefi program, or should this be initiated by the TIG? We are excited to have you in our community and look forward to the future!

1 Like

Welcome to Threshold Network — thanks for contributing!

  • Be kind to your fellow community members.
  • Does your reply improve the conversation?
  • Constructive criticism is welcome, but criticize ideas, not people.

For more, see our community guidelines. This panel will only appear for your first 2 posts.

Apologies for the late response - one other thing to add here is that auditors who have worked on the protocol should not be eligible for a bounty. I echo @Naxsun’s sentiment on clearly defining how bugs are reported and who determines the severity.


Thoughts on this kick-off question from @ZeroInFo56, @Mr_T?

@Naxsun and the integration guild owning this is appropriate.

Registration appears to be straightforward (link), the guild needs to onboard directly with the Immunefi team and there isn’t any upfront deposit required.

Threshold has an established Security Policy (link) and vulnerability disclosure contact email (security@threshold.network) that can be used for reports.


Confirming here that the TIG & @Luna5 will pick this up.

We’ll come with a plan & milestones and share it here to collect feedback.


Thank you, @Naxsun and @Luna5! :raised_hands:

Hello everyone,

through the process of onboarding with Immunefi, the integrations guild has a question related to the cap budget to the bug bounty program. Is there a maximum allocation to the program? Should it be defined? I would like to request your comments and feedback on this topic.

Thanks very much.

IMO: the Critical category cap should be phrased as $500k+ which indicates there’s a soft allocation cap of $500k that can be raised at the DAO’s discretion.


I would agree - since the risk of a crit on our most valuable exploit is theoretically unbounded in terms of EV for a hacker, we should have a very compelling bug bounty for crits. Typically, to find the right number you have to weigh the two options subjectively:

Option 1: Exploit the Vulnerability
Value Captured: >50% of the Mkt_Cap(TBTC)
Cons: This money has to be cleaned. This is challenging and, outside of Lazarus Group, can be a huge deterrent.

Option 2: Redeem the Bug Bounty
Value Captured: Value(Bug Bounty)
Cons: If the protocol determines it is not a critical bug, can lose a lot of money. Notably, protocols have a conflict of interest when assessing a bug and historically have “sandbagged” severity ratings. I address a remediation for this later on.

My Recommendation

Critical Findings
Size: Either “$500,000+” as Maclane stated or $1,000,000 flat for a critical finding.
Rationale: $1,000,000 is a significant enough bounty to motivate a gray-hat.
Criteria: A vulnerability that puts all TBTC funds at risk
High Severity Findings
Size: Either $50,000 or $100,000
Criteria: A vulnerability that puts some TBTC funds at risk
Below High
Size: No rewards.
Rationale: Small bugs that don’t put funds at risk are simply not a concern and thus not worth rewarding.

Currency: I propose that we pay out in DAI, TBTC, or ETH.

What to do with the money?
This will be a liability for the DAO, essentially a “Notes Payable” in perpetuity. We will need to keep it on hand and easily retrieved. Although, we should have some wiggle room here. I suggest that we keep 50% at all times in protocol owned liquidity so that it is active and generating some yield.

Mitigating the Conflict of Interest
We should have clear and unbiased guidelines to determine the severity of a finding. I suggest a technical lead from Keep Co and Nu Co and an independent and qualified third party, such as @michwill, serve as judges for findings. They should be compensated some amount for their time if they are willing to provide the service. I’d suggest $5k in T tokens to each.


Sorry, dropped off at the end of the call.

I think that the funds denominated for the bounty should be put to work in protocol-owned liquidity. Like John said in the call it’s definitely worth thinking about the possibility that multiple critical findings are claimed and IMO it’s important to launch the bug bounty as soon as possible. So I’d recommend setting the bounty at $500,000, then increasing this as time goes on if non are claimed.

So adding to a liquidity pool a nominal amount of $1,000,000 then half can be withdrawn for any bounties (I believe someone mentioned there is some time flexibility for paying out) could be a beneficial solution.

Also, it may be worth putting a non-typical amount down, ie $525,000 as it bumps Threshold up from page 9 at $500k to page 6 at $525K on the Immunefi explore bounties page.