Foundry DeFi Stablecoin CodeHawks Audit Contest
Cyfrin
DeFiFoundry
15,000 USDC
View results
Previous Next
Submission Details
Severity: medium

There is no way to recover collateral tokens accumulated on the dscEngine contract as a result of liquidation transactions

natzuu

Summary

The smart contract audit for the "dscEngine" contract revealed a critical design flaw concerning the handling of excess funds earned from liquidation processes. Currently, these funds remain locked within the contract, with no mechanism in place for the protocol owners or administrators to access them. This omission could potentially impact the protocol's long-term sustainability and financing.

Vulnerability Details

The vulnerability pertains to the lack of a designated function or mechanism to manage the excess funds accumulated during liquidation processes. As a result, any surplus funds generated by the protocol's operations are effectively stuck within the contract, inaccessible to the protocol owners or administrators.
https://github.com/Cyfrin/2023-07-foundry-defi-stablecoin/blob/d1c5501aa79320ca0aeaa73f47f0dbc88c7b77e2/src/DSCEngine.sol#L217-L262

* @param collateral The erc20 collateral address to liquidate from the user
* @param user The user who has broken the health factor. Their _healthFactor should be below MIN_HEALTH_FACTOR
* @param debtToCover The amount of DSC you want to burn to improve the users health factor
* @notice You can partially liquidate a user.
* @notice You will get a liquidation bonus for taking the users funds
* @notice This function working assumes the protocol will be roughly 200% overcollateralized in order for this to work.
* @notice A known bug would be if the protocol were 100% or less collateralized, then we wouldn't be able to incentive the liquidators.
* For example, if the price of the collateral plummeted before anyone could be liquidated.
*
* Follows CEI: Checks, Effects, Interactions
*/
function liquidate(address collateral, address user, uint256 debtToCover)
external
moreThanZero(debtToCover)
nonReentrant
{
// need to check health factor of the user
uint256 startingUserHealthFactor = _healthFactor(user);
if (startingUserHealthFactor >= MIN_HEALTH_FACTOR) {
revert DSCEngine__HealthFactorOk();
}
// We want to burn their DSC "debt"
// And take their collateral
// Bad User: $140 ETH, $100 DSC
// debtToCover = $100
// $100 of DSC == ??? ETH?
// 0.05 ETH
uint256 tokenAmountFromDebtCovered = getTokenAmountFromUsd(collateral, debtToCover);
// And give them a 10% bonus
// So we are giving the liquidator $110 of WETH for 100 DSC
// We should implement a feature to liquidate in the event the protocol is insolvent
// And sweep extra amounts into a treasury
// 0.05 * 0.1 = 0.005. Getting 0.055
uint256 bonusCollateral = (tokenAmountFromDebtCovered * LIQUIDATION_BONUS) / LIQUIDATION_PRECISION;
uint256 totalCollateralToRedeem = tokenAmountFromDebtCovered + bonusCollateral;
_redeemCollateral(user, msg.sender, collateral, totalCollateralToRedeem);
// We need to burn the DSC
_burnDsc(debtToCover, user, msg.sender);
​
​
uint256 endingUserHealthFactor = _healthFactor(user);
if (endingUserHealthFactor <= startingUserHealthFactor) {
revert DSCEngine__HealthFactorNotImproved();
}
_revertIfHealthFactorIsBroken(msg.sender);
}

Impact

While this issue does not directly affect the security and immediate functionality of the protocol, it has significant implications for the long-term development and sustainability of the platform. The inability to access and utilize the excess funds could hinder the protocol's growth and hinder the funding required for ongoing development and maintenance.

Recommendations

To address the design flaw and enhance the sustainability of the "dscEngine" contract, the following recommendations are proposed:

  1. Add an Administrator Function: Implement a new function that allows protocol owners or designated administrators to access and transfer the excess funds accumulated from liquidation processes. This function should include proper access control mechanisms to ensure that only authorized entities can trigger fund transfers.

  2. Automatic Redirection of Excess Funds: Consider introducing an automatic redirection mechanism for excess funds. After liquidation processes, any surplus funds can be automatically directed to a reserve pool or other designated areas of the protocol. This would enhance the protocol's liquidity and ensure that the excess funds are effectively utilized.

  3. Community Decision-Making: If the "dscEngine" protocol operates under a decentralized governance structure, consider organizing a community vote to determine how to utilize the excess funds. This approach would empower protocol users to actively participate in decision-making and allocate the funds based on the community's needs and priorities.

Support

FAQs

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