- Join Sherlock Discord
- Submit findings using the issue page in your private contest repo (label issues as med or high)
- Read for more details
Polygon
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?
Stablecoins listed in the StablecoinHandler.sol are the same as the stablecoin contract being evaluated in this audit and are expected to behave as such, not simply "any stablecoin". Besides this tokens are expected to behave like normal ERC20s. Tokens that spend off fee portions should be allowed, and if a portion of the fee sent off breaks the contract, than this would be an issue. However issues raised simply stating "user's might get less than expected" is not valid if the source of this issue is simply lacking checks for return values. We will also work with USDT and USDC.
Q: Are there any limitations on values set by admins (or other roles) in the codebase, including restrictions on array lengths?
No
Q: Are there any limitations on values set by admins (or other roles) in protocols you integrate with, including restrictions on array lengths?
No
Q: For permissioned functions, please list all checks and requirements that will be made before calling the function.
Potentially multiple trades are prepared durning a single swap. Permissioned functions rely on swap data provided from an aggregator for the user's swap and buyback swap. Some of these payloads need to be signed by the user and appropriate checks are made for approvals, ensuring that the user's have approved the tokens to swap, or tokens taken from safes already have approvals to do so. FX rates are provided for stablecoin swaps and these rates are verifies off chain and their values align.
Q: Is the codebase expected to comply with any EIPs? Can there be/are there any deviations from the specification?
Most all contracts will be behind proxies and should comply with eip-1967. That said, it is not the auditor's responsibility to verify that the contract is currently backwards compatible with an existing deployment.
Q: Are there any off-chain mechanisms for the protocol (keeper bots, arbitrage bots, etc.)? We assume they won't misbehave, delay, or go offline unless specified otherwise.
An executor system is used to perform transactions on the user's behalf. It is assumed that this system will not go offline.
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?
The system should assume that so long as the network is running, bridge related issues should not affect the workings of this contract.
N/A
The contract is constructed so that most inputs can be ignored in nearly any flow unless this would lead to a loss of funds. For example, the protocol may chose not to perform a buyback, are accept a fee, etc. However is the value for a safe is not passed in tokens should not be able to be sent into space or the zero address. Tokens received in stablecoin swaps do not need to back the currencies that are minted.
Defi trades in different portions of the swap may fail, causing the entire transaction to fail. This is acceptable. Actions are expected to be atomic and if portions are not successful the entire transaction should not succeed.
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
https://audits.sherlock.xyz/contests/196
N/A
N/A