TIP-041: Establish a bug bounty program

Threshold Network, and its applications (PRE and tBTCv2), have been audited by multiple third party firms. The audits are published on (Threshold · About) and we understand that a second audit of tBTCv2, with Trail of Bits, will be published soon.

However, given the recent launch of tBTCv2’s Chaosnet 0 and the upcoming launch of minting in January, it is our responsibility to take further steps to improve the networks’ security posture. We propose establishing a public bug bounty on Immunefi (Immunefi Bug Bounties | Immunefi), a popular web3 bug bounty platform.

A credible bug bounty program will attract additional security reviews from the white hat community and incentive responsible disclosure of security vulnerabilities, which is especially topical given the severity of recent bridge-related security vulnerabilities.

We propose an initial schedule below, and request community and developer feedback on the amounts prior to moving this to snapshot:

  • Critical: Up to $500,000 in T tokens
  • High: Up to $50,000 in T tokens
  • Medium: Up to $5,000 in T tokens
  • Low: Up to $500 in T tokens

If tBTCv2 achieves an extremely TVL, these amounts can be revisited and increased.


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.