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

`WrappedNativeToken` Can Only Work in `NativeToken` Mode

jesjupyter

Summary

In the TokenManager::tillIn function, if _tokenAddress is equal to wrappedNativeToken, the function directly assumes that a native token is being used and checks msg.value for sufficient funds. This approach limits the functionality of wrappedNativeToken when it is used as an ERC-20 token, leading to unintended transaction reverts even when the user has approved sufficient funds.

Vulnerability Details

The TokenManager::tillIn function has a conditional check that determines if the _tokenAddress is equal to wrappedNativeToken. If this condition is met, the function assumes that the transaction involves the native token (e.g., ETH) and checks if msg.value is greater than or equal to _amount. If msg.value is insufficient, the transaction reverts:

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);
}

This implementation does not consider cases where wrappedNativeToken (e.g., WETH) is being used as a regular ERC-20 token in functions like PreMarkets::createOffer. In such cases, even if the user has already approved sufficient WETH, the transaction would still revert due to the insufficient msg.value, causing unintended reverts.

Consider the following case:

  1. A user intends to use wrappedNativeToken (e.g., WETH) directly in PreMarkets::createOffer.

  2. Despite having approved enough WETH, the transaction would still revert because msg.value does not match the _amount required, leading to an unintended failure.

Impact

This issue restricts the flexibility of using wrappedNativeToken as an ERC-20 token and can lead to unintended transaction failures. Users attempting to interact with the contract using wrappedNativeToken which is a normal/frequent case may face unexpected reverts, hindering the user experience and limiting contract functionality.

Tools Used

Manual

Recommendations

To address this issue, it is recommended to introduce a separate address that explicitly represents the native token (e.g., ETH). For example, the commonly used address 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee could be utilized to signify the native token. The condition should then differentiate between wrappedNativeToken (used as an ERC-20 token) and the native token (ETH) itself:

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.