The Treasury.sol::deposit() function directly interacts with ERC-20 tokens using IERC20(token).transferFrom, which does not account for weird ERC20 tokens (e.g. that do not return a boolean value, such as USDT). Some tokens have unconventional implementations, such as missing return values, requiring additional gas, or having internal state changes that deviate from the ERC-20 standard. This can lead to unexpected reverts or incorrect balances, making the function unreliable for certain tokens.
The contract does not use OpenZeppelin’s SafeERC20, which provides a safer interface for handling ERC-20 tokens. Some tokens, such as USDT, do not return a boolean value in their transferFrom function, which can cause reverts. Other tokens may have additional logic in their transfer functions, such as burning mechanisms, hooks, or fees, which are not accounted for. Directly calling IERC20(token).transferFrom(msg.sender, address(this), amount); can lead to unexpected reverts, incorrect balances, or loss of funds. Given that the contract is designed to support multiple ERC-20 tokens as stated in the docs, failure to handle non-standard tokens limits its usability and reliability.
Deposits using non-standard ERC-20 tokens may fail.
Unexpected token behavior may cause incorrect balances to be recorded, leading to accounting inconsistencies.
Tokens with fees or additional logic may result in inaccurate deposited amounts, causing fund mismanagement.
Potential loss of funds if an unsupported token’s transfer function behaves unexpectedly.
Manual review
Replace direct ERC-20 interactions with OpenZeppelin’s SafeERC20 library. This ensures compatibility with all ERC-20 token implementations, preventing unexpected reverts and handling non-standard behavior properly.
LightChaser Low-60
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.