PID controlled interest rate curve attacks

[sambacha]

When do dynamic DeFi rate curves reduce capital efficiency?

From the unpublished paper:
https://gauntlet.network/reports/pid

The two major designs proposed for PID controlled interest rate curves are Euler Finance's reactive rates [2, 3] and Mars Protocol. Currently, only Mars Protocol has implemented $[13,14]$ and deployed a proportional interest rate controller to production. Euler Finance has signalled that they would introduce reactive rates pending further research. However, it appears that neither of these teams has formally analyzed their PID interest protocols.

We note that most PID designs in DeFi are either proportional (P) or proportional integral (PI) controllers. The PI controllers correspond to the utilization of time-weighted average quantities (akin to the Uniswap V3 TWAP oracle [9]). There are two reasons derivatives of rate changes are less useful in practice. First, the rate of change of an interest rate is more easily manipulable given the constraints of blockchains, such as large confirmation times. Moreover, the only reason to adjust a rate based on its gradient is to provide fixed-interest rate protocols. However, most fixed-interest rate protocols such as Yield and Notional, use more transaction cost efficient mechanisms than a PID controller [11]. As such, whenever DeFi enthusiasts talk about PID controlled interest rates, they usually only mean a P or PI controller.

profitability in the worst case for lenders: when there is no supply or demand elasticity. The supply and/or demand elasticity of a protocol refers to the expected rate of change of supply or demand in the protocol as a function of a rate change. We usually have the supply elasticity be positive when rates increase whereas the demand elasticity is negative. However, in many DeFi protocols there are a large swath of users who are completely inelastic to rate changes [5]. This means that the worst case condition of the attack is often true.

We also analyze how this attack is related to capital efficiency in the protocol. We demonstrate that the attack has low profitability if there is excess capital within the pool (e.g. the utilization rate and the target utilization rate are low and the supplied assets dwarf the demand). Similarly, if the protocol can time-lock assets (e.g. force a user who to supply or borrow for a minimum time period), the protocol can make such an attack significantly more expensive However, both of these options are very capital inefficient states for a lending protocol.
Our solution for mitigating this attack involves three components:

1. Using a PI controller which is more expensive to attack (see Appendix A)
2. Separating supply and demand curves (akin to what Compound V3 does [7])
3. Having the controller depend not only on utilization but also supply and demand elasticities

We also note that any off-chain optimization of interest rate curves should take attack profitability into account (which is what Gauntlet has focused on making sure we have battle tested before we roll out interest rate optimization recommendations).