# SSV analysis - Setting / Adjusting DAO Controlled parameters analysis

[TOC]

## High level problem statement

* The highest priority with setting dao-controlled parameters is that Liquidations take place when cluster is at risk of running out of funds.
This is crucial, since under current system design, the SSV network contract could run out of funds and thus DAO or other operators may end up not being paid for their services.
* to ensure liquidations take place they must always be profitable. the important word here is *always*.

Here is a acompanying sheet to this document including all the calculations, charts and formulas.
[Setting / Adjusting for DAO Controlled parameters calc - Google Sheets](https://docs.google.com/spreadsheets/d/1Qy_BWbPtTjvFGcYANCW0Tvue6-7JR8cuklZqrADijaY/edit#gid=0)

### Variables affecting cost of liquidation

- gas amount -> `gasAmount`
- gas price -> `gasPrice`
- SSV/ETH price -> `SSVprice`

#### Asumptions
- Gas cost to liquidate a cluster is constant and never larger than 130_000 wei, I have used 140_000 wei in my calculations to be on the safe side.

If this assumption holds true, the only variables that will change in time and need to be analyzed are `gasPrice` and `SSVprice`.

### gasPrice

The main question is what is the minimum fee in a high fee environment that a liquidator can expect to pay to comfortably liquidate the account?

It is important to note that we are looking NOT looking for a max `gasPrice` but for a `gasPrice` which can safely be paid for a liquidation tx that ensures that it is included in some time period $p$.

In a practical example where $p=7 days$ this question is posed as:
What is the min `gasPrice` a liquidator must pay that ensures that his tx will get included within any consecutive 7 days?

Max amount of the 10th lowest percentile should be enough in theory.

For this analysis I have used `gasPrice` $median$ value.

I have used it because it is more practical, data for this are readily available and it leaves a room for error as this number will be always strictly higher than 10th lowest percentile since this is in effect 50th percentile value.
Also I have not sampled all 7 day averages within the time series but used predefined periods and calculated medians. This number maybe a little lower than if maximal median of any 7 day period were taken, but since this is already a much weaker assumption than we need I believe this simplification makes sense.

#### Max value

I have used value $147$.
The rational behind this is that it is the highest value for the past three years and it seemed to be the ceiling that was reached repeatedly.

I have discounted the the overall max value that is 210 reach in 2020 defi summer.
The reasoning behind this decision is that the gas environment has changed both qualitatively and quantitatively since then. EIP1559 was introduced which has an effect of smoothing out gas price removing extremes and ETH is couple orders of magnitudes more expensive which creates a large pressure against rising gas price.
Also unlike in 2020 there are various scalability solutions already live ranging from other L1s to rollups which alleviate the pressure on gas price on mainnet to large extent.

I think it is also reasonable to expect to gas price not overcome prior maxima due to EIP4844, further scalibity of ethereum.

For more charts and exploration see [this sheet](https://docs.google.com/spreadsheets/d/1Qy_BWbPtTjvFGcYANCW0Tvue6-7JR8cuklZqrADijaY/edit#gid=1283833458)

#### Data source

`ETHEREUM_MEDIAN_GASPRICE`: glassnode, calculated by tradingview

https://www.tradingview.com/chart/?symbol=GLASSNODE%3AETH_MEDIANTXGASPRICE

### SSVprice

Since Liquidation Collateral - $LC$ s in SSV token and tx fees are paid in ETH we must account for possible price drops of SSV relative to ETH.

The question is:
What is the minimal SSV/ETH price in relative terms that we can expect?

To define it mathematically, by how many % can SSV/ETH drop in any given time period?
If the maximal drop were to be 60% the $maxSsvPriceDrop$ variable which I will be using would be equal to $0.4$.

The max one week price drop since late 2021 was no more than 20% as explored in [this table](https://docs.google.com/spreadsheets/d/1Qy_BWbPtTjvFGcYANCW0Tvue6-7JR8cuklZqrADijaY/edit#gid=337951645).
However, it is reasonable to expect much larger drops, as we have seen other small tokens drop dramatically in time of stress.

It is reasonable to expect the possibility of larger SSV price movements in the future once network goes live.
The largest one week price movement was 73% in late November 2021.

Thus I have used 80% possible price drop for calculations and set the $maxSsvPriceDrop$ value to $0.2$

It is important to be ultra conservative when setting this variable as this has the most pronounced effect on overall required $LC$ and runway settings.

Also it can be expected that all stakers and staking apps will adjust to these parameters. Thus even though updating these parameters by the DAO within 7 days is reasonable to expect, it may not be reasonable to expect all stakers to adjust to them in time and avoid large scale liquidations, SSV price and network instability.

### Calculation

There are in effect two variables which DAO sets based on which $LC$ is calculated.
`minimumLiquidationCollateral` - a static absolute amount of SSV below which any account can be liquidated
`liquidationThreshold` - an operational runway or a time period, for which a cluster needs to have funds, defined as:

uint64 liquidationThreshold = minimumBlocksBeforeLiquidation * (burnRate + networkFee) * cluster.validatorCount;

All calculation can be checked in the[ main sheet here](https://docs.google.com/spreadsheets/d/1Qy_BWbPtTjvFGcYANCW0Tvue6-7JR8cuklZqrADijaY/edit#gid=0)

### Edgecases - Static Fees

I will use $burnRate$ instead of `liquidationThreshold`
in this section when necessary to make the reasoning less confusing as `minimumLiquidationCollateral` are `liquidationThreshold` are somewhat similar terms.

I will also use $LC$ and `minimumLiquidationCollateral` interchangeably.

The main assumption is that there are 3 well defined special cases for which we need to be prepared. All other cases fall within these categories and are solved for if all these special cases are.

1. Cluster burn rate is smaller than $LC$ and approaching zero. - $burnRate<minimumLiquidationCollateral$, $burnRate_{lim \to 0}$
2. Cluster burn rate is equal to minimum $LC$. - $burnRate=minimumLiquidationCollateral$
3. Cluster burn rate is larger than $LC$ and approaching infinity. - $burnRate>minimumLiquidationCollateral$, $burnRate_{lim \to 0}$ $burnRate_{lim \to \infty}$

Let's explore why this is true:

Liquidation can take place when either one or the other of these conditions are true.

1. Cluster burn rate is approaching zero. - $burnRate_{lim \to 0}$

In this case `liquidationThreshold` approaches zero, thus liquidation is always triggered by the `minimumLiquidationCollateral` value.

In this case we need to make sure that `minimumLiquidationCollateral` is sufficient to liquidate a cluster under any circumstances. The good thing in our design is that `gasAmount` for liquidating a cluster is always constant. Thus the problem is reduced to setting large enough `minimumLiquidationCollateral` to account for max $gasPrice$ and $maxSsvPriceDrop$ specified above.

2. Cluster burn rate is equal to minimum $LC$. - $burnRate=minimumLiquidationCollateral$

This can be though of as the worst-possible-case or situation with the highest possible $burnRate$ when liquidation is still triggered by $LC$ or converesly the lowest possible $burnRate$ to trigger it. If $burnRate$ were to be any higher it would start approaching scenario 3. Thus we can say this is the worst possible case for both $burnRate$ and `minimumLiquidationCollateral`. Thus if the cluster is profitable to liquidate under it, it will be profitable to liquidate under all other cases.

Also if the cluster is Liquidatable with triggering $burnRate$ condition and the $burnRate$ is set high enough to liquidate any cluster that triggers this condition it should hold true that all other cases are accounted for and fall under the scenario 3.

The worst possible scenario:
There is a sudden gas price increase and $maxSsvPriceDrop$ at the same time.
In this case a cluster would be right at the border of its $minimumLiquidationCollateral$ when there is suddenly large gas spike and SSV price drop. I use in the calculation 7 day median values, thus the edge case is that cluster can be unprofitable to liquidate for up to 7 days if my assumptions hold. Thus the $minimumLiquidationCollateral$ must be set to include additional 7 day $burnRate$.

From this then follows, that if there is a $minimumLiquidationCollateral$ which accounts for the $burnRate$ in this special case, thus for this additional 7 day period, it must account also for all other cases where $minimumLiquidationCollateral>burnRate$ since under all of these cases the $burnRate$ is strictly lower than in this edge case.

3. Cluster burn rate is larger than $LC$ and approaching infinity. - $burnRate>minimumLiquidationCollateral$, $burnRate_{lim \to \infty}$

In this case we disregard $minimumLiquidationCollateral$ as this is strictly lower than $burnRate$ in this case thus liquidations are always triggered by burn rate alone.
Thus the problem is reduced to setting large enough $burnRate$ to account for max $gasPrice$ increase and $maxSsvPriceDrop$ specified above.
If we divide 7day period needed for liquidations by SSV price drop we get 5 week runway. We need to add 1 week on top, to adjust for the possible max liquidation time of 7 days.

### Edgecases - Dynamic Fees

#### Time period
I am using 7 days time period for fee changes. The number is somewhat arbitrary, but there are few good reasons why I have chosen this as default:
- Possibly the shortest time period within which it can be reasonably expected DAO to update these parameters.
- 1 week period is the shortest time series with natural seasonality if we disregard 1 day. Seasonality is applicable for both gas and SSV price variables that we care about. Thus any sudden price drop is dampened by this seasonality.
- Natural time period for humans to reason about. This is useful for stakers when calculating / adjusting their SSV collateral.

**Assumption**
**Network fee**
Fees in ssv.network can be changed dynamically by operators or by DAO itself. The assumption here is that DAO would not increase its fees in times of high volatility or if there is a high volatility after network fee change, the DAO is ready to decrease the fee to the previous value.

To make the system predictable and be able to have clear guidelines to setting DAO controlled variables it makes sense for it to self-limit the increases of network fee.

Guideline for setting network fee:
For the purposes of these calculations I have assumed that network fee would change once **every 7 days** at most and every change would be **less/equal to 10%** of previous fee.

This can be changed of course but should be accounted for in the calculation as well.

**Operator fee**

I would suggest the parameters that control operator fee to be set accordingly:

uint64 updateOperatorFeeIncreaseLimit = 0.1 
uint64 updateDeclareOperatorFeePeriod = 7 days 

In human readable terms the fee change would take at least **7 days** to take effect and every change would be **less/equal to 10%** of previous fee.

This can be changed of course but should be accounted for in the calculation as well.

#### Fee change dynamics

Operators can change fees only up to a limit set in % by the DAO.

**The worst case**
The worst case with regards to liquidations is when both increased Network fee and new Operator fees become active exactly when there is sudden large gas spike and SSV price drop. I use in calculation 7 day median values, thus the edge case is that a cluster can be unprofitable to liquidate for up to 7 days if my assumptions hold. In this edge case dynamic fees make the burn rate higher by the max % rate they could have been raised by.

What this effectively means is that both `minimumLiquidationCollateral` and $burnRate$ must account for this worst case scenario.

For the purposes of these calculations I have assumed that both operator fee and network fee would change once every 7 days at most and every change would be less/equal to 10% of previous fee.

### Recommendations

#### Notifications
Work with teams building notification services, to notify stakers of the operator fee change and recalculate cluster operational runway right after the new fee was declared.
If notification services were to update the runaway only after the new fee takes effect clusters could be liquidated before stakers can replenish their collateral.

#### Network fee
For larger predictability and transparency I would suggest similar schema to changing network fee that is currently used for changing operator fee.
resons:
- removes some governance attacks - if an attacker took control of setting dao controlled parameters they could cause mass liquidations in the network.
- easier cluster balance maintenance - cluster account monitoring bots can adjust to this new burn rate before it takes place. Also the mechanism is the same as with operator fee change, thus there is no additional code or logic required.

If this cannot be implemented in the mainnet v1 version, DAO should have a clear protocol of communicating this fee change, so that stakers can adjust in time.
Ideally a new event `declareNetworkFeeChange` would be added to the ssv network contract, so that stakers' bots can automatically listen to fee change declaration.
Adding an event does neither change smart contract state or logic thus should be safe to implement even without additional audit.

--------------------------------