- 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
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?
Only whitelisted ERC20 standard tokens can work with the codebase.
Q: Are the admins of the protocols your contracts integrate with (if any) TRUSTED or RESTRICTED? If these integrations are trusted, should auditors also assume they are always responsive, for example, are oracles trusted to provide non-stale information, or VRF providers to respond within a designated timeframe?
All the external admins are trusted.
Q: Are there any protocol roles? Please list them and provide whether they are TRUSTED or RESTRICTED, or provide a more comprehensive description of what a role can and can't do/impact.
There is a single admin (owner) that is trusted.
Q: For permissioned functions, please list all checks and requirements that will be made before calling the function.
Permissioned functions are secure by OZ Ownable (onlyOwner modifier).
Q: Is the codebase expected to comply with any EIPs? Can there be/are there any deviations from the specification?
n/a
Q: Are there any off-chain mechanisms or off-chain procedures for the protocol (keeper bots, arbitrage bots, etc.)?
no
Yes. The specifics around per block points emission rate for the farm as a whole and for each pool will be defined later. The specific pools in the farm will be finalized later as well.
Q: If the codebase is to be deployed on an L2, what should be the behavior of the protocol in case of sequencer issues (if applicable)? Should Sherlock assume that the Sequencer won't misbehave, including going offline?
We only plan to deploy the codebase on Ethereum mainnet at this time.
Q: Should potential issues, like broken assumptions about function behavior, be reported if they could pose risks in future integrations, even if they might not be an issue in the context of the scope? If yes, can you elaborate on properties/invariants that should hold?
n/a
n/a
n/a
Q: We will report issues where the core protocol functionality is inaccessible for at least 7 days. Would you like to override this value?
no need to override
n/a
Any bridging related code is considered out of scope
farming-contracts @ c08a2a81f2d5359bc05f41a25df54c7a91a73a03