The _applyUpfrontFee function in BorrowerOperations contains the _requireICRisAboveMCR() check. This ensures that an upfrontfee from an adjustment cannot bring the trove below the MCR.
However, the setBatchManagerAnnualInterestRate function, which is used to adjust the interest rate of a batch, does not contain such a check (as troves in a batch can have different ICRs). As a result, it is possible for an upfrontfee of a batch interest adjustment to bring a trove below the MCR.
The batch interest rate can only be adjusted at most once per second, so if a trove is pushed below the MCR, it should be liquidated before the next adjustment can happen. If this limitation was not in place, batch interest could be adjusted many times in a block and potentially create bad debt when the ICR falls below 100%.
Other ways of bringing a Trove's ICR below MCR are:
As mentioned in the description, we enforced a minimum interest rate change frequency, so that only 1 change per block can happen and so this doesn’t become a real danger.
The
_applyUpfrontFee
function in BorrowerOperations contains the_requireICRisAboveMCR()
check. This ensures that an upfrontfee from an adjustment cannot bring the trove below the MCR.However, the
setBatchManagerAnnualInterestRate
function, which is used to adjust the interest rate of a batch, does not contain such a check (as troves in a batch can have different ICRs). As a result, it is possible for an upfrontfee of a batch interest adjustment to bring a trove below the MCR.The batch interest rate can only be adjusted at most once per second, so if a trove is pushed below the MCR, it should be liquidated before the next adjustment can happen. If this limitation was not in place, batch interest could be adjusted many times in a block and potentially create bad debt when the ICR falls below 100%.
Other ways of bringing a Trove's ICR below MCR are: