Open code423n4 opened 1 year ago
berndartmueller marked the issue as primary issue
Can you give an example of a deflationary token? Does this mean that the balance goes down w.r.t. time or w.r.t being transferred.
Can you give an example of a deflationary token? Does this mean that the balance goes down w.r.t. time or w.r.t being transferred.
@kyscott18 With regard to being transferred.
https://github.com/d-xo/weird-erc20#fee-on-transfer is a great resource on this topic.
This finding and its dupes show a valid issue that prevents the use of rebase/FoT tokens with the protocol. As there is no clear mention of the support of non-standard ERC-20 tokens in the Numoen docs or contest README, I consider Medium the appropriate severity.
berndartmueller marked the issue as satisfactory
berndartmueller marked the issue as selected for report
How is this different from https://github.com/Uniswap/v3-core/blob/main/contracts/UniswapV3Pool.sol#L486-L490 ? If it isn't any different, which I don't think it is, then we will just acknowledge this and be mindful of which token we allow people to list.
@kyscott18
In this specific case of the mint(..)
function, there is no difference to Uniswap. Both implementations do not work properly for this kind of rebase/FoT tokens. Uniswap V3 is built on a setup of assumptions (see here), excluding rebase tokens.
It becomes a bigger issue if the use of rebase tokens can influence the token balance accounting of other regular ERC-20 token pairs, which is not the case for Numoen.
One of the other submissions presents further instances in the code which are potentially affected by incorrect token balance accounting caused by rebase/FoT token -> https://github.com/code-423n4/2023-01-numoen-findings/issues/272
Okay, thanks for clarify, I think we should mark this as noted by the team because we want to use the same assumptions as uniswap in this case
Lines of code
https://github.com/code-423n4/2023-01-numoen/blob/main/src/core/Lendgine.sol#L99
Vulnerability details
Impact
In Numoen, it does not specifically restrict the type of ERC20 collateral used for borrowing.
If fee on transfer token(s) is/are entailed, it will specifically make mint() revert in Lendgine.sol when checking if balanceAfter < balanceBefore + collateral.
Proof of Concept
File: Lendgine.sol#L71-L102
As can be seen from the code block above, line 99 is meant to be reverting when
balanceAfter < balanceBefore + collateral
. So in the case of deflationary tokens, the error is going to be thrown even though the token amount has been received due to the fee factor.Tools Used
Manual inspection
Recommended Mitigation Steps
Consider:
collateral
if deflationary token is going to be allowed in the protocol.