Broad Jetblack Alligator
Medium
In the file at https://github.com/sherlock-audit/2024-10-axion/blob/d75df3636ea28dd627d548d5d473c5d5477b0dc6/solidly-utils/contracts/MasterUtils.sol#L147, and https://github.com/sherlock-audit/2024-10-axion/blob/main/liquidity-amo/contracts/SolidlyV2AMO.sol in multiple places , and https://github.com/sherlock-audit/2024-10-axion/blob/main/liquidity-amo/contracts/SolidlyV3AMO.sol also in multiple places , unsafe approval is utilized. and using the standard ERC20 approve function instead of safeApprove may lead to transaction failures with non-standard ERC20 tokens, such as USDT, which do not return a boolean value and can cause unexpected reverts and functionality loss.
In MasterUtils.sol
and solidlyV2Amo
and SolidlyV3Amo
, the dev use the standard ERC20 approve function instead of safeApprove, despite SafeERC20 being imported but not utilized.
for MasterUtils contract
- The contract must interact with a non-standard ERC20 token that does not return a boolean for approval.
- The OPERATOR_ROLE invokes the notifyRewardAmounts function with this token as one of the reward tokens.
No response
- OPERATOR_ROLE calls notifyRewardAmounts with a non-standard ERC20 token (e.g., USDT) as one of the reward tokens.
- The function attempts to approve the token transfer using the standard approve function.
- The approve call fails silently or reverts due to the token not returning the expected boolean value.
- The entire transaction reverts.
or
- add liquidity in SolidlyV2 or V3 and approve the tokens.
The protocol cannot allocate reward amounts for specific tokens.
No response
Utilize the SafeERC20 library that is already imported in the contract, and replace the standard approve call with safeApprove from SafeERC20.