Summary

The health check calculation relies on the s_DSCMinted variable to correctly represent the user's DSC balance. However, due to incorrect logic in the liquidate() function, s_DSCMinted is not updated for the liquidator even though he paid DSC to redeem the collateral. This means s_DSCMinted will be greater than the actual DSC balance of the participant and the health check will be incorrectly calculated.

Vulnerability Details

The health check is a pivotal part of the system and determines whether a position can be liquidated and it determines if a participant can liquidate a position.

Since the s_DSCMinted variable is used for this calculation, it must exactly mirror the balance of the DSC of all participants.

However, due to faulty logic in the liquidate() function, this is not the case.

The liquidator pays DSC to liquidate a position and receive collateral. However, s_DSCMinted is only reduced for the liquidated user, not for the liquidator.

As a result, the amount stated in s_DSCMinted will be greater than the liquidator's actual balance, and this discrepancy will increase with each liquidation performed.

Impact

Positions with a collateral rate over 200% will be deemed eligible for liquidation and users that should be able to liquidate positions will be denied due to having a too-small health factor.

This finding completely breaks the proper functioning of the protocol.

Tools Used

Manual review,

Recommendations

Create a separate _burnDSC function for liquidation wherein the s_DSCMinted balance of both the user & liquidator is correctly updated.