The identified code segments fail to validate the return value of the transferFrom function, which violates the ERC20 token standard security practices. Missing return value checks could allow failed token transfers to go undetected, leading to inconsistencies in contract state and potential loss of user funds.
AaveDIVAWrapperCore.sol Lines 229-230:
AaveDIVAWrapperCore.sol Lines 285-289:
Issue:
The ERC20 transferFrom function returns a boolean value indicating success (true) or failure (false). These code segments do not check the return value, assuming transfers always succeed. However, tokens like USDT (on mainnet) or non-compliant implementations may return false instead of reverting on failure. This could result in:
Users retaining tokens while the contract logic proceeds as if the transfer succeeded.
Incorrect accounting (e.g., recording deposits/withdrawals without actual token movements).
Users may lose tokens if the contract logic proceeds under the false assumption that transfers occurred.
Contract state inconsistencies (e.g., minting/redeeming shares without token custody).
Exploitable scenarios where malicious actors intentionally force transfer failures.
foundry
Explicit Return Value Checks:
Wrap transferFrom calls in require statements to enforce successful transfers:
Use SafeERC20 Library:
Replace raw transferFrom calls with OpenZeppelin’s safeTransferFrom from the SafeERC20 library. This handles both boolean returns and non-compliant tokens:
Test with Non-Compliant Tokens:
Validate behavior with tokens that return false on failure (e.g., USDT on Ethereum mainnet).
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.