hash - Setting minDebt and minBorrow to low values can cause protocol to accrue bad debt

[sherlock-admin2]

hash

Medium

Setting minDebt and minBorrow to low values can cause protocol to accrue bad debt

Summary

Setting minDebt and minBorrow to low values can cause protocol to accrue bad debt as liquidators won't find enough incentive in clearing the low debt and also depending on the price, users may be able to borrow dust without providing collateral

Vulnerability Detail

minDebt and minBorrow are supposed to be settable from 0

link

Min Debt = from 0 to 0.05 ETH = from 0 to 50000000000000000
Min Borrow = from 0 to 0.05 ETH = from 0 to 50000000000000000

Setting these to low values will allow positions to be created with low debts and liquidations won't happen on small positions due to it not generating enough profit to cover the costs of the liquidator. This will cause the protocol to accure bad debt.
Also if both are set to dust, the roundings will become significant and allows one to borrow dust amounts without proper collateral. Eg, if both are set to 0 and the price of assets is less than that of eth, the borrowing 1 wei of the assets will require no collateral as the value in eth will be rounded to 0

Impact

Protocol can accrue bad debt leading to depositors loosing their assets in case the values are set low

Code Snippet

https://github.com/sherlock-audit/2024-08-sentiment-v2/tree/main?tab=readme-ov-file#q-are-there-any-limitations-on-values-set-by-admins-or-other-roles-in-the-codebase-including-restrictions-on-array-lengths

Tool used

Manual Review

Recommendation

Ensure the minDebt,minBorrow values are not decreased below a certain threshold

[z3s]

Admin won't set minDebt and/or minBorrow to zero

[serial-coder]

I cannot escalate the issue due to insufficient escalation threshold

Hi @z3s,

Your statement is not true:

Admin won't set minDebt and/or minBorrow to zero

Please refer to the following excerpts from the contest public channel.

• ruvaag (sponsor): "another common query regarding minDebt and defaultInterestFee, while they won't be zero in our current deployment, they could be zero in future deployments" (https://discord.com/channels/812037309376495636/1273304663277572096/1275023937687916595)

• 0xb0k0 (watson): "what about minBorrow amount? Do you plan on having a 0 amount for it in the future?" (https://discord.com/channels/812037309376495636/1273304663277572096/1275033430140387359)

• ruvaag (sponsor): "yes while not in this deployment, we could set this in a future deployment. so if there are issues arising from that, we'd like to know so that beforehand" (https://discord.com/channels/812037309376495636/1273304663277572096/1275066936669245571)

Furthermore, the "Sponsor Confirmed" tag also confirms that the sponsor considers this issue valid.

Thanks for your time.

[kazantseff]

Escalate,
per the above comment

[sherlock-admin3]

Escalate,
per the above comment

You've created a valid escalation!

To remove the escalation from consideration: Delete your comment.

You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.

[cvetanovv]

I agree with the escalation.

In the Readme, we have values that the TRUSTED admin will set. That is exactly the purpose of this question in the Readme:
https://github.com/sherlock-audit/2024-08-sentiment-v2?tab=readme-ov-file#q-are-there-any-limitations-on-values-set-by-admins-or-other-roles-in-the-codebase-including-restrictions-on-array-lengths

There we can see that the admin will use low values for Min Debt and Min Borrow:

Min Debt = from 0 to 0.05 ETH
Min Borrow = from 0 to 0.05 ETH

If low values are set for minDebt and minBorrow, a liquidator will have no incentive to liquidate the position. This means that the protocol can accrue bad debt.

Planning to accept the escalation and make this issue a Medium severity.

[WangSecurity]

Result:
Medium
Has duplicates

[sherlock-admin4]

Escalations have been resolved successfully!

Escalation status:

• kazantseff: accepted

[AlexCZM]

Note to @cvetanovv:
#181 is a duplicate. Moreover that issue has a more complete description and I propose to make it the main issue.

[cvetanovv]

@AlexCZM I agree that #181 is a duplicate of this issue and will duplicate it.