Strong Butter Crow
Medium
the "default" ERC20 behavior expects the approve function to return a boolean, however, some ERC20s on some chains don't return a value.
The most popular example is USDT on the main net, and as the docs mention it should be compatible on any EVM chain and will support USDT:
On what chains are the smart contracts going to be deployed?
Ethereum Mainnet, Polygon PoS, Arbitrum One, Base
If you are integrating tokens, are you allowing only whitelisted tokens to work with the codebase or any complying with the standard? Are they assumed to have certain properties, e.g. be non-reentrant? Are there any types of weird tokens you want to integrate?
For LenderGroups (our primary concern for this audit - LenderCommitmentGroup_Smart), we are allowing any token complying with the ERC20 standard except for fee-on-transfer tokens. Pools will be deployed with the principal token and collateral token types ( both must be ERC20) already defined and visible on the frontend so borrowers/lenders will be able to vet tokens for weirdness that way and avoid them if needed. Therefore we do not especially care if a 'weird' token breaks the contract since pools with tokens that are obviously weird will be naturally avoided by users but we would like to know if weird tokens affects do break our pools . We absolutely do want to fully support all mainstream tokens like USDC, USDT, WETH, MOG, PEPE, etc. and we already took special consideration to make sure USDT works with our contracts.
Some known tokens don't return a value on approvals, more info [here](https://github.com/d-xo/weird-erc20?tab=readme-ov-file#missing-return-values), an example of this is USDT, which is mentioned that the protocol will use it.
principalToken.approve(address(TELLER_V2), _principalAmount);No response
No response
No response
No response
No response
Use safeApprove instead of approve.