- Join Sherlock Discord
- Submit findings using the issue page in your private contest repo (label issues as med or high)
- Read for more details
Ethereum mainnet Arbitrum OP Mainnet Base Celo Polygon POS Gnosis Chain Scroll
Q: If you are integrating tokens, are you allowing only whitelisted tokens to work with the codebase or any complying with the standard? Are they assumed to have certain properties, e.g. be non-reentrant? Are there any types of weird tokens you want to integrate?
No tokens
Q: Are there any limitations on values set by admins (or other roles) in the codebase, including restrictions on array lengths?
Owner is trusted
Q: Are there any limitations on values set by admins (or other roles) in protocols you integrate with, including restrictions on array lengths?
No
No
Q: Are there any off-chain mechanisms involved in the protocol (e.g., keeper bots, arbitrage bots, etc.)? We assume these mechanisms will not misbehave, delay, or go offline unless otherwise specified.
No
The safe threshold should always be equal to lesser of the "enforced threshold" and the current number of safe owners HSG should always be the guard of the safe (except when detaching itself) HSG should always be enabled as a module of the safe (except when detaching itself) There should never be more than 1 module enabled on the safe No multisig transactions can be executed when the number of static signers is less than the min threshold No multisig transactions can be executed when the number of static signers is less than the "enforced threshold" No multisig transactions can be executed when the number of valid signers is less than the "enforced threshold" Modules should never be able to change any values in Safe storage The safe can never change its own number of static signers (unless it is explicitly authorized to do by being made the admin of one of the signerHats) The safe can never change its own threshold
Here is a doc (will also include in the repo) with an overview of our approach and some of our design choices, plus differences compared to v1: https://docs.google.com/document/d/1bq9yiuKaSl5qz0KatXxIDwNrkMr0J0dQluO46hiQTJU/edit?usp=sharing
The following audits covered Hats Protocol and HatsSignerGate v1. Since HatsSignerGate v2 has significant changes compared to v1, findings listed here should not invalidate findings in the present contest. But I am including these past audits for reference as it may be helpful to Watsons.
https://github.com/Hats-Protocol/hats-zodiac/tree/main/audits
https://docs.hatsprotocol.xyz https://hatsprotocol.xyz
This PR holds the diff between HatsSignerGate v1 and v2: Hats-Protocol/hats-zodiac#45