The implementation of tillIn(address,address,uint256,bool)
forces the msgSender()
to always transact using msg.value
when attempting to use a tokenAddress
of wrappedNativeToken
, they cannot use the ERC-20 itself.
Invocations to tillIn(address,address,uint256,bool)
have special handling for wrappedNativeToken
; it unconditionally deposits call's msg.value
into the IWrappedNativeToken
(i.e. WETH):
Consequently, this makes it impossible to transact using purely the IWrappedNativeToken
token balance of the caller via the _transfer(address,address,address,uint256,address)
, since this takes place in the opposing conitional branch designed specifically for ERC-20 transfers.
They have to use msg.value
, no exceptions.
Limited composability and arguable dependent client DoS for a crucial token type, since it is impossible to tillIn(address,address,uint256,bool)
using a raw IWrappedNativeToken
ERC-20 balances; callers are forced to transact using msg.value
exclusively.
This will no doubt attenuate the effectiveness of the TokenManager
.
Manual Review
When transacting using wrappedNativeToken
, the amount
supplied to the call should represent the IWrappedNativeToken
balance, which if non-zero, should be pulled from the caller.
If a non-zero msg.value
is supplied, we must then enforce that the msg.sender
has additionally declared a _tokenAddress
of IWrappedNativeToken
, else revert
.
Finally, the non-zero msg.value
should be deposited to the IWrappedNativeToken
contract, and the amount
should be increased to reflect this additional deposited amount.
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.