# Interest rate model rivising

Based on what we have known on Interest protocol’s interest rate model, we found that we can improve its borrow rate model by introducing PID controller,(the deposit rate is based on the borrow rate and the protocol fee rate). The core design of the borrow rate model is that when s value is small, we want to raise both borrow rate to encourage users to pay their loans and deposit rate to encourage users to deposit USDC (both way will help to increase s value). Thus, the core design of new borrow rate model will also raise borrow rate when s value is small.

First of all, we need to understand what is PID controller: In brief, PID is an adjusting algorithm when we want to change a parameter W to its optimal value W0 by adjusting another parameter Y.

The formula is :

e(t) = W0 - W(t), it means the difference between W’s target value (or optimal value) and W’s value at time t.

Y(t) = Y(t-1) +u(t), it means we should adjust Y(t) to the sum of u(t) (calculated as above) and Y(t-1)

Introducing PID in our borrow rate model:

u(t) = P(t) + I(t) + D(t)

e(t) = S0 -S

P(t) = Kp * e(t)

I(t) = I(t-1) + Ki * e(t)

D(t) = Kd * ( e(t) -e(t-1) )

IR(t) = IR(t-1) + u(t)

S(t)is the s value at time t;

S0 is our target s value;

Kp、Ki、Kd are three parameters in PID’s formula;

IR(t) is the borrow rate at time t;

Tuning process:

In our first borrow rate model (three-line piecewise function), we apparently want s value to be above 0.4, so we can simply set S0 as 0.4 (S0 can be other number, and it also can be dynamic, here is just an example to show a simply way to value Kp、Ki、Kd)

To find optimal value for Kp、Ki、Kd (the process is called tunning), we are going to use Ziegler-nichols method (again, other methods can be used here).

Ziegler-nichols method process:

To complete the simulation in Ziegler-nichols method, we need a relationship betweer S(t) and IR(t), because in our PID example we want to affect S(t) by adjusting IR(t).

A simple way to set the simulation model:

When IR(t) is 0, S(t)should be 0, because no one would like to deposit.

When IR(t) is large enough, let’s say 0.5, S(t) should be 1,because none would like to carry the loans.

So we can have a simple simulation model:

S(t) = S(t-1) + ΔIR * 2 + whitenoise, ΔIR = IR(t-1) -IR(t-2)

IMPORTANT: the simulation model is very important in the process of finding best value for Ks, the actual simulation model can be very complicated and it should be based on testnet data if possible. Here is just a very basic linear simulation model used to show the process of tunning.

We set S(0) as 0.2 and IR(0) as 0.1. By following the third step of the graph above, we find the Kmax as 0.2 and f0 as 0.1, and thus we have Kp = 0.12, Ki = 0.024, Kd = 0.15 by using classic PID in the table(Ku =0.2 and Tu=10 inour case):

The graph of S(t) when we set Kp=0.2,Ki=0,Kd=0 and find sustained oscillation.

The graph of S(t) with Kp = 0.12, Ki = 0.024, Kd = 0.15

The graph of IR(t) with Kp = 0.12, Ki = 0.024, Kd = 0.15:

2 Likes

Thank you for your post! It is really cool to see folks take an interest in the protocol and its underlying mechanics. While I think it could be premature for us to adjust the interest rate system, I do think it makes sense to conduct research on the topic. It is unlikely we implemented the optimal interest rate system on the first try, and given its significance to the protocol, we should continue searching for a better system that balances safety and efficiency.

Could you explain more about how introducing the PID controller would benefit the protocol? My understanding is that the PID controller would have two major impacts on how the protocol sets the interest rate. First, the interest rate currently responds instantaneously to changes in the reserve ratio. With the PID controller, the rate would respond gradually over time. While reducing abrupt changes in the interest rate may be beneficial, I am not certain if sudden rate changes are or will be a critical issue for the protocol. As our TVL grows, the rate will respond less to small capital movements. And even now, the rate mostly stays within the target range between 50 bps and 10%.

