Two weeks ago we got a ping from community member Fav_Truffe#7571 about an offer to participate early in their venture to secure smart contracts via bug bounty smart contract vaults. Some deeper research is needed on part of the security team if we want to go for it. However - a first security internal discussion yielded some points we might not be comfortable with. I’ll let @brodhisattva chime in on this.
Here is the full text of the inquiry:
As Hats Finance we would love to create an on-chain security bug bounty vault for Giveth to create another protection layer. Its completely free to have a vault on Hats protocol. Additionally, we have recently initiated an Airdrop Machine (similar to the one Optimism used) in order to fill the gap until our TGE. Accordingly, both Giveth DAO and your community members who deposit to your vault will be able to farm future $HAT tokens and these tokens will be sent after our TGE. Since, you are very probably to be eligible for a good amount of $HAT tokens as a DAO, it would be really nice to see you guys in our future DAO.
Briefly, Hats.finance is a decentralized bug bounty platform specifically designed to prevent crypto hack incidents by turning black hat hackers into white hat hackers using the right incentives. Additionally, the projects creating bounties for bugs (of differing severity) get to have the opportunity to increase the engagement both within their community and across other DeFi communities. Hats.finance is a decentralized bug bounty protocol that allows anyone to add liquidity to a smart bug bounty while farming $HAT. 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, and do not cost anything unless there a vulnerability is discovered, which would be more costly and irreversible once exploited. More importantly, it is transparent, decentralized, and gives power to the community behind the project. You can take a look at the DeFi projects, having created bug bounties, at the Hats.finance - decentralized cybersecurity bug bounty protocol
Why it’s good to open a vault during the bear market besides creating an additional security layer:
Lock token from the circulation into security pool (less sale pressure as the community participation increases)
More engagement with the community
Opportunities for yield farming ($HAT (not live yet)) with their token during the bear market (another utility for the token)
PR about things the protocol doing during this time: announcement, space, more promotion
ON first pass this appears to be a great idea that is super aligned with Giveth.
We have deep White Hat roots with our dear founder, the $HAT fits!
Partnerships that deepen our recognition as a solution provider that values security, strengthen our position as a leader in regenerative web3 economy creation, and can put more tokens in our treasury…
I hope that you are all well and thanks @geleeroyale for taking the time to share the proposal.
Firstly, Hats Finance is a permissionless and non-custodial protocol and therefore Giveth DAO can withdraw the deposit whenever wished. In the meantime, if there is a successful vulnerability submission, its good for you since the vulnerability is reported instead of being exploited. If there is no any successful vulnerability submissions, its again good for Giveth DAO since you will basically be making money by farming $HAT tokens (after our TGE).
All in all, its a cost-negative action for Giveth to create a bug bounty vault on Hats protocol.
Lastly, i would be very happy to answer any questions or concerns
Hey everyone, Oliver here the director of operations at Hats.
It would be very interesting for us if you could share the points you might not be comfortable with. We understand ourselves as a decentral infrastructure provider so we are more than happy to consider requirements from the partners that leverage this infrastructure.
We put a lot of emphasis on the token part in our pitch because that seems to be a concept that resonates with many projects in the current environment. I really like what Giveth does personally so it would be great to have Giveth and its community as early stakeholders in terms of governance.
Even ignoring the upcoming incentives I think it’s a really attractive deal. But obviously, I’m biased so the Giveth Community has to discuss it internally and we are just here to answer any potential question.
There is one last point I want to bring forward, even if you don’t decide to host a bug bounty on Hats you should really have a bug bounty somewhere! It’s mandatory from a security perspective and every good auditor can confirm that.
Not sure if this is/was addressed (i missed it if so) how is the Vulnerability reported? (there are ofc other platforms for Bug Bounties, this one is interesting to me, with roughly low cost etc. might work out well.
Otherwise, might have to hire a setup to do this, with higher costs etc.
In case a vulnerability is submitted, the report is sent to the committee of the relevant bug bounty vault encrypted. So, it cannot be seen even by the Hats team and its only the committtee members who can decrypt it (and therefore see the sensitive data (vulnerability report)).
If we were to move our liquidity into one of these Hats, I can see two risks we’re taking.
The risk that Hats and its infrastructure may be compromised, leading to the loss of our liquidity. I can’t quantify this risk at the moment, but as always in defi, it’s not zero risk.
The opportunity risk of putting that liquidity elsewhere for a different return on investment. If there’s another place where we can make real returns on our liquidity, we will be losing that by putting money in Hats. That may eventually be offset by $HAT.
We also need to understand more about the following:
3) Who exactly decides which vulnerability disclosures result in bounty payments? is there anyone outside of the Giveth team who can influence the decision to pay out or the amount to pay out?
4) How effective has Hats been for other DAOs to get useful vulnerability reports? Does Hats have any metrics on the number of reports that have been received over time for each DAO? Or metrics on how many of those actually paid a bounty? Over the time that I’ve worked with giveth, the majority of vulnerability reports have not been useful, and before we start soliciting more, we should make sure they’re going to be useful.
Hats team, do you have any info for #3 and #4?
Thank you,
Hey, thanks for your comment and essential questions and sorry for the late reply, I was OOO.
Yes, there is always a risk in DeFi. You can check our audits and our code. Many of our onboarded projects have done an internal review of our contracts, and we welcome you to do that as well. To find an on-chain security solution, we want to know the pain points of being an on-chain project. As a Defi project, we share the same problems in the product’s life cycle, so we battle-test our solution on ourselves before offering it to partners.
You can also deposit any yield token, so you will not have an opportunity risk.
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.
Hats team dont have access or readability to the report submitted on the chain; only the committee members who hold the private PGP key on their local machine can decrypt the reports and communicate with the hacker.
As I mention, we don’t have a readability accsess of the reports, but we do have an on-chain data for “claim” = submission of a report. We opened this dashboard since the last CTF, where we had more than 50 submissions in 72 hours. You can follow this link: Dune
For your important comment about the “useful reports,” I can share with you how the submission works, especially the tx fee filter:
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 acts 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
Please feel free to share more thoughts; this discussion is essential.
I want to offer my deepest condolences for the recent exploit. However, times/cases like this should remind us all about the good security practices and how to serve best to our community/ how to do public good in the most secure way.
Please feel free to reach out to us if you have any security-wise issues, questions or concerns. We would be more than glad to do our best to help.
Hey Fav_Truffe! Thanks for all that information. That really helps. Would you and your team be available for a conversation before your presentation in the community meeting in two weeks? We’d like to try to go a bit more in depth with some of our engineers to get our head around how this works and the implications of using your service.
Do you have any availability in the next two weeks for a half hour meeting? Preferably one that is early for the west coast north american people and late for the EMEA people.
Hey @brodhisattva! Appreciate the feedback. Yes, we would love to meet to give a full explanation of the processes and do a demo show of Hats dApp. I am sharing our calendly with @mitch on Discord. Feel free to book a slot
I want to give an update of this to the community. Since the community decided in a soft poll that we would like to try out hats.finances bounty system, we need to prepare a few things.
To start - we need to select the committee. This will be a multisig of people judging bounty payout reauests, as such some technical skill in judging severity and impact of a vulnerability is a requisite.
I will start below this post to nominate myself for the committee.
I am volunteering to be part of the committe to judge vulnerability reports coming in via hats.finance.
Why me:
I feel I am suited to this task, since I work with security a lot and did handle all prior vulnerability reports in the first stage after receiving it. Those that were eligible for bounties got them and I handled informing the community, making votes and finally setting up bounty payouts to be paid out via our Aragon DAO.
Furthermore, with experience in Giveth sice inception I feel I have earned a solid reputation for being trustworthy with handling large amounts of funds, as well as holding a key to a multisig.
I am volunteering to be part of the committe to judge vulnerability reports coming in via hats.finance.
Why me:
Since January 2022, I’ve been involved with reviewing, prioritizing, and responding to security issues reported to Giveth. Before being involved with Giveth, I spent about nine years working in AWS across security operations, application security, and cryptography. During that time I reviewed well into the triple digits of external security reports. I have led responses to embargoed issues (meaning that they impact enough users/organizations that they are not disclosed publicly until a mitigation is found). I have extensive experience dealing with external security researchers and penetration testers.
In this committee, I expect that my role would primarily be to provide quick impact assessment and validation of submissions, and coordinate our response to the submitters.
I’ve spent a lot of time being trusted with multi-billion dollar systems and secrets that could break the internet, so this is all pretty normal for me. I’m also happy to perform these same duties without being part of the committee.
I am volunteering to be part of the committe to judge vulnerability reports coming in via hats.finance.
Why me:
I feel I need to be on this crew, since I have a history of managing the White Hat Group, know the smart contract systems we use very well, and have done audits categorizing severity.
It should be fairly secure, but not too big to become unwieldy. General multisig rules apply I’d say. Internally we said to do it with no less than 4 people - that would be on the weak side tho.
I am volunteering to be part of the committee to judge vulnerability reports coming in via hats.finance
Why me:
Although I am relatively new to the smart contract world. I have been involved in the past months in mitigating some of our vulnerabilities through my work with the team. This included working on closing security issues with IPFS in our legacy platform (Trace), identifying misconfigs, advising and helping out with auditability on our infrastructure access control and patching, and advising with static security scans to our contracts.
Being part of this committee to judge vulnerability reports, increases my chances to advise on future security improvements. And as a DEVOPS Specialist, this will increases my ability to find better tools and advise on better development from a security standpoint.
