Since the LTV is based on tokens, so their no slippage to specify how much the price can increase or decrease for the lender to give out a loan. There is too much risk and can cause the borrower/lender lose and take on more risk
with vast price movements loanRatio
based on just collateral is not enough and can end up in scenarios where lender/borrower is at a disadvantage or advantage because of token prices let's say debt for this loan is usdc and collateral is weth lets say that weth token is at $1000 lender allows LTV=(1000e6 *1e18) /1e18); for loan Then the price drops and weth is worth 500 dollars the maxLoanRatio
will not go down causing the borrower to get a better rate and cause loss of funds for the lender
`uint256 loanRatio = (debt * 10 ** 18) / collateral;`
but this attack works only if collateral falls down in the first block so that it doesn't give enough time for the lender to update the loan terms Besides that ist also an assumption that the lender will call to update loanTerms every tx if the borrower doesn't pick up the loan causing a lot of gas and storage writes for the lender
as explained above can cause gas issues and most normal lenders won't have time to update the loan terms if the price of the tokens rapidly increases/decreases causing a loss to either party based on when they call it.
The reason this is an issue not just the spec is that normally the lender can specify the USD value of LTV so this scenario doesn't happen but here we don't do that
this protocol doesn't validate the edge cases and is undercomplex which enables this.I would redesign and use USD or give a range of how much the price can fall for the lender and borrower
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.