TokenManager.sol documentation says that it should accept either ERC20 or a native token but the check in tillInfunction for native tokens is wrong - initializing TokenManager with the address of the wrapped token(as done in the tests provided) and passing that address as tokenAddressin params means that the tillInfunction will never work with the wrapped(WETH) token and will always wrap the native token(ETH) first.
The check in https://github.com/Cyfrin/2024-08-tadle/blob/main/src/core/TokenManager.sol#L79-L80 for checking if transferring a native token means that it'll never work with the wrapped token because it checks if if (_tokenAddress == wrappedNativeToken),with wrappedNativeTokenaddress being the address of the wrapped token i.e having native token to be ETH, wrappedNativeToken will be WETH so when depositing a native token, if the _tokenAddressis 0x0, as it's supposed to be according to part of the documentation, transferring the native token will never work because it'll try to transfer it as a normal ERC20 token.
Otherwise, if the _tokenAddressis the address of the wrapped native token, as it is done in the provided tests, it'll always transfer the native token first and then wrap it. In this case, it's impossible to deposit the ERC20 wrapped token, as the code always requires to have the native token available.
Excerpt of the tillIn code in TokenManager.sol:
This breaks one of the main functionalities of the contract to accept native tokens and wrapped ERC20 tokens.
Manual review
If 0x0 is supposed to be internally viewed as the native ETH token, fix the check to that and use that in offer params, but the convention is to use 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee:
Valid medium severity, given it is noted in contest READ.ME that any standard ERC20 tokens should be supported. Although arguably could be low severity, given users can simply unwrap WETH to native ETH and perform the deposits via `tillIn()`, I will leave open for discussions, but taking READ.ME as the source of truth, I believe medium severity is appropriate, given it is explicitly noted that this token should be compatible#9##. The fix would be to utilize a zero address or equivalent to represent native ETH when wrapping to WETH. > Tokens: - ETH - WETH - ERC20 (any token that follows the ERC20 standard)
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.