## Scope
This document is supplement, focusing on suggesting principles on defining `priorityExitShareThreshold` described in [VEBO Improvements](https://hackmd.io/oTg7wl7rRFyiUKfMPjj3xw?view) document as a solution *smoothing* the protocol possible volatility and solving:

> ... a problem – the protocol's TVL has some volatility, and operators in different modules have varying costs for rejoining validators. These differences can be expressed in the node operator itself (solo staker or large company), in the automation of processes, technology features (vanilla validator or DVT), etc. TVL volatility, combined with varying rejoining costs, leads to the problem that the protocol may periodically rotate validators in modules with high rejoining costs – requesting exits and then making deposits after some time.

From the problem description this document is structured around suggesting possible reasoning and numbers for **CSM**, **SDVT** and **Curated** modules, based on:
* Protocol **Volatility** (specifically ETH volatility) - as a **source** of risk of unnecessary rebalancing
* Modules **costs of rejoining** - as a cost-of-risk in case the event happens
* Modules **risk exposure** sensitivity - as an additional risk of maintaining higher module share that is defined by `stakeShareLimit`

💡Note on **Curated** module
As Module **costs of rejoining** is a subjective value compared with *other* modules cost, **Curated** module is considered a baseline with minimal cost, therefore for this module `priorityExitShareThreshold` is suggested to be set **equeal** to `stakeShareLimit`

## Suggested approach application
### Protocol **Volatility**
The *unnecessary* rotation of Validators is considered as event that is caused by simultaneously:
* Module *A* being at cap (*or near the cap*) of it's `stakeShareLimit`
* protocol TVL in ETH decrease over time, leading to validator exits from Module *A* and re-entering when protocol would grow back, leading to **cost-of-risk** realization

Within `priorityExitShareThreshold` functioning as a buffer to prevent such risk realization it's suggested to formalize risk scenarios in terms of possible level of protocol TVL decrease, based on [observed history](https://dune.com/queries/2859190/4782072).

***Observations:***
1. Maximum observed ETH TVL decrease is **-6.48%**, observed from 2024-03-10 to 2024-05-05 (through 71 days)
2. Maximum observed ETH TVL decrease within 30 days is **-4.83%**, observed on 2024-04-19

***Risk scenarios:***
1. **Moderate:** **5% drop**. Representing **very rare**, but observed case within reasonable timeframe for reaction (one month)
2. **Extreme:** **10% drop**. Representing case never observed in history, but possible under severe conditions
3. **Apocalyptical: 20% drop**. representing outstanding shrink in protocol - more than two times greater than was ever observed

The proposed risk scenarios are suggested to determine corresponding difference between `stakeShareLimit` and `priorityExitShareThreshold`.

Within the interpretation of *choosing multiplier for risk scenario corresponding to **X%** drop, would prevent module from withdrawing in cases of protocol TVL decrease up to **X%***

### Modules **costs of rejoining**
Within current approach **costs of rejoining** valuation is opinionated and is open to additional arguments on more precise evaluation.
1. For *CSM* module the cost of rejoining is estimated to be <span style="color:red">**high**</span> as it is impacting also the efficiency of capital provided by to Node Operator in form of bond, and also could lead to significant reputation risks for the protocol
2. For **SDVT** module the costs of rejoining is estimated to be <span style="color:green">**low**</span> to <span style="color:orange">**medium**</span>, as it's definitely exist (in terms of comparison to *Curated* module) but lower than *CSM* module. The low to medium difference, subjectively, could be estimated by operational efficiency of [Super Clusters](https://x.com/LidoFinance/status/1815377016897597687) (supporting up to 500 validators each) as a *buffer* for the SDVT module in terms of lowering rejoining costs.

### Modules **risk exposure** sensitivity
Within module risk exposure valuation it's suggested to evaluate the factor focusing on **scalability** of module, as associated risk is already used to define module(s) `stakeShareLimit`.
1. For *CSM* module the **risk exposure** is estimated to be <span style="color:green">**low**</span> as increasing module share over set `stakeShareLimit` leads to increased risk mitigation available in terms of bonds capital provided, therefore it's more acceptable to set `priorityExitShareThreshold` higher (relatively to corresponding module share)

2. For *SDVT* module the **risk exposure** is estimated to be <span style="color:red">**high**</span> as increasing module share over set `stakeShareLimit` does not lead to increased risk mitigation tech ([cover fund](https://research.lido.fi/t/proposal-expanding-the-simple-dvt-module/7549#risk-factors-6)) and impact DAO inflow sustainability with higher NO fee

## Resulting suggestion:

Within reasoning above:
1. For *CSM* module with cost of rejoining being <span style="color:red">**high**</span> and <span style="color:green">**low**</span> module risk exposure sensitivity it's suggested to provide `stakeShareLimit` increase sufficient for even **Apocalyptical** (*20% drop*) scenario.
2. For *SDVT* module with cost of rejoining being <span style="color:green">**low**</span> to <span style="color:orange">**medium**</span> and <span style="color:red">**high**</span> module risk exposure it's suggested to provide `stakeShareLimit` increase sufficient for scenario based on cost of rejoining:
* **Moderate** (*5% drop*) for low cost of rejoining
* **Extreme** (*10% drop*) for medium cost of rejoining.