CS-BOLD-016 Informational 7.9: Insufficient Gas Compensation Could Mint Bad Debt

[bingen]

The system relies on the gas compensation to be sufficient to cover the gas costs of the liquidation. If the gas cost of a liquidation is higher than the gas compensation, the system can end up with bad debt. This can happen due to falling collateral prices, in which case no new debt can be directly minted to insufficiently collateralized troves. However, bad debt can still be newly minted through interest and batch fee accrual, if the gas is expensive for extended periods of time.

An attacker could join their own batch and set the batch management fee to the maximum amount (currently 100%) to mint themselves tokens. If liquidations stay expensive for months, this could be profitable. A user could also create a batch with ICR = 1.1 and the maximum interest rate (currently 100% APR) and join the stability pool to which the interest is minted. If it is unprofitable to liquidate the trove, after about 4 days unbacked tokens will be minted to the stability pool (as the interest will surpass the 10% overcollateralization).

However, both of these attacks can easily be punished by anyone willing to make an unprofitable liquidation, so they incur a high risk for the attacker. As timely liquidations are profitable for the stability pool, anyone who is part of the stability pool also has an additional incentive to liquidate. These factors make the described attacks unlikely to be profitable.

Note that there is a variable gas compensation dependent on a trove's collateral amount, so liquidations of larger troves are more likely to be profitable than those of smaller troves.

In conclusion, these attacks are likely not of concern unless the gas prices on Ethereum significantly and
permanently increase in the years to come. However, they illustrate how the debt of the system can increase (and be minted to an attacker), even when troves fall below the minimum collateralization ratio.

[bingen]

Indeed, we are aware that the liquidation mechanism is not perfect. We’ve had long discussions about it internally.
As mentioned in the issue, big troves are prioritized, so it’s very unlikely that this becomes a problem for the system health.
Based also on Liquity v1 experience, we are confident that the mechanism will be robust enough.