Tadle
Tadle
DeFiFoundry
27,750 USDC
View results
Previous Next
Submission Details
Severity: medium
Valid

Users cannot create offers with WETH

4eyes

Summary

A vulnerability was identified in the createOffer() function within the smart contract, which prevents users from successfully creating offers using Wrapped Ether (WETH). The issue arises due to improper handling of WETH within the TokenManager.sol::tillIn() function, leading to a transaction revert.

Code Snippet:

function tillIn(
address _accountAddress,
address _tokenAddress,
uint256 _amount,
bool _isPointToken
)
external
payable
onlyRelatedContracts(tadleFactory, _msgSender())
onlyInTokenWhiteList(_isPointToken, _tokenAddress)
{
/// @notice return if amount is 0
if (_amount == 0) {
return;
}
​
​
address capitalPoolAddr = tadleFactory.relatedContracts(
RelatedContractLibraries.CAPITAL_POOL
);
if (capitalPoolAddr == address(0x0)) {
revert Errors.ContractIsNotDeployed();
}
​
​
if (_tokenAddress == wrappedNativeToken) {
/**
* @dev token is native token
* @notice check msg value
* @dev if msg value is less than _amount, revert
* @dev wrap native token and transfer to capital pool
*/
if (msg.value < _amount) {
revert Errors.NotEnoughMsgValue(msg.value, _amount);
}
IWrappedNativeToken(wrappedNativeToken).deposit{value: _amount}();
_safe_transfer(wrappedNativeToken, capitalPoolAddr, _amount);
} else {
/// @notice token is ERC20 token
_transfer(
_tokenAddress,
_accountAddress,
capitalPoolAddr,
_amount,
capitalPoolAddr
);
}
​
​
emit TillIn(_accountAddress, _tokenAddress, _amount, _isPointToken);
}

Vulnerability Details

When the createOffer() function is executed, it calls the TokenManager.sol::tillIn() function, passing several parameters, including tokenAddress. If a user attempts to transfer WETH, the following code is executed:

if (_tokenAddress == wrappedNativeToken) {
/**
* @dev token is native token
* @notice check msg value
* @dev if msg value is less than _amount, revert
* @dev wrap native token and transfer to capital pool
*/
if (msg.value < _amount) {
revert Errors.NotEnoughMsgValue(msg.value, _amount);
}
IWrappedNativeToken(wrappedNativeToken).deposit{value: _amount}();
_safe_transfer(wrappedNativeToken, capitalPoolAddr, _amount);
} else {
/// @notice token is ERC20 token
_transfer(
_tokenAddress,
_accountAddress,
capitalPoolAddr,
_amount,
capitalPoolAddr
);
}

In this logic, when tokenAddress == wrappedNativeToken, the function assumes the user is transferring the native token (ETH) and attempts to wrap it. The problematic line is:

if (msg.value < _amount) {
revert Errors.NotEnoughMsgValue(msg.value, _amount);
}

If the user is transferring WETH (an ERC-20 token) instead of ETH, msg.value will be 0, causing the function to revert, as the condition msg.value < _amount will be true.

Impact

Users cannot create offers using WETH. Based on documentation, users should be able to use any ERC20.

Tools Used

Manual review

Recommendations

Implement a mechanism that handle WETH transfers. For example add a if statement in tillIn() which cheks if wrappedNativeToken is send with msg.value=0. If this is the case treat it like any other ERC20.

Updates

Lead Judging Commences

0xnevi Lead Judge about 1 year ago
Submission Judgement Published
Validated
Assigned finding tags:

finding-TokenManager-tillin-wrapper-inconsistent

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)

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.