The protocol implements low level calls to ERC20 tokens in Rescuable
and in CapitalPool::approve
:
The problem is, this low level implementation, only checks whether the call was successful or not, and do not check the RETURNED DATA from that call
Some ERC20 tokens might return false on unsuccesful operations, rather than reverting. therefore, if such call was succesful but returned false, which means it was not succesful, the protocol will treat it as succesful call.
this might lead to loss of funds and unexpected errors.
manual review
consider implementing OpenZeppelin's SafeERC20
I believe the issues and duplicates do not warrant low severity severity as even if the call to transfers returns false instead of reverting, there is no impact as it is arguably correct given there will be insufficient funds to perform a rescue/withdrawal. This will not affect `tillIn()` as there are explicit balance [checks that revert accordingly](https://github.com/Cyfrin/2024-08-tadle/blob/04fd8634701697184a3f3a5558b41c109866e5f8/src/core/TokenManager.sol#L255-L260) to prevent allowing creation of offers without posting the necessary collateral
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.