Scope

This document is supplement, focusing on suggesting principles on defining priorityExitShareThreshold described in VEBO Improvements 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.

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 high 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 low to medium, 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 (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 low 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 high as increasing module share over set stakeShareLimit does not lead to increased risk mitigation tech (cover fund) and impact DAO inflow sustainability with higher NO fee

Resulting suggestion:

Within reasoning above:

1. For CSM module with cost of rejoining being high and low 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 low to medium and high 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.