Steadefi

Steadefi
DeFiHardhatFoundryOracle
35,000 USDC
View results
Submission Details
Severity: medium
Invalid

`DUST_AMOUNT` from the `emergencyWithdraw function` could get stuck in contract, leading to an accumulation of negligible assets over time

Summary

In contract, there is a potential issue related to the definition of the DUST_AMOUNT. This value is used in the emergencyWithdraw function to avoid leaving small amounts of assets behind during withdrawals. However, the specific context and definition of this value are not provided, making it unclear whether the value of 1e17 is appropriate. This vulnerability highlights the need for a review of the code to ensure that the dust amount is correctly defined for the system's context.

Vulnerability Details

In the emergencyWithdraw function, the code checks if the calculated user share balance minus the amount to be withdrawn is less than the DUST_AMOUNT. If this condition is met, the code ensures that the full user share balance is withdrawn, preventing dust amounts from remaining in the contract. The specific value of DUST_AMOUNT is set as 1e17, but there is no context or explanation regarding how this value was determined or whether it is suitable for the system.

function emergencyWithdraw(
GMXTypes.Store storage self,
uint256 shareAmt
) external {
// check to ensure shares withdrawn does not exceed user's balance
uint256 _userShareBalance = IERC20(address(self.vault)).balanceOf(msg.sender);
// to avoid leaving dust behind
unchecked {
if (_userShareBalance - shareAmt < DUST_AMOUNT) {
shareAmt = _userShareBalance;
}
}
GMXChecks.beforeEmergencyWithdrawChecks(self, shareAmt);
// share ratio calculation must be before burn()
uint256 _shareRatio = shareAmt * SAFE_MULTIPLIER
/ IERC20(address(self.vault)).totalSupply();
self.vault.burn(msg.sender, shareAmt);
uint256 _withdrawAmtTokenA = _shareRatio
* self.tokenA.balanceOf(address(this))
/ SAFE_MULTIPLIER;
uint256 _withdrawAmtTokenB = _shareRatio
* self.tokenB.balanceOf(address(this))
/ SAFE_MULTIPLIER;
self.tokenA.safeTransfer(msg.sender, _withdrawAmtTokenA);
self.tokenB.safeTransfer(msg.sender, _withdrawAmtTokenB);
emit EmergencyWithdraw(
msg.sender,
shareAmt,
address(self.tokenA),
_withdrawAmtTokenA,
address(self.tokenB),
_withdrawAmtTokenB
);
}
}

Impact

The impact of this vulnerability could result in small amounts of assets, often referred to as "dust," getting stuck in the contract. This can lead to an accumulation of negligible assets over time, potentially affecting the efficiency and cleanliness of the contract.

Tools Used

VsCode

Recommendations

  1. Review and assess the specific context and requirements of the system to determine an appropriate value for DUST_AMOUNT. This value should be set to a level that prevents dust accumulation without inadvertently affecting legitimate withdrawals.

  2. Document the rationale and context behind the chosen DUST_AMOUNT value, both in the code comments and in the project's documentation.

  3. Consider incorporating a mechanism to sweep and clean dust amounts periodically if they do accumulate to ensure the efficient operation of the contract. This could be part of a maintenance function or routine.

Recommendation Example

// Define an appropriate dust amount based on the context
uint256 public constant DUST_AMOUNT = 1e16; // Example: 0.1 token (adjust as needed)
/**
* @notice Function to withdraw assets with dust amount handling
* @param self GMXTypes.Store
* @param shareAmt The amount of shares to withdraw
*/
function emergencyWithdraw(
GMXTypes.Store storage self,
uint256 shareAmt
) external {
// Check to ensure shares withdrawn do not exceed the user's balance
uint256 userShareBalance = IERC20(address(self.vault)).balanceOf(msg.sender);
if (userShareBalance - shareAmt < DUST_AMOUNT) {
// If the withdrawal would leave a dust amount, withdraw the full balance
shareAmt = userShareBalance;
}
// Rest of the withdrawal logic...
}
Updates

Lead Judging Commences

hans Lead Judge over 1 year ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
0xVinylDavyl Submitter
over 1 year ago
hans Auditor
over 1 year ago
0xVinylDavyl Submitter
over 1 year ago
hans Auditor
over 1 year ago
Steadefi Lead Judge
over 1 year ago
hans Lead Judge over 1 year ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
0xVinylDavyl Submitter
over 1 year ago
hans Lead Judge over 1 year ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

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