Root + Impact

Description

• * Users can redeem collateral while burning DSC in a single transaction. The function burns DSC debt first, then redeems collateral, then checks health factor.

  * The `redeem_collateral_for_dsc()` function burns DSC before redeeming collateral. This order is counterintuitive and could mask bugs, as typically you'd want to ensure sufficient collateral remains before reducing debt.

  ```vyper

  @external

  def redeem_collateral_for_dsc(

  token_collateral_address: address,

  amount_collateral: uint256,

  amount_dsc_to_burn: uint256,

  ):

  self._burn_dsc(amount_dsc_to_burn, msg.sender, msg.sender) // @> Debt reduced first

  self._redeem_collateral(

  token_collateral_address, amount_collateral, msg.sender, msg.sender

  ) // @> Collateral redeemed second

  self._revert_if_health_factor_is_broken(msg.sender) // @> Health factor checked last

  ```

Risk

Likelihood:

• * Users might expect collateral to be redeemed first to ensure sufficient collateral remains

  * If there's a bug in health factor calculation, this order might allow invalid operations

  * Front-running or MEV bots could exploit the order of operations

Impact:

• * Potential for confusion and unexpected behavior

  * Could mask bugs in health factor calculations

  * Users might not understand why operations succeed or fail

Proof of Concept

Recommended Mitigation