The second and perhaps more important impact of the PID controller seems to be that the protocol can target a specific reserve ratio, instead of a range (currently 40% - 60%), by continuing to adjust rates until the target ratio is reached. This is an interesting idea, but it is not obvious to me that the protocol always benefits from this. For example, when there is low demand for USDi loans, we might want the protocol to offer less loans (i.e. have a higher reserve ratio) and maintain a high enough borrow rate, rather than continue lowering the borrow rate until the protocol has lent out the same amount of capital that it was lending out when the demand for loans was high. Of course, this depends on our assumptions about the market structure around Interest Protocol. I would be interested to hear more about your thoughts on the expected effects of PID.

Another important consideration is the onchain implementation of the PID controller. It does not look simple to me at first glance, since the current rate would have to depend on past states of the protocol and the time that has passed since those states came about. Note that right now, the protocol currently does not have to store the current interest rate or the past rates.

Here is my thoughts:
Firstly, I don’t think it is a problem that current interest rate responds instantaneously. Actually , the PID-form interest rate also responds very fast, because we can update t every time there is a user’s action or we can update t based on blocks. With optimal K parameters, interest rate can be adjusted to extreme values(if needed) within 5 time stamps.
Secondly, as I mentioned in the doc, the target reserve ratio (s value) can be dynamic, which means under different market/protocol condition we can have different target reserve ratio.
Thirdly, the math calculation of PID is very simple, and PID requires the protocol to store only the value at time t and time t-1. Uniswap has one slot to store data, and users can open another slot to store historical data(according to their need). I believe we can use the same way to store data. I think we can find a way to put PID-form interest rate on chain without high cost.
However, there is cost of PID. As I mentioned in the doc, to have a good PID model, we need a good simulation model for the relationship between s(t) and IR(t) (or how IR naturally impacts s) to have optimal K parameters. This means we need to do some statistical tests, and collect enough data. I believe this is the main disadvantages of PID-form interest rate model.
The benefit of PID model is that we don’t need to worry about if we need to change the parameters, especially after we find a good formula for target reserve ratio. Under current interest model, the interest rate is fixed for fixed reserve ratio. For example, on Monday s = 20%, the interest rate is fixed 300%, which might be the optimal value under given situation, but on Sunday s=20%, the interest rate is still 300%, which might not be the optimal value under different situation. You see, even if we have optimal values of r1,r2,r3,s1,s2,s3, we can’t change interest rate if s value keeps the same, and it is so hard to find dynamic functions with scientific logic for r1.r2.r3.s1.s2.s3. By using PID, we only need to find the dynamic function for target S value, which can be easy and scientific.
These are all my views!
Thank you!

A few points.

1. I don’t think a compelling case has been made there is some problem, or optimization needs to be addressed.

2. Since there is no compelling case for (1) I also don’t see any particular reason a PID loop is needed (feed forward or feed back).

3. As noted PID controllers (feed forward or feed back) are notorious for getting into oscillations, sometimes these are damped, other times they are not. Significant testing is required to determine optimal parameters to avoid oscillations.

4. Implementation of such PID controllers requires them to be active within a ‘time domain’ = t. Each time element the controller is active and ‘operating’. In the case of blockchain this requires some transaction be posted and some ‘sequence’ of transactions be posted for this to operate correctly.

I don’t see any analysis of how a PID controller could successfully operate within blockchain time constraints, nor how many transactions would be required for the PID controller to settle/converge to stable solutions. Additionally given this strong PID operational time constraint how this would work if the inputs are changing dramatically, and constantly. Assumptions around PID controllers are that inputs are seeking some steady state, and the operational time domain is such to allow this. I am not convinced these assumptions will always be maintained and hence without very careful consideration of not just the operational domain conditions, but what to fall back on if outside of these conditions would be required.

End analysis is that no case has been made regarding how the current interest rate model is sub-optimal, nor what a more optimal goal might be, much less that a PID loop (feed forward or back) is the most suitable choice.

1 Like