Submitted by T1MOH
Protocol mints incorrect depositAmount and depositShare to protocol. Such that reserveFee is higher than defined. Suppose following scenario:
Lender pays this extra fee.
Here is gist with all tests https://gist.github.com/T1MOH593/34729b5333fe43eb58cf8b4948ef137f
First part: Show that issue exists. It is shown in custom_test1().
Second part: Explaining the issue.
Lets set initial values, for example:
Tranche 2 has 20% APR, 5_000 borrowed, 20_000 deposited; Tranche 1 has 10% APR, 10_000 borrowed, 20_000 depositeed. And we use 1 year as time difference to ease calculations.
Tranche struct has 2 types of variables, lets focus regarding deposit: totalDepositAmount and totalDepositShare. Initially without accrued interest they equal, 1 : 1, in above scenario will be 20_000 in both tranches. As the time passes, interest accrues. It means that totalDepositAmount increases. If reserveFee is 0%, thats it - for example 1000 of interests accrued, totalDepositAmount is increased by 1000.
However in case 10% of interest must be paid to reserve. It means that extra shares will be minted increasing totalDepositShare AND totalDepositAmount should be also increased because otherwise users balance will decrease. Lets take delta of totalDepositAmount as X and totalDepositShare as Y. And calculate these values for above scenario.
Solving this we get X = 1500, Y = 140.51. I.e. 140.51 of shares must be minted to Reserve, and totalDepositAmount must be increased by 1500 (amount of accrued interest) in Tranche2.
Now lets calculate accordingly for Tranche1:
X = 500, Y = 48.89.
However current implementation mints 100 shares to Reserve and increases totalDepositAmount by 1450 in Tranche 2; Also mints 100 shares to reserve and increases totalDepositAmount by 550 in Tranche1 as shown in test custom_test2
This is the core issue: Code always mints amount of shares equal to reserveInterest to Reserve (100 in this example) and calculates sub-optimal amount of depositAmount to increase.
Foundry
Fix is not obvious at all, its the most difficult part of report to be honest.
Algorithm should be completely refactored, should be implemented following accounting:
And also write tests to check reserveFee amounts, now they absent
cccz (Judge) commented:
allenjlee (BetaFinance) confirmed and commented:
