Summary

Due to the delayed calculation of the health factor, malicious users could perform multiple illegal operations before the health factor is recalculated.

Vulnerability Details

At this location in the code,
https://github.com/Cyfrin/2024-12-algo-ssstablecoinsss/blob/4cc3197b13f1db728fd6509cc1dcbfd7a2360179/src/dsc_engine.vy#L268-L274
the health factor check occurs after each operation. This means that if a user is able to perform multiple operations such as deposits, minting, or redemptions frequently, and the health factor is checked only after each operation, the following situation can arise:

Frequent operations within a short time span: Suppose a user repeatedly deposits and mints tokens, which changes the collateral and stablecoin balance. If the health factor is checked only after each operation and the system does not immediately flag low health factors, the user’s health factor may fall below the minimum threshold after multiple operations. However, these operations will still succeed, causing an inconsistency in the contract state and potentially leading to system insolvency.

For example:

• User A deposits some collateral and mints some DSC.

• User A deposits more collateral and mints more DSC.

• After these operations, User A’s health factor may drop below a safe threshold, but because the health factor is only checked after each operation, all these operations would have passed the health factor check, ultimately causing the health factor to drop below the minimum and destabilize the system.

Impact

If the health factor is breached and there is no immediate action (e.g., liquidation, warning), this could pose a risk to the system. For instance, a user could continuously mint DSC without concern for the health factor, driving the health factor to dangerously low levels, which would lead to an over-issuance of stablecoins, increasing the risk of system defaults.

Tools Used

Manual review

Recommendations

• Time Lock Mechanism A time lock mechanism can limit the frequency of operations by requiring a mandatory waiting period between consecutive operations. Even if users perform frequent actions, the time constraint will reduce the risk of excessive operations that could damage the system.

• Operation Frequency Limit To prevent excessive minting or redemption, the contract can impose a limit on the frequency of operations per user. For instance, if a user performs several operations in a short period, subsequent actions would be blocked until a specified cooldown period is reached.