Should we use a non-view function for the borrow rate?

[MerlinEgalite]

This may not be possible to have a view function to get the borrow rate. Maybe we should consider that it won't be a view function at some point

Originally posted by @MerlinEgalite in #138 (comment)

[Rubilmax]

It is necessary to have a permissionless view function on the IRM to be able to calculate accrued interests on-chain, without having to update the market on Blue.

So if the borrowRate function cannot be a view, we need to expect the IRM to provide another view function so that integrators (including MetaMorpho vaults) have the ability to calculate accrued interests without updating the market on Blue. Or else, we can just discard the issue we're trying to solve, because it would simply be impossible to calculate interests accrued without updating the market on Blue.

Additional thoughts on this:

If it's not a view, it needs to be only accessible by Blue, otherwise anyone can change the storage of the IRM without updating Blue (just like Morpho optimizers on Compound/Aave).
Or we need to have some additional storage on Blue (just like Morpho optimizers have additional storage to keep up with Compound/Aave independent updates).

I'd like to have @morpho-labs/research's POV on this

[makcandrov]

Could you give an example of an IRM that would need to update storage at each borrowRate call? I can't think of any

[Rubilmax]

Could you give an example of an IRM that would need to update storage at each borrowRate call? I can't think of any

I believe a canonic example would be a second-order controller IRM, which would require storing the first-order derivative of the rate somewhere (the rate being always stored and accessible on Blue).

[MerlinEgalite]

Could you give an example of an IRM that would need to update storage at each borrowRate call? I can't think of any

Maybe one that is depending on something external like the votality of the different assets, the available liquidity onchain, etc. This might be the first IRM that we implement obviously but if it's a view then it's clear that it won't be possible.

[MerlinEgalite]

Btw this is possible using solidity so I don't really see the blocker of not removing view.

[Rubilmax]

Btw this is possible using solidity so I don't really see the blocker of not removing view.

If the function as defined in the interface doesn't have the view modifier, it cannot be called inside the context of a view function. Your example does not indicate otherwise.

[MerlinEgalite]

Is it a requirement for borrowRate to be view?

[Rubilmax]

In the PR this issue originates from yes, in order to expose a getter for accrued interests, which requires querying the borrow rate.

[MerlinEgalite]

in order to expose a getter for accrued interests

I recently changed my mind and I'm questioning the relevance of such getter 😅

[MerlinEgalite]

why? Seems that everyone was against

[MathisGD]

Sorry, I didn't have time to answer but we need to change something here. I'm focusing on #194 vs #123 for the moment and then I answer.

[MathisGD]

We should allow for non-view IRM, and it's current state of the code so I'm closing.