PID-regulated Liquidity Control

[steakhouse]

Problem Set

Currently Lido is spending multiple millions of dollars supporting liquidity in stETH/ETH pools, among others.

If the stETH/ETH exchange rate is <(1-x) where x is a fair liquidity / yield discount, new uesers prefer to buy the existing stETH from existing users, vs minting new stETH.

Therefore, in order for Lido to grow ETH deposits, Lido must maintain a stETH/ETH rate >(1-x).

Given there is structural selling pressure on stETH due to inability to withdraw (for now) and therefore arbitrage until the Shanghai update goes live, Lido essentially subsidizes all buying pressure at a static incentive rate per LP.

We’ve proposed the ratchet as one solution:

LDO_{max} = min \left(LDO_{n-1} \times (1-Red_{\%}), \frac{USD_{n} \times (1-Red_{\%})}{Price(LDO)} \right)

This means that month on month, the number of LDO issued is the lower of the previous month LDO issued times a reduction, or a new amount of LDO at the latest USD market price, which means the amount of LDO tends to ratchet down unless there are very large dislocations in market price.

However, this crude control solution solves for reducing spend on liquidity, not necessarily optimizing its outcome. What is missing is a reliable and scientific method for pushing and pulling liquidity only when and where its needed in a programmatic way.

Solution Proposed:

Steakhouse Skewer: PID-regulated Liquidity Control

• Only subsidize stETH/ETH LPs when the structural selling and buying pressures push the exchange rate off the target rate
• Pre-Shanghai, the target rate should be lower than the parity rate (assuming a discount rate higher than the yield due to liquidity premium)
• Use a PID controller method inspired by RAI to determine the correct amount of liquidity incentive for LPs

Overview of PID Controller Method

https://en.m.wikipedia.org/wiki/PID_controller

A PID controller is suitable in systems with a control process and an observed output of that process. Three components introduce a change in the control variable to implement a change in the desired direction for the output, according to different parameters.

The proportional component simply reverses the error, e.g. for a drift of e away from the target level, the proportional component will drive a -K_{p} \cdot e(t) change until the error is zeroed out.

The integral component increases with distance, the longer the drift persists, the larger the response, e.g. for a sustained drift over a period of time t, the integral component will increase by K_{i} \int^{t} e(\tau)d\tau until the error is zeroed out.

The derivative component will react more strongly with change, the sharper the change the larger the response, e.g. for a large market shock, the derivative component will increase more, by K_{d} \frac{de(t)}{dt}.

Application to liquidity

Our proposal for Lido would be to target a level of price drift away from a target rate of 1:1 relative to ETH, or close to it accounting for incentives and fees.

If the price of stETH in ETH terms drifts away from a desired level and arbitrage routes are unable to put pressure on the gap, the liquidity controller would be in charge of supplying incentives to LP pools until the exchange rate stabilized.

This liquidity incentive could be denominated in stETH or DAI. The liquidity controller contract would be loaded with a budgeted or reserve amount and a price oracle with keeper bot triggers would keep the controller functioning to supply its reserve to specified liquidity pools.

By applying a PID controller logic to liquidity discussions we can frame the choice of sizing the liquidity budget from a hard USD or ETH amount to a discussion around the parameters:

1. How much proportional response do we want to introduce to respond to a drift in the exchange rate?
2. How much do we want to ramp up to push against a drift in the exchange rate over time?
3. How strongly do we want to respond to instantaneous changes to the exchange rate?

Benefits

The chief benefit is to move away from a discussion about price levels, USD spend or any other type of one-off argument, and towards a principled discussion about parameter setting.

In the hypothesis that liquidity incentives are ineffective for sustaining the stETH rate, the controller would just drift towards 0 over time.

In the hypothesis that liquidity incentives are effective for sustaining the rate, we focus on tuning the parameters until we get the maximum possible effect for each DAI invested.

Drawbacks

Would likely require substantial implementation time though it could be tested ‘manually’ for effectiveness in the context of the rewards committee.

Ideally, pools would implement a similar mechanism on their end rather than at the protocol level. However, the protocol-level spend remains a primary lever for token holders at the moment.

Acknowledgements

@pipko, Rai

with apologies to rai

[jbeezy]

This is a great way to implement the next steps for the committee. I agree that implementation might be a blocker due to Shapella consuming all bandwidth RN.

There is additional work by the committee already being done on sensativity analysis in order to provide only the minimum required liquidity to handle liquidations and some confidence interval of swap volume (>95% imo).

The PID controller is the logical next step to remove the human data reading elements so I am supportive AF of this. Maybe a team can apply to LEGO

[kadmil]

Would note that even LEGO development would still be blocked on the way to mainnet due to security checks process

[kadmil]

Wowza, thank you for the proposal!

Testing the management framework manually first sounds like a great first step. It seems like something which could be implemented reasonably well given the reWARDS ops infra (both on-chain & array of analytics models).

Would mention that rewards aren’t continuous in most cases (weekly and monthly distribution cycles are almost everywhere), so the decision-making would be “stepped” as well