The DebtToken contract’s burn function returns a tuple in the order (amount, totalSupply(), amountScaled, balanceIncrease). However, in the LendingPool contract’s _repay function, the returned values are destructured in a different order, which causes the variables to be misinterpreted. This misordering leads to improper updates of the user’s debt balance during repayment.
Location: DebtToken.burn (return order) and LendingPool._repay function (variable assignment)
Impact: Incorrect variable interpretation in the repayment process, potentially resulting in inaccurate debt balance updates
• Return Order in DebtToken.burn:
The burn function is implemented as follows:
• Variable Destructuring in LendingPool._repay:
The _repay function incorrectly assumes the return order as:
This causes:
• The first returned value amount to be interpreted as amountScaled.
• Subsequent values are similarly misassigned.
• Inaccurate Debt Accounting: The misinterpretation of return values can result in the wrong debt amounts being deducted, leading to discrepancies in the user’s debt balance.
If the intended return order is (amount, totalSupply(), amountScaled, balanceIncrease), then update the _repay function to destructure the tuple accordingly:
Interest IS applied through the balanceOf() mechanism. The separate balanceIncrease calculation is redundant/wrong. Users pay full debt including interest via userBalance capping.
Interest IS applied through the balanceOf() mechanism. The separate balanceIncrease calculation is redundant/wrong. Users pay full debt including interest via userBalance capping.
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.