Per to MIP-19, the depositToken should not be fee-on-transfer tokens:
... v2 pools, a v2 single $MC pool and a v2 LP $MC/ETH pool.
Therefore, we consider this an informational issue only.
2. Centralization risks
Use of Upgradeable Proxy Contract Structure allows the logic of the contract to be arbitrarily changed.
This allows the proxy admin to perform malicious actions e.g., taking funds from users' wallets up to the allowance limit.
This action can be performed by the malicious/compromised proxy admin without any restriction.
3. Lack of Storage Gap in Upgradeable Contracts
For upgradeable contracts, there must be storage gap to “allow developers to freely add new state variables in the future without compromising the storage compatibility with existing deployments” (quote OpenZeppelin). Otherwise it may be very difficult to write new implementation code. Without storage gap, the variable in child contract might be overwritten by the upgraded base contract if new variables are added to the base contract. This could have unintended and very serious consequences to the child contracts, potentially causing loss of user fund or cause the contract to malfunction completely.
WATCHPUG
unlabeled
Miscellaneous
The following issues can not meet the standard for Medium severity given the negligible impact, we submitted them just for your reference.
1.
depositTokencan not be fee-on-transfer tokens, otherwise the users whowithdraw()first will taken the funds from the users whowithdraw()laterhttps://github.com/sherlock-audit/2022-10-merit-circle/blob/main/merit-liquidity-mining/contracts/TimeLockPool.sol#L85-L107
https://github.com/sherlock-audit/2022-10-merit-circle/blob/main/merit-liquidity-mining/contracts/TimeLockPool.sol#L116-L135
Per to MIP-19, the depositToken should not be fee-on-transfer tokens:
Therefore, we consider this an informational issue only.
2. Centralization risks
Use of Upgradeable Proxy Contract Structure allows the logic of the contract to be arbitrarily changed.
This allows the proxy admin to perform malicious actions e.g., taking funds from users' wallets up to the allowance limit.
This action can be performed by the malicious/compromised proxy admin without any restriction.
3. Lack of Storage Gap in Upgradeable Contracts
For upgradeable contracts, there must be storage gap to “allow developers to freely add new state variables in the future without compromising the storage compatibility with existing deployments” (quote OpenZeppelin). Otherwise it may be very difficult to write new implementation code. Without storage gap, the variable in child contract might be overwritten by the upgraded base contract if new variables are added to the base contract. This could have unintended and very serious consequences to the child contracts, potentially causing loss of user fund or cause the contract to malfunction completely.
Refer to the bottom part of this article: https://docs.openzeppelin.com/upgrades-plugins/1.x/writing-upgradeable