# Risk Assessment Framework for stVaults **URL:** \ **Category:** Lido V3\ **Created:** [April 28, 2025, 7:00am UTC](https://research.lido.fi/t/risk-assessment-framework-for-stvaults/9978 "2025-04-28T07:00:48Z")\ **Posts on this page:** 1\ **Showing post:** 1
**Author:** ![mikgur](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/mikgur/32/2488_2.png) [@mikgur](https://research.lido.fi/u/mikgur)\ **Post date:** [April 28, 2025, 7:00am UTC](https://research.lido.fi/t/risk-assessment-framework-for-stvaults/9978/1 "2025-04-28T07:00:48Z")
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_: 1. The user takes on all the risk exposure which he introduces to the system within defined risk scenarios. 2. **Rebalancing mechanism** is aligned with risk re-allocations within (5), therefore executing additional risk mitigation in case of risk events _For principle 3_: 1. 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_: 1. There is a tech managing **redemption liquidity** between Lido Core and stVaults 2. 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: 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): **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_ 2. Withdrawals participation, with some of the withdrawals facilitated by the Vaults # 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 --- _[View the full topic](https://research.lido.fi/t/risk-assessment-framework-for-stvaults/9978)._