Bug Bounty Vault Proposal by Hats Finance

TLDR:

This is a proposal for Idle DAO to collaborate with Hats.finance, create a hacker/auditors incentive pool to protect the Idle smart contracts. The goal of the vault is to incentivize vulnerability disclosure for Idle smart contracts. Liquidity can be added permissionless and LPs will be rewarded with $HAT token once the liquidity mining program is launched.

Summary:

The direct losses from hacks and exploits between 2020-2022 are above $15B, and yet, the solutions currently being offered are not decentralized, permissionless, scalable and continuous like Idle DAO is.

Hats Finance:

Hats.finance is a on-chain decentralized bug bounty platform specifically designed to prevent crypto-hack incidents by offering the right incentives. Additionally, hats.finance allows anyone to add liquidity to a smart bug bounty. Hackers can responsibly disclose vulnerabilities without KYC & be rewarded with scalable prizes & NFTs for their work.

Smart bug bounty programs are a win-win for everyone. They can be created easily with a few on-chain transactions (it takes around 1 hour to open a vault on hats), and are free of charge. The protocol will only charge a fee if an incident has been successfully mitigated, which would be way more costly and irreversible once exploited. More importantly, it is transparent, decentralized, and gives power to the community behind the project.

Security underlies the technology of smart contracts; there isn’t such a thing as too much security in our space. We think Ethereum dapps should include our solution and others, like Immunefi. Having said that, we strongly believe the future of cybersecurity is incentivized. We aim to lead this agenda, by creating a decentralized bug bounty marketplace that will incentivize all of its participants.

The key advantage of Hats solution on the traditional, centralized bug bounty services:

  • Bug bounty vaults are loaded with the native token or yield bearing token of the project. Reducing the free floating supply while giving the token additional utility.
  • Scalable bounty network — vault TVL increases with success / token appreciation of the project.
  • Open & Permissionless — Anyone can participate in the protection of an asset they are a stakeholder of and any hacker, anywhere in the world, can participate anonymously when disclosing exploits (no KYC needed)
  • In the future when providing liquidity(taking risk) every depositor could farm $HAT tokens.
  • Continuous — As long as tokens are locked in the vault, hackers are incentivized to disclose vulnerabilities through Hats, instead of hacking.

Motivation

Project coverage:

  • 24\7 audits on your protocol with a proactive approach that incentivizes hackers to disclose vulnerabilities instead of hacking
  • A disclosed vulnerability means no TVL\ TOKEN loss
  • Permissionless vault — token holders and the protocol community can deposit or withdraw in the same permissionless nature.
  • Public relation regarding mitigated vulnerabilities and security becomes a strength of the project.
  • Attract more users that have high security requirements

Token value:

  • Token staked in vault → Token with higher security guarantees.
  • In the future one-sided yield farming based on $IDLE
  • Staking tokens in the Hat vaults reduces circulating token supply

Committee:

The main incentive of a committee to triage reports is the potential to rescue users’ funds and the protocol’s reputation. In addition, Hats has two incentive mechanisms in place in addition:

  • Each call to approve function (confirmation of an exploit that was resolved by the project committee) triggers a split function that sends part of the reward (default 5%) to the committee for triaging the issue and solving it in a responsible manner.
  • Each exploit claim is attached with ETH denominated fees. This fee is intended to prevent bad actors to use the reporting function to create spam reduce the exploit report spam and to incentivize report triage by committees. The fees are transferred to the Hats governance wallet in order not to expose the project that was reported and will be transferred to the respected committees from time to time upon receipt of disclosure descriptions that correspond to the hash of the vulnerability on-chain. Submission fees are currently set to 0 so only tx gas costs apply.

Project community \ Token holders:

  • Join the effort to secure the ecosystem of Idle DAO.
  • Protect their $IDLE by depositing a portion of their $IDLE holding to the bug bounty vault to make their holding more secure. By doing that, depositors potentially get $HAT tokens (on liquidity mining program launch)
  • Permissionless vault — token holders and the protocol community can deposit or withdraw in the same permissionless nature.

Hacker/Auditors:

  • Fungible funds - no need to move the funds into mixers
  • Incentivized by the big reward prize, less than what they could hack, but still a meaningful amount.
  • Play by black hat rules and get a white hat rewards.
  • Easier to disclose vulnerability than to exploit it
  • No KYC
  • Reputation and notoriety as a proficient hacker
  • Be good, do good for the ecosystem

Proposal action items:

  • Decide on collaboration with Hats.Finance
  • Choose and set up a committee
  • Vote for DAO participation amount (It was decided to propose creating a vault of $10.000 value, but the amount can be increased by a second proposal if the community members want so)

Onboarding action items:

  • Choose committee: The committee is preferably the public multisig contract of Idle DAO or another multisig with some of the same members.

  • Committee responsibility:

  • Triage auditors/hackers reports/claims(get back to the reporter in 12 hours).

  • Approve claims within a reasonable time frame (Max of 6 days)

  • Set up repositories and contracts under review. (List of all contracts under the bounty program and their severity)

  • Be responsive via its telegram group or discord channel.

$IDLE deposit:

Vaults are opened with the native token of the project, with the one token - per vault (bug bounty) mechanism. Therefore the community has to select one token to bootstrap their bounty, be it $IDLE. It means that the rewards to security experts/hackers after a responsible disclosure will be in $IDLE token. In the next few weeks, we will introduce the multiple-token options, where the Idle DAO community will also be able to deposit the other asset $IDLE, wETH, or stable coins.

In the future when the $HAT token will be live, depositors in the bounty vaults will be potentially able to claim the $HAT token. Anyone can join the security efforts of their beloved protocol for the first time in the crypto ecosystem. Decentralizing the traditional bug bounty will create a new way of responsibility/success sharing and a new level of trust between the community and the protocol.

