Creating a Bug Bounty Service Run by Nexus Mutual

Governance Discussions Nexus Mutual Protocol Improvement Proposals
1

Over the last year, there have been numerous exploits conducted by black hats across various protocols. I’ve taken the time to write a fairly detailed study on the existing problem and economic impact that these exploits have on the protocols affected.

The Mutual currently offers smart contract cover, which is designed to reimburse members holding cover for a platform that is affected by an exploit (with proof of loss requirement and certain conditions as outlined in cover wording).

For every instance where we payout a claim, we are losing capital. There are some members who act as risk assessors and, upon having their stake burnt after a claim is paid out, decide that the rewards do not reflect the amount of risk. I don’t plan to address this last point, but the solution I have created does plan to mitigate risk across the DeFi ecosystem by realigning economic incentives.

I reviewed the bug bounty programs offered by 44 protocols within the DeFi ecosystem. The average bug bounty payout for a critical flaw was $111,153, while the average loss of funds in the various exploits conducted between 02/2020-02/2021 was $10,751,636.

This means the largest bug bounty available, on average, is just 1.03% of what the average loss of funds is based on aforementioned data.

Here is where I believe the Mutual can step in and create a service.

While there are existing platforms acting as a third-party service in bug bounty program management, there are no platforms in the DeFi market that offer a bug bounty service that builds capital over time and increases funds. The Mutual could offer such a service, and it would be hugely beneficial to all parties involved.

The details and breakdown of specifics is included in a study I wrote. Members can review this document to get a better understanding of how the Mutual can gain a significant market share in the third-party bug bounty service. This service would also create a positive feedback loop.

I outline three (3) possible approaches that we can take to start such a service. Of the three, I am most in favor of Option #3, but I have written this report to better help members make an informed decision.

I see this as a multi-million dollar service from the outset, so I do not want to approach this idea lightly or without serious discussion.

Option #1: Protocol-Specific Bug Bounty (PSBB) Fund

Basics of Proposed Solution/Service:

Protocol deposits money for PSBB fund pool into Nexus Mutual.

  • PSBB fund topped up with 10% of premiums paid for the protocol.

  • If an issue is discovered and approved, the PSBB fund pays white hat based on a) severity and b) pre-defined rewards schedule.

  • If no issues are discovered/arise, protocol can either keep funds with Mutual and grow the PSBB fund over time OR they can withdraw the initial deposit and forfeit any additional rewards accrued in the PSBB fund.

Option #2: Pooled Bug Bounty (PBB) Fund

Basics of Proposed Solution/Service:

  • Nexus Mutual puts up a majority of the capital for the PBB fund.

o The ideal scenario here would be the Mutual purchasing wNXM and converting it to NXM to buy discounted wNXM and reduce open supply of wNXM on market while creating PBB fund.

  • Protocol provides a good-faith deposit, which is determined by schedule that provides deposit sizes based on protocol’s market cap.

  • Protocol pays a monthly premium (or by the year) for bug bounty coverage.

  • Portion of all premiums paid goes into PBB fund: proposed amount would be 10%.

  • A certain percentage of funds is invested (less than 30% of funds) to earn interest that would go back into PBB fund.

  • If a flaw/weakness is discovered by white hat in a protocol’s smart contracts, PBB fund pays out based on a) severity and b) pre-defined reward schedule.

  • If a protocol wants to cancel their bug bounty policy with the Mutual, their good-faith deposit will be returned. Mutual keeps any funds earned from portion of premiums diverted to the program.

Option #3: Protocol Deposit Bug Bounty (PDBB) Pooled Fund

Basics of Proposed Solution/Service:

  • Protocol deposits money for PDBB pooled fund into Nexus Mutual.

  • PDBB pooled fund topped up with 10% of premiums paid for protocols.

Protocol pays a monthly premium (or by the year) for bug bounty service.

  • If an issue is discovered and approved, the PDBB pooled fund pays white-hat hacker based on a) severity and b) pre-defined rewards schedule.

  • If no issues are discovered/arise, protocol can either keep funds with Mutual and grow the PSBB fund over time OR they can withdraw the initial deposit.

  • If an exploit does occur, there is a two-week withdrawal hold. This is a safety mechanism to ensure that any one protocol cannot decide to sufficiently drain the pooled fund after an exploit occurs (under the same approach we take with NXM stake lock-up period).

