Harmonize p2p rate computation

[Rubilmax]

Pull Request

Issue(s) fixed

• closes [R&D review] Reuse computation for p2p rate per block #1484

[MathisGD]

There are other places where the function could be used.

[MathisGD]

isn't this function supposed to handle the case where the rates are inverted ?

[Rubilmax]

Yes, but this PR does not address this issue. I chose to handle them independently. I'm opening a PR on top of this one to handle #1467 (the one in your mind)

[Rubilmax]

Also, inverted spreads are only possible on aave-v2?

[MathisGD]

No on both, but for different reasons

[Rubilmax]

There are other places where the function could be used.

Please show me (note the function doesn't exist in aave-v2's InterestRatesModel)

[MathisGD]

In the aave-v2/RatesLens.sol sorry, at least lines 219 275 and 335.

[Rubilmax]

In the aave-v2/RatesLens.sol sorry, at least lines 219 275 and 335.

Just force-pushed (because it's a change of paradigm) a new version, getting rid of this unnecessary function in InterestRatesModel (just use weightedAvg everywhere instead)

[MathisGD]

Don't we have issues here when the spread is natively inverted ? This time, I was in favor of having an internal function

[MathisGD]

Still one question to answer

[MerlinEgalite]

Don't we have issues here when the spread is natively inverted ? This time, I was in favor of having an internal function

Can we have the same issue as on Aave? Knowing that there's no flashloans nor stable rates on Compound.

Anyway, I think it's safe doing the same we did on Aave.

[MathisGD]

Can we have the same issue as on Aave? Knowing that there's no flashloans nor stable rates on Compound.

The indexes can grow as if there were an inverted spread, when someone send some token on the cToken contract

[MerlinEgalite]

Can we have the same issue as on Aave? Knowing that there's no flashloans nor stable rates on Compound.

The indexes can grow as if there were an inverted spread, when someone send some token on the cToken contract

Yes but it broke the growth factors, not the rates no? But as I say I'm for changing it

[MathisGD]

Yes but it broke the growth factors, not the rates no? But as I say I'm for changing it

tbh I don't remember how the supply rate is computed exacly on Compound

[Rubilmax]

https://github.com/compound-finance/compound-protocol/blob/master/contracts/WhitePaperInterestRateModel.sol

On Compound, $supplyRate = utilization * borrowRate * (1 - r)$, which ensures that $supplyRate <= borrowRate$ (because $0 <= utilization <= 1$ and $0 <= r <= 1$), so it's safe to me

Note: $utilization$ as well as $borrowRate$ can be decreased by manipulating getCashPrior (sending underlyings to the CToken contract), but the above argument is enough alone

[QGarchery]

https://github.com/compound-finance/compound-protocol/blob/master/contracts/WhitePaperInterestRateModel.sol

On Compound, supplyRate=utilization∗borrowRate∗(1−r), which ensures that supplyRate<=borrowRate (because 0<=utilization<=1 and 0<=r<=1), so it's safe to me

Note: utilization as well as borrowRate can be decreased by manipulating getCashPrior (sending underlyings to the CToken contract), but the above argument is enough alone

The white paper abstracts the computation too much in this case. Only the supply index is changed if some underlying tokens are sent to the cToken contract, so the equality does not stand anymore. See the computation of the supply index. Notice that the function exchangeRateCurrent accrues the interests, I found that those comments are the easiest to read.

For an explanation of why the equation stands without transfer of underlyings to the cToken contract : https://github.com/morpho-labs/morpho-yellowpaper/issues/117

[Rubilmax]

Seen together:

1. The WhitePaperInterestRateModel is not the IRM actually used in production. The one used is JumpRateModelV2
2. The equation I written still stands with the current used IRM, and is based on the code from getSupplyRate, called by CTokens (https://github.com/compound-finance/compound-protocol/blob/a3214f67b73310d547e00fc578e8355911c9d376/contracts/CToken.sol#L203-L217)

Note: Compound exposes rates per block which are not computed based on the CToken indexes. This is what we call "desync", because the indexes can grow by sending underlyings to CTokens, and may grow faster than what is computed by supplyRatePerBlock
For now though, we do use rates per block computed by Compound, from supplyRatePerBlock & borrowRatePerBlock, which were just proven to always be in ascending order

[MerlinEgalite]

Note: I think we should not rely on papers but on the code for the behavior of the underlying contracts we're plugging into.