After all my checking i can say yes. Its the best way to the project. Thank u!
Should the DAO be responsible to support the auditing of code that the association is responsible for? this would be a general question in the future.
I support this proposal
good proposal
I want to know more. But for now mi vote is NO
Yes…
Yes , is good for Hopr
This is only for the staking smart contract of for something more ?
Yes , good option
I need some time to check
I believe this is a kind of trial, and If it works well, the bug bounty for more critical smart contract for HOPR protocol can be managed here.
If things go well, the vault can be expanded in the future to cover evolutions to our staking program and other HOPR smart contracts, such as the payment channel contract.
The idea does not seem to me very good, since moving such a number of tokens to a contract can carry various risks: hacking the contract, etc. I think that the amount should be reduced
I am all for things that grow a secure the network/contracts. I am also a big believer in starting small and building…you can always add more funds as confidence builds…
good!
Hey! Thanks for the question, and I’m sorry for my late reply.
How it works:
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.
Filter bot:
The routing bot verifies that the Hash of the encrypted message was published on-chain and publishes 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.
- To ensure maximum security and confidentiality of the report, only committee members with the private PGP keys stored on their local machines can decrypt it. This provides an additional layer of protection against unauthorized access and ensures that only authorized individuals can access and review the report
The bounty reward for the submitter is not paid at once to reduce the price pressure on the project token; we are using a vested contract, with the default of 20% - immediately paid, 60% - vested for 30 days, and then paid to the hacker, 5% - goes to the committee members, 5% - swape to $HATS token (not live yet) for 90 days and then paid to the hacker, 10% goes to Hats governance (From the approved by the project committee after the bug fixed).
Who is the committee:
- 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.
- We’ve implemented a flexible mechanism for DAOs where the committee can have different types of members, each with their own specific privileges. This includes:
- Multisig members who can decrypt the report
- Multisig members who cannot decrypt the report
- Members who can only decrypt the message without being able to sign
- Members who can only participate in the committee discussion
We’ve taken all necessary security measures to ensure that the committee can decentralize itself while maintaining a high level of security.
1 Like
I completely agree from the perspective of a security researcher!
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 a vulnerability is discovered, which would be more costly and irreversible once exploited. More importantly, it is transparent and decentralized.
Hats protocol is a non-custodial, open, and permissionless system for everyone, allowing deposits and withdrawals at any time. However, it is important to note that a seven-day waiting period is required between the withdrawal request and the actual withdrawal. This is necessary to ensure that if the committee receives and approves a vulnerability submission, they can temporarily freeze the vault to prevent any further risks.
To avoid exposing the bug publicly by halting the vault withdrawals, it is crucial to select a trusted committee that can address the issue in the background and pause the vault only when deploying the fix. This is yet another reason why a reliable committee should be chosen by the project.
Good to know, thank you
yes
Greetings HOPR Community! It’s Ofir from Hats.finance.
We have an important update to share with you all.
The HOPR Association team has successfully established the HOPR Vault (Bug Bounty) and is currently in the process of gathering signatures to make it visible.
Here are the next steps in the process:
- The HOPR Association has checked- in the Vault and is preparing to deposit funds.
- The Hats Governance will ensure the Vault becomes visible within the next 48 hours.
- For HOPR DAO deposit instructions, please follow these steps:
- Visit the Hats dApp at https://app.hats.finance/vaults
- Connect the DAO wallet address using Wallet Connect.
- Select the HOPR Bug Bounty and click the ‘Deposit’ button.
- Enter the amount the DAO wishes to deposit.
- Approve the amount by providing a signature (sig).
- Sign the transaction (sig).
If you require any assistance or have questions, please feel free to tag me here or reach out in the Hats Discord.