Concluding Remarks

At Hats.finance, we envision a future in which the security marketplace is a standard for the crypto ecosystem. Considering how much Idle DAO cares about the security of the network and its operations, it is beyond any doubt that a bounty on Hats.finance will draw more attensionwhite hat hackers and auditors to the smart contracts of Idle. Accordingly, each scrutiny will contribute to the safety and security of Idle DAO.

References

We would love to see the discussion going in detail and get feedback on the proposal.

Thank you!

4 Likes

Thanks for the detailed proposal and welcome to the forum!

In general it seems a good way to ‘upgrade’ the security of the various Idle products even more and expand the bug bounty with also community contributions.

I have a couple of question regarding the committee and how the bug reports are handled:

  1. can you share some documentation regarding the committee? From what I got bug hunters need to ‘attach’ (I assume ‘pay’, here but correct me if I’m wrong) some ETH for submitting an issue and this fee is transferred to the committee minus a fee?
  2. should the committee be composed only by Idle DAO members?
  3. Is there a dashboard for the committee where to see all bug reports or how those are communicated?
  4. the reward for each confirmed bug report is determined by the committee based on the IDLE tokens present in the Hats vault?
  5. while a bug report is submitted and is being triaged, are withdrawals still available?
3 Likes

1- Encrypt vulnerability:
User (Submitter) writes a detailed vulnerability description on Hats dApp. The submission is encrypted with the project PGP key.

Submit vulnerability:
The user hashes the encrypted description and sends a transaction on-chain with that Hash ( only the Hash of the encrypted report is going on-chain), While sending the encrypted message to the routing bot.

-The tx fee is acting as a spam filter and can be set to a higher value. The additional fee is being sent to hats governance.

Filter bot:

The routing bot verifies that the Hash of the encrypted message was published on-chain and publish the encrypted message to the committee group together with a link to a front end open source tool to decrypt the messages that are stored on IPFS that is part of Hats dapp

The bounty reward for the submitter is not paid at once to reduce the price pressure on project token. A default of 5% from the paid bounty will go to the committee for their work.

2- Setting up a pool for a project results in a situation where the designated committee can call the “approve” function and use part or all the pool content as a reward to the designated Ethereum address. This outcome can be dangerous for the pool funds if the committee is not aligned with the project incentives. At Hats we are mitigating those risks by using several methods:

  • The committee is preferably the public multisig contract of the project or another multisig with some of the same members. this contract usually executes the snapshot decisions or the founders of the project itself that have control over the deployed contracts to a certain extent already. By using a well-known party that is already staked in the project’s success we are aligning the incentives as those same people are responsible for much more than the funds in the pull itself.

  • The committee approves itself and the pool details are set up before funds can be deposited into it. We are doing it to prevent a situation where a pool has been set up with a committee multisig address that doesn’t exists or lost control of keys and therefore, is caused a situation where the project token cannot be bountied to.

3- We started to design a dashboard for the committee’s use as follows:
Vault creation tools - ready
PGP generated - ready
Payment approval - in progress.
Committee bug report dashboard & war room - Next!

Hats Finance currrently communicate with the committee through a private Discord or Telegram channel via encrypted messages.

4- Yes, the committee can determine the severity description and how much, in percentage, the bounty will be from the bug bounty TVL.

For each severity, there is a range of rewards; for example - Low severity can be up to 5% of the bug bounty TVL, but it could also be 1%, 2%, 3%, etc… the committee predetermines the range before the bug bounty deployed on mainnet.

5- Generally, there is a seven-day period between the withdrawal request and the withdrawal. While the committee receives and approves the vulnerability submission, they will freeze the vault. No one can deposit or withdraw during this time to ensure new depositors are not taking an existing risk. One of the reasons a trusted committee should be selected by the project is to solve the issue in the background and pause the vault only when deploying the fix to not expose the bug publicly by pausing the vault withdrawals.

How does the payment work?
In general for

  1. I think I get all steps but I guess we may have to test them at least once just to be sure we got everything right

  2. ok makes sense

  3. ok do you have a rough timeline for the payment approval and the committee bug report dashboard & war room?

  4. ok perfect

  5. great!

In general as committee we can use the dev league multisig (2 out of 5 owners needed) I guess or the treasury multisig (4 out of 12)

1 Like

For example, a bounty of a critical severity would look like this:

80.00% of vault ≈ $245K
Prize Content Division:

60% Vested TEMPLE for 30 days (Hacker reward) ≈ $147K
20% TEMPLE (Hacker reward) ≈ $49K
5% Committee ≈ $12.3K
5% Vested Hats for 90 days (Hacker reward) ≈ $12.3K
10% Governance ≈ $24.5K

  1. Yes, we would love to do a demo for you whenever you are ready.

  2. Rewards -
    For low-level severity vulnerabilities rewards are likely to be released within 14 days of the validation of your submission.

For medium, high and critical level severity vulnerabilities, rewards will be released within two weeks after the vulnerability has been properly addressed.
you can find it here as well: Hats.finance - decentralized cybersecurity bug bounty protocol

In general as committee we can use the dev league multisig (2 out of 5 owners needed) I guess or the treasury multisig (4 out of 12)

Yes, both of them works.

1 Like

So just to be clear here

80% (60 + 20) of the rewards are for the hacker in the form of protocol token, IDLE in our case.
Another 5% more is for the hacker in the form of HATS tokens.
We, as a committee, get 5% back of our IDLE tokens for triaging the issue
10%, in IDLE is the ‘fee’ for Hats governance right?

1 Like

Yes William. 5% of the bounty for the hacker is exchanged from $IDLE to $HAT and it is vested for 90 days. Then, its sent to the hacker.

1 Like