# Setting / Adjusting for DAO Controlled parameters

[TOC]

## public updateLiquidationThresholdPeriod (blocks)

Description: Sets the minimum period (in blocks) after which SSV accounts can be liquidated.

<table>
<tr>
<td><strong>Parameter</strong>
</td>
<td><strong>Type</strong>
</td>
<td><strong>Description</strong>
</td>
</tr>
<tr>
<td>blocks
</td>
<td>uint64
</td>
<td>Duration in blocks to have sufficient balance
</td>
</tr>
</table>

### High level problem statement

* To allign incentives it would be ideal to perform a check and allow operator to draw only up to the `balanceOf(account)` of particular account, ideally up to `(balance - networkFee)`. In current design this is not possible, as this would be very costly(in gas terms) to perform.
* Problem arises when it becomes economically unprofitable to trigger liquidations
* SSVDao can be the final guarantor of account solvency that would run `liquidate()` function even if it is unprofitable.

### Edge cases

#### Zero operator fees (or close to it)

- if `operatorFees` are set at very low levels or there are zero operator fees, the `blocks` parameter is not relevant for the liquidations. Thus there need to be a condition -> a minimal amount of SSV set in the absolute terms.

_liquidatable(account):
	if ballanceOf(account) <= minAmount:
		break
	...

**To get min amount:**

 $\lim_{burnRate \to 0} LiquidationThresholdPeriod = 0 + minEthProfit$

thus the `minAmount` can be calculated disregarding the burnRate.

**NOTE:**

If the equasions are roughly correct, $burnRate*numBlocks$ is insuficient for fee calculation.

### Framework for changing liquidation fee

$$
liquidationPrice = \frac{maxGasPrice*maxGas + minEthProfit}{minSsvPrice} + errorMargin
$$

$liquidationPrice >= LiquidationThresholdPeriod * burnRate$

$LiquidationThresholdPeriod <= \frac{liquidationPrice}{burnRate}$

$minEthProfit = minSsvPrice*ssvMinProfit$

$\frac{minEthProfit}{minSsvPrice} = ssvMinProfit$

Questions to guide this parameter change

**Variables**
h
* $LiquidationThresholdPeriod ~= 7days$
For this variable 7 days or 30 may be a good default. There is a natural seasonality to gas cost time series. 1 day, one week, one month etc...
One day seems like too short of a time, we have experienced sustained spikes in gas costs taking this long. There is a negative corrolation between $LiquidationThresholdPeriod$ and $maxGasPrice$ the larger the former, the smaller the latter and vice versa. To be more precise in setting this, we can explore $\delta$ (rate of change) of $maxGasPrice$ variable.

* $maxGasPrice$
What is the minimum fee in a high fee environment that a liquidator can expect to pay to comfortably liquidate the account?
or
What is the max fee in the cheapest 10% of the block in a given period?
thus
* what is the $maxBlockfeeInLowest10thPercentile(timePeriod)$ that we can expect in $LiquidationThresholdPeriod$?
* We can sample last 6 months of blocks to get a reasonable value
* It is important find out the highest rate of change per month(if we want to change monthly) of this variable as well, this informs us how often + aggressively should this parameter be adjusted

* $maxGas$
What is the max gas amount of account liquidation?
This should be quite straightforward to find out.

- $minSsvPrice$
What is the minimal SSV/ETH price in relative terms that we can expect?
- Calculate price in ETH makes more sense, since gas price is paid in ETH as well
- Are there any future token unlocks that can dump the price?
- How to
- rule of thumb -> 50% of last ATL = rock_bottom
- $0.001645 ETH -> 0.00329*.5$
- $0.146875 -> 0.001645/0.0112$ -> It will not fall to more than 14% of current price
- more sofisticated -> calculate rate of change
- calculate fastest rate of change for prefered time period 7 / 30 days, for the past $n$ days and add some margin to it (~20%)

- $errorMargin$
An absolute value in ETH may be better than percentage, in case we have missed some variable in the calculation or something truly unexpected happens.

