In some implementations, such as USDC, Some ERC20 Tokens do not revert on failure of the transfer function, but return a bool value instead. Some do not return any value. Therefore it is required to check if a value was returned, and if true, which value it is. it can lead to potential issues where user funds could be lost or the transaction could fail silently.
https://github.com/Cyfrin/2024-08-tadle/blob/main/src/core/TokenManager.sol#L169
In some ERC20 token implementations, especially those that do not follow the standard strictly, the transfer function may return a boolean value indicating the success of the operation. If this return value is not checked, the contract may continue executing without ensuring the transfer was successful.
Silently failing transfers can result in a partial or total loss of the users investment.
User Funds Loss: If the transfer function fails but the failure is not detected due to unchecked return values, the funds intended for transfer may not be sent to the recipient. This can result in a loss of user funds or the funds not being available as expected.
Manual review
Check for the existence and value of the returned data of the Transfer call. If there is a return value, it has to be true. This could be achieved by using Openzeppelins SafeERC20 library´s safeTransfer.
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
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.