Not compound rate variation ?

[MathisGD]

          I seriously wonder if it is not a bit overkill. This computation cost a non-negligible amount of gas, and it is complex: it requires to ensure that there are no overflow in a computation up to a power of 12 (and it has also a limit when the linear variation is < -3).

Something simpler like

        uint256 variationMultiplier = WAD_INT + linearVariation;

would not have those issues. I understand that we would lose the property that having multiple updates in an interval is the same as having one update at the end, but this is only a third order loss in the worst case:

• approximating an amount is a first order precision issue
• approximating the rate (for example linear instead of compounded) is a second order precision issue
• approximating the variation of the rate is a third order precision issue

It was already unclear for rates if it was worth the extra computation cost, it may be the case here that it's not worth at all

Originally posted by @QGarchery in #1 (comment)

[MathisGD]

I think that the benefit of this is small now that we have #12