- $minEthProfit$
What min profit can we reasonably expect liquidators to be comfortable with? In what it should be denominated? Should it be relative to the amount liquidated? -> probably not, since if tx submitted via flashbots is successful, it should succeed since it will have satisfied race conditions.
- It seems most reasonable to use absolute amount in eth, avoids complexity and seems not much worse than USD. thus lets say:
- $0.1ETH$ ?
- $ssvMinProfit = 0.1/0.147 = 0.68 ETH$
- if we relax the requirement and assume that SSV will not fall under this summer's ATL quicker than we can adjust it then:
- $ssvMinProfit = 0.1/0.147*2 = 0.34 ETH$

## public updateNetworkFee (networkFee)

Description: Updates network fee.

<table>
<tr>
<td><strong>Parameter</strong>
</td>
<td><strong>Type</strong>
</td>
<td><strong>Description</strong>
</td>
</tr>
<tr>
<td>networkFee
</td>
<td>uint256 (casted to uint64)
</td>
<td>The fee charged by the network per validator (denominated as $SSV tokens per block).
</td>
</tr>
</table>

### High level

- Not curcial variable for system stability
- Would set it at some minimal rate (not zero)
- Rationale
- The main reasons not to set it to zero is for users and services get used to paying the network fee. Set expectations, make sure systems built on top can handle fee payments under private operator setting. (~0.1% of deposit)
- Keep the system highly competitive with other staking solutions

## public withdrawNetworkEarnings (amount)

Description: Withdraws accumulated network fees in SSV token.

<table>
<tr>
<td><strong>Parameter</strong>
</td>
<td><strong>Type</strong>
</td>
<td><strong>Description</strong>
</td>
</tr>
<tr>
<td>amount
</td>
<td>uint256 (casted to uint64)
</td>
<td>Amount to be withdrawn
</td>
</tr>
</table>

### High level

- Nothing to set
- DAO can withdraw fees every month or on other periodic basis

## public updateOperatorFeeIncreaseLimit (percentage)

Description: Sets the max amount by which operators can increase fees in each fee update cycle. This does not limit max operator fee, only the rate (%) by which it can be increased within each fee update cycle.

<table>
<tr>
<td><strong>Parameter</strong>
</td>
<td><strong>Type</strong>
</td>
<td><strong>Description</strong>
</td>
</tr>
<tr>
<td>percentage
</td>
<td>uint64
</td>
<td>Maximum increase percentage
</td>
</tr>
</table>

### High level

- Important variable for system stability
- If Operator payments **are adjusted** based on SSV token price
- What external events can influence operators profit margin?
- Probably only external costs, such as datacenters, electricty etc. or change in market dynamics
- If correct, can be set to relatively low number, e.g.(20%)
- If Operator payments are **NOT adjusted** based on SSV token price

## public updateDeclareOperatorFeePeriod (seconds)

Description: Sets the time window (in second) between the declaration and activation of a new operator fee.

<table>
<tr>
<td><strong>Parameter</strong>
</td>
<td><strong>Type</strong>
</td>
<td><strong>Description</strong>
</td>
</tr>
<tr>
<td>seconds
</td>
<td>uint64
</td>
<td>Period in seconds until you can execute fee after setting it
</td>
</tr>
</table>

### High level

- Give enough time for stakers to change operators
- Probably not necessary to have human actionable time window as there is not much cost even if they are days late, since there is limit to the increase
- A week, 7 days sounds reasonable default, no strong reasons
- It is expected that there will be bots monitoring this, so even 1 hour or 1 day could be sufficient

## public updateExecuteOperatorFeePeriod (seconds)

Description: Sets the time window (in second) in which an operator can activate a new fee. It starts after the fee declaration window ends.

<table>
<tr>
<td><strong>Parameter</strong>
</td>
<td><strong>Type</strong>
</td>
<td><strong>Description</strong>
</td>
</tr>
<tr>
<td>seconds
</td>
<td>uint64
</td>
<td>Period in seconds that you can execute a execute fee until it expires
</td>
</tr>
</table>

### High level

- Give enough time for operators to execute fee change
- One day sounds like a reasonable default, no strong reasons
- It is expected that there will be bots monitoring this, so even 1 hour could be sufficient