Using one of these three approaches, the Mutual could do what, I’ll argue, no other platform can in the current market: offer a solution that is a vertical integration, which take advantage of existing revenue streams to create an incentive for protocols to use the Mutual for this service, while also generating revenue from the protocols’ premiums and, thus, offsetting any premium diversion.

Possible approaches could take advantage of market synergy by partnering with an existing bug bounty program management service, such as ImmuneFi, to handle that service. The Mutual would just manage the capital.

It creates an incentive for protocols to encourage users to buy cover because a portion of premiums go into the bug bounty fund.

It creates an incentive for members to stake NXM because growth in cover purchases means that more rewards will be available. It is possible that more shield mining campaigns could result because of the same point stated above.

It better aligns a hacker’s incentives to be a white hat instead of a black hat. Free-and-clear, legal money is more attractive.

Less black hat activity makes the whole ecosystem safer and mitigates some of the risk that risk assessors take on when staking NXM.

This is the idea, and I welcome feedback and others’ perspectives. I do not come from a dev background, so I would love to hear from a dev’s point of view. I would also like to know how many bug bounties are paid out over the course of a year.

Review the attached link to read the full report that I’ve written, which includes much more detail.

NXM Bug Bounty Report

2 Likes
2

Thanks for such a detailed and well thought out post!

From an incentive point of view I thought it would help to identify the roles and outline who should pay whom. Then the details of the which mechanic is best become a bit clearer.

Black Hat
Objective: convert to white hat
Funds flow: receive higher bounties for acting as a white hat, to limit the amount of black hat hacks
Challenges: if bounties aren’t big enough the incentive to shift isn’t there.

Protocols and their users
Objective: minimise losses from hacks, something additional to regular bounties
Funds flow: pay higher bounties if there is a hack, benefit if there isn’t a hack.
Challenges: likely don’t have large financials resources at launch, though may have native tokens. Need to have an additional incentive to run the program on Nexus rather than doing it entirely by themselves.

Nexus Mutual
Objective: maximise surplus, so income from sales less claims.
Funds Flow: Happy to hand over some of the fees from sales if it reduces claims costs.
Challenges: diverting fees that don’t actually reduce claims costs simply reduces surplus. Should only divert fees if covers are taken out. Is this enough to encourage protocols to set-up the bounty with Nexus?

Set-up
The biggest challenge appears to be bootstrapping the initial bounty because:

  1. If the protocol is new it likely doesn’t have spare cash
  2. Nexus should only fund if it avoids claims, and cover sales will start at zero and increase with user adoption.

The main solution to this problem is likely the protocol pays for the majority of the initial bounty in either cash (USD, ETH, DAI etc) or with their native token. This can then be supplemented with a share of fees from Nexus. It could also be supplemented by the protocol taking some cover themselves to enhance the bug bounty pool.

If there isn’t a hack the protocol should keep the Nexus fees (likely with a longer term vest), otherwise it is added to the bounty pool.

Other comments:

  • intuitively I’m more in favour of the protocol specific approach
  • I’d probably keep this separate from the Nexus core capital pool and have different protocol specific pools that are topped up with wNXM based on cover sales.
3

Great points all around, Hugh. Thanks for breaking down incentives.

My version isn’t as concise, but I always aim to be thorough.

The funding is the biggest stumbling block in my thinking, too. Going forward, my hope is that investors would see how providing funding for a bug bounty program would be a necessary part of any investment package in a protocol. That neither here nor there in this discussion, though.

As it pertains to this program, I think the protocol-specific pools do have a lot of advantages. I figured these pools would have to be separate, but I wanted to make flow of funds diagrams that fit into the initial design of the protocol.

If the capital pools are protocol-specific, then I think a vesting option would be the greatest incentive for a protocol. In other scenarios, it wouldn’t have played as significant a role.

I’m definitely open to more discussion, but if we were to launch such a program, it might be beneficial to approach some of the larger protocols we provide cover for and ask if they want to participate in an initial soft launch of this service. Approaching Alpha Homora v2 with such an offer would probably attract a lot of staking and benefit the Mutual. A small initial rollout could be a good approach to see if there is greater interest and any significant benefit to users. Things to consider.

From a dev level, I don’t know if it makes sense to implement something like that to test it out, either.

Perhaps starting with a survey that we send out to dev teams from various protocols to see if there is an appetite for such a service?

1 Like