The _calculateInterest
function is vulnerable to precision loss. Due to dividing twice the function will return zero for both interest and protocolInterest
. This could lead to a lender giving their loan to another pool that doesn't have the balance to cover it. Leading to a loss for them and a gain for the future pools as they will have debts greater than their balance.
giveLoan()
calls _calculateInterest()
which then returns the amount of interest the protocol fee and adds that to the loan (debt) in order to calculate the totalDebt
.However, we already determined that these values are vulnerable to precision loss leading them to return 0 in some cases or be smaller than expected. That would lead to an inaccurate totalDebt
and loanRatio
allowing us to give a loan to a pool that has a higher loan ratio than our current pool which is not the expected behavior of the protocol.
The effect of this is the loanRatio
value will be lower than expected.
This would allow a user to move their loan to a pool in which their loanRatio is greater than the maxloanRatio for that pool. Allowing them to move and create loans to pools with less collateral than the pool requires.
Verifying that neither the interest rate nor the fees are zero can help prevent precision loss and trigger a reversal if necessary. Additionally, establishing a minimum loan size could ensure that the left side of the equation consistently exceeds the right side.
Another solution is creating a formula that always rounds up. This is in favor of the lender and the protocol as well. Something like this would suffice.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.