Risk Assessment Framework for stVaults

[mikgur]

Lido contributors are excited to present the Risk Assessment Framework for stVaults in Lido V3: Ethereum Staking Infrastructure. This framework introduces stVaults as a modular solution for Ethereum staking, providing users with more flexible and customizable staking options while maintaining the core principles of decentralization and openness.

The stVaults aims to allow stakers, Node Operators, Asset Managers, and other participants to interact with stETH liquidity in new ways, addressing the diverse needs of the Ethereum ecosystem. This post outlines the foundational principles and risk management framework to ensure the stability and solvency of stVaults.

As this is a work-in-progress, we are sharing it with the community for feedback and input before the release.

stVaults underlying principles

Goal:

Possibility to utilise stETH liquidity with customizable staking position.

Principles:

1. Vault users don’t negatively affect stETH users:
   a. Vaults don’t negatively affect stETH users APR
   b. Slashing risk consequences are contained within vaults up to the level agreed by the DAO

2. stVaults have a set reserve ratio which determines the quantity of stETH that can be minted based on ETH provided, and that can only be changed by the DAO

3. The impact of possible reallocation of stake between Lido Core and stVaults is contained and manageable
   a. Keep incentivizing Ethereum decentralization
   i. stVaults are no more than a set share of of Lido Core

4. stETH solvency - all stETH existing could be converted into ETH at 1:1 ratio

Invariants:

For principle 1:

1. Minted stETH is backed up by collateral: ETH, which might be staked and securely redeemed if needed on Validators
2. A sufficient amount of collateral is defined based on risk scenarios for validators balance changes. As it is relative to minted (mintable) stETH it is defined by Reserve Ratio (RR)
3. There is a tech, ensuring collateral / minted stETH balance for defined risk scenarios - rebalancing mechanism
4. A rate on vault-minted stETH is greater or equal to stETH APR (90% of gross Lido Core APR)

For principle 2:

5. The user takes on all the risk exposure which he introduces to the system within defined risk scenarios.
6. Rebalancing mechanism is aligned with risk re-allocations within (5), therefore executing additional risk mitigation in case of risk events

For principle 3:

7. Lido core providing redemption liquidity is good for Vault users. Thus Lido Core is incentivized in case stVaults more than a set share of % of Lido Core

For principle 4:

8. There is a tech managing redemption liquidity between Lido Core and stVaults
9. There is a tech facilitating extreme cases for stVaults out of defined risk scenarios determining Reserve Ratio to maintain stETH solvency
   a. Cover fund
   b. Rebase decrease

Risk framework

Global limit

Global limit is derived from 3rd principle: The impact of possible reallocation of stake between Lido Core and stVaults is contained and manageable

Vault Global limit is designed with an assumption that Lido Core being the only provider of redemption liquidity on the initial stage

Based on possible maximum withdrawal pressure from stETH minted through vaults, ensures that after withdrawals are processed

• The remaining ETH in core protocol is greater than doubled total ETH in vaults
• The volatility in stETH APR is still extremely low (less than 5%)

Lido V2 currently holds ~9.2M ETH in TVL. To preserve protocol resilience, we aim to ensure that even if all ETH entering stVaults comes from Lido Core withdrawals, the remaining ETH in Lido Core stays at least 2x larger than the total ETH in stVaults. This implies that the global stVault cap should not exceed 33% of Lido Core’s TVL.

We propose setting the global limit at 32%, or 3,000,000 ETH.

NO limit and risk exposure

Particular limits are derived from 1st principle: Vault users don’t negatively affect stETH users

• Vault limits & reserve ratio designed to be sufficient to cover the risk scenario of 100% of validators (both within Lido staking module and all vaults) slashed for one identified Node Operator from Curated module.

We use following logic to calculate slashing penalties in our scenarios:
- Identified NO limit within Vaults is considered up to 1M ETH
- Add 1% of the network on top of that to cover a possible slashing of the same NO in the Curated Module
- Slashing penalties are calculated based on the catastrophic scenario of slashing 100% of NO’s validators within protocol (both in Lido Core and in Vaults).

What is not covered by our risk scenarios:
- Possibility that identified NO has more than 1% of network within Curated module, Vaults with non-identified NO and Other protocols
- Possibility that more than 1 NO are slashed simultaneously.

• For Vaults with non-identified Node Operator the limit & reserve ratio is set across all vaults and designed to mitigate risk scenario of 100% of validators within this vault group being slashed simultaneously with 1% of the network being slashed on top

• Utilizing DVT technology within Vaults is also considered with identified Node Operators as participants. With alignment on risk scenarios of only one Node operator subject to slashing that could lead to lower levels of Reserve Ratio, but also introduces requirements for management of corresponding DVT technology risk: with limits considered at up to 1M ETH for each particular technology.

Vault groups and risk coverage

Based on 2nd principle: stVaults have a set reserve ratio which determines the quantity of stETH that can be minted based on ETH provided, and that can only be changed by the DAO, the risk re-allocation are designed within 5th and 6th invariants:

• The user takes on all the risk exposure which he introduces to the system within defined risk scenarios.
• Rebalancing mechanism is aligned with risk re-allocations within (5), therefore executing additional risk mitigation in case of risk events

As a result of the non-linear scale of correlation penalty (and, to lesser extent, exit queue) risk exposure grows with concentration of stake on particular Node Operator. Therefore the concept of vault groups is introduced - limited by mintable stETH amount so risk exposure is also limited, and could be reallocated to the users introducing it (via growing Node Operator share in total staked ether, for example)

