Tadle
Tadle
DeFi
30,000 USDC
View results
Previous Next
Submission Details
Severity: low
Invalid

Excessive Funds Will Get Stuck in `PreMarket`

jesjupyter

Summary

In the TokenManager::tillIn function, the msg.value is checked against the _amount parameter to ensure that sufficient funds have been sent for the transaction. However, if the msg.value exceeds _amount, the excess funds are not refunded and remain stuck in the contract. This issue can arise due to mistakenly sent funds or sudden changes in fees. Consequently, the excess funds become trapped in the contract PreMarket.

Vulnerability Details

The issue arises from the following code in the TokenManager::tillIn function:

if (msg.value < _amount) {
revert Errors.NotEnoughMsgValue(msg.value, _amount);
}
IWrappedNativeToken(wrappedNativeToken).deposit{value: _amount}();
_safe_transfer(wrappedNativeToken, capitalPoolAddr, _amount);

In this code snippet, the function checks if the sent msg.value is less than the required _amount, reverting the transaction if it is. However, there is no mechanism to handle cases where msg.value is greater than _amount. As a result, the excess funds are not refunded to the sender and remain stuck in the contract PreMarket.

There are several cases when msg.value > _amount:

  1. User Error: A user may accidentally send more funds than required, resulting in excess funds being trapped.

  2. Fee Rate Changes: If the fee rate changes just before the user’s transaction, less value might be required, leaving the excess funds in the contract.

function createTaker(address _offer, uint256 _points) external payable {
...
@=> uint256 platformFeeRate = systemConfig.getPlatformFeeRate(_msgSender()); // <= could be updated
...
uint256 platformFee = depositAmount.mulDiv(
platformFeeRate,
Constants.PLATFORM_FEE_DECIMAL_SCALER
);
...
@=> _depositTokenWhenCreateTaker(
platformFee,
depositAmount,
tradeTax,
makerInfo,
offerInfo,
tokenManager
);
...
}
​
function _depositTokenWhenCreateTaker(...) {
...
@=> tokenManager.tillIn{value: msg.value}(
_msgSender(),
makerInfo.tokenAddress,
transferAmount,
false
);
...
}

Impact

The absence of a refund mechanism in TokenManager::tillIn leads to a scenario where any excess funds sent by the user are permanently trapped in the contract, effectively removing them from the user’s control. The vulnerability can result in a significant amount of ETH being permanently locked in the PreMarket contract due to user error or changes in fee rates. This creates a financial loss for users and reduces trust in the contract’s design.

Tools Used

Manual

Recommendations

Implement a Refund Mechanism: Modify the TokenManager::tillIn function to include a refund mechanism that returns any excess funds to the sender:

Updates

Lead Judging Commences

0xnevi Lead Judge 10 months ago
Submission Judgement Published
Invalidated
Reason: Known issue
Assigned finding tags:

[invalid] finding-TokenManager-tillin-excess

Invalid, these are by default, invalid based on codehawks [general guidelines](https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity#findings-that-may-be-invalid). The check implemented is simply a sufficiency check, it is users responsibility to only send an appropriate amount of native tokens where amount == msg.value when native token is intended to be used as collateral (which will subsequently be deposited as wrapped token). All excess ETH can be rescued using the `Rescuable.sol` contract. > Users sending ETH/native tokens > If contracts allow users to send tokens acc111identally.

Support

FAQs

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