Node operators, Tiers and Vaults

Each Node Operator is assigned a set of Vault Tiers (an example of a vault group). A Tier defines two things: the Reserve Ratio (RR) and the total stETH minting cap.

For example:

• Tier 1 — 5% RR, 47,500 stETH cap;
• Tier 2 — 6% RR, 47,000 cap (94% of 50,000);
• Tier 3 — 9% RR, 182,000 cap (91% of 200,000).

A Tier’s minting cap limits how much stETH can be minted, not how much ETH can be deposited. For example, in a Tier 1 with 5% RR and a 47,500 stETH cap, users can deposit any amount of ETH into the Vaults under this Tier. However, stETH can only be minted up to the 47,500 limit. Once the cap is reached, additional ETH deposits are still allowed, but no new stETH can be minted until stETH is burned within the Vaults in this Tier.

Tiers are scoped per Node Operator. This means two Operators will each have a Tier 1 with identical parameters — say, 5% RR and a 47,500 stETH cap—but these Tiers are entirely separate.

Rebalancing mechanism

1. LTV (Liquidity-to-Value, which is equals to 1 - Reserve Ratio), for each next Tier is set lower than it should be, taking into account additional slashing risk it brings to the system:
   

   
   
   The illustration shows the difference between the theoretical LTV and the LTV generated by our Risk Framework. The Risk Framework accounts for the increased slashing risks for previous vaults, which is not considered in the theoretical LTV.

2. In the event of a considered scenario (100% of validators within this vault group being slashed simultaneously with 1% of the network being slashed on top):

   • Vaults in the highest LTV tiers may not possess sufficient ETH to cover the minted stETH after the slashing event. In this situation, the resulting difference would be covered by utilizing the ETH held in the reserve part of the Vaults of the next tier.
     The concept is that when a Vault is created with an X% Risk Ratio (RR), it means that in the event of slashing, up to X% of the Vault’s ETH valuation could be used to cover NO’s slashing penalties. This is not limited by the actual penalties attributable to validators of the specific Vault.
   • ETH held in non-slashed Vaults is not used for covering any of the consequences (more on this in Appendix A)

The Vault Owner must acknowledge that they risk losing up to RR% of ETH deposited into the Vault in case of slashing. The RR% is predetermined and based on our Risk Framework.

DAO risks

Risk parametrization targets confinement of risk in previously defined catastrophic scenarios to the overall set of vaults (some collateral transfer between vaults belonging to a single NO may be required); there should be no shortfall / deficit under any of the scenarios that either the stETH holders (through reduction of stETH rebasing rate) or Lido DAO (through depletion of recovery fund and/or Lido DAO Treasury have to cover. In case of scenarios surpassing catastrophic (e.g. multiple NO slashing simultaneously / Holesky on mainnet) risk management is yet to be defined, with possible options:

• Utilizing cover fund
• Reduction in stETH rebase with possibility to going negative

ETH movement from Lido V2 to stVaults

Addressing Principle 3:The impact of possible reallocation of stake between Lido Core and stVaults is contained and manageable

The current approach suggests containment for the impact through Global limit, ensuring:

1. Sufficient withdrawal liquidity
2. Low effect on stETH APR volatility

In case of continuous withdrawal pressure on Lido Core within the scenario of Vaults > 35% of Lido Core until automatic solution is implemented there is a manual tech for utilizing stVaults for redemption liquidity

Next steps:

As Lido core providing low volatile APR and redemption liquidity and thus may be incentivized, the options considered:

1. Fee curve providing fiscal incentive to support Lido Core: the more minted_in_vaults_stETH / Core ratio the more is the fee which is transferred to Lido Core rewards

   • Increasing Lido Core market position to attract stake
   • Increasing Liquidity_fee_percentage to disincentivize minted volume

2. Withdrawals participation, with some of the withdrawals facilitated by the Vaults

   • With soft liquidation mechanism
   • Within variable LTV, enabling the regular liquidation as threshold on LTV lowers with a decrease in Lido Core volume

Appendix A: Risk transfer within vault groups

This part is elaborating on the tech, ensuring that any combination of slashing within one Node Operator suggested Reserve Ratio structure is sufficient to cover the consequences, limited to affecting only stVaults with slashed validators.

Assumptions:

1. X ETH is slashed simultaneously on validators within the stVaults on one Node Operator
2. Z ETH is slashed within the same time out of this particular Vaults

Goal:

If Z is less than 1% of total Network, collateral in slashed vaults should be enough to cover that after penalties all minted stETH debt could be covered

Assume X ETH is Staked within vaults 1,2…..N with different reserve ratio (RR) with average RR stated as avg_rr(X)

1. Volume in each particular vault is Yi, where X = sum(Yi)
2. Maximum minted stETH is X*(1-avg_RR(X))
3. avg_RR(X) = sumYi * RRi) / X
4. Total penalties on the vaults are a function f(X+Z) that is not sensitive to particular (Yi) vaults

The worst scenario in this case is when

• Minted stETH → max
• Hence avg_RR(X) → min

But, as vault tiers are designed with increasing RR, the solution for minimizing RR is filling up the tiers with lowest possible RR

And RR & Tiers are designed that in this case, the capital is still enough to cover borrowed stETH, within assumptions above