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

[Gauntlet]

Thanks @mikgur and the Lido Analytics Workstream for sharing the detailed risk assessment framework! We’ve reviewed the framework and would like to share a couple of observations and recommendations:

1. Vault Global Limit: Recommend Reducing to 25%

The framework sets a 32% cap on stVaults, but this does not satisfy the stated goal of ensuring that, after maximum vault withdrawals, the ETH remaining in Lido Core is more than double the ETH in vaults.

• With a 25% global limit:
  • Before withdrawal: Vaults = 25%, Core = 75%
  • After withdrawal: Vaults = 33%, Core = 67%
    • This satisfies the “2x” solvency condition

	Before withdrawal	After withdrawal
Vaults	2.25m (25%)	2.25m (33%)
Core	6.75m (75%)	4.5m (67%) - double the total ETH in vaults

At 32%, this solvency threshold is no longer met post-withdrawal.

Recommendation:

Set a 25% vault global limit on stVaults.

2. Reserve Ratio (RR): Static Ratio Insufficient for Large NOs

We modeled a worst-case scenario where a large Node Operator (NO) holding ~4% of the network stake is fully slashed post-Pectra. Our results showed a max loss of 15.8% of vault collateral for a large NO with 1m ETH delegated, which means a 5% reserve is not enough for the vault to remain solvent.

Solvency Risk from Full Slashing of a Large Node Operator

To further evaluate the worst-case slashing risk referenced in the Risk Assessment, we modeled the full slashing of a large Node Operator (NO) holding:

• 1M ETH in a single stVault
• 340K ETH in the curated module (~4% of total network stake)

Assumptions:

• Post-Pectra slashing rules are applied (EIP-7251: lower base penalty, higher EB).
• Only this single NO is slashed.
• All stVault ETH is held in one vault.

Outcome:

• Initial slashing penalty: After Pectra Upgrade, the initial slashing penalty is decreased to 0.5 ETH per validator. With each validator’s MAX_EB increased to 2048, this is a much smaller slashing ratio (1/4096 instead of 1/32).

  • Total initial penalty (curated module + vault) = 0.5 / 2048 * (1,000,000 + 340,000) = 327 ETH

• Correlated slashing penalty: Since this NO represents 4% of the network’s total stake*, the correlation penalty is significant. The correlated penalty scaled linearly with the total slashable balance (in this case the full NO balance).

  • Total correlation slashing penalty = EB * min{3* SB / TB, 1} = (1,000,000 + 340,000) * 3 * (1,000,000 + 340,000) / 34,000,000 = 158435 ETH

  *Note that 4% share of the network is very high. currently Kiln is the only NO that has 4% share.

Source: Kiln - Modelling correlated slashing risks on Ethereum

Source: Mike Neuder / ethresear.ch Slashing penalty analysis; EIP-7251

• Inactivity leak penalty: No inactivity leak given the assumption only this single NO is slashed.
• Missed attestation rewards: The slashed validators miss attestations for the entire 8192 epoches until they can withdraw. This penalty per epoch (in GWEI) is calculated as base reward * (14+26) * EB / 64.

Loss Breakdown:

Penalty Type	Calculation	NO Loss
Initial slashing	0.5 / 2048 * (1,000,000 + 340,000)	327 ETH
Correlated slashing	(1,000,000 + 340,000) * 3 * (1,000,000 + 340,000) / 34,000,000	158,435 ETH
Missed rewards	sqrt(34,000,000) * (14+26) * (1,000,000 + 340,000) / 64	4.88 ETH
Total Loss	327 + 158,435 + 4.88	158,767.88 ETH
Total Percentage Loss	(4.88+327+158435)/1000000	15.8%

Our findings suggest that a vault with 1M ETH delegated to this NO would suffer a 15.8% total loss, exceeding the default 5% reserve ratio — rendering the vault insolvent in this plausible yet extreme case. This analysis highlights that slashing risk is non-linear and highly dependent on operator size.

Recommendation:

We suggest adjusting the RR (hence LTV) tier dynamically based on the NO’s total balance (or vault balance) to reflect the variation in slashing penalty. This better aligns capital efficiency with actual tail risk, especially in a future with wider NO diversity and reduced slashing penalties for smaller operators.

3. Risk Transfer Between Vaults Is Problematic

We caution against allowing one vault’s collateral to absorb losses from another — even if both are operated by the same NO.

• In a multi-curator environment (e.g., Symbiotic), this creates incentive misalignment:
  • Low-RR vaults could externalize risk to high-RR vaults.
  • This erodes solvency and creates a “race to the bottom” on reserve ratios.

Recommendation:
Preserve vault-level isolation of slashing risk unless curators and users explicitly consent to pooled risk.

Outstanding Questions

• Will stVault curators hold the withdrawal key to the validator and be able to initiate EIP-7002 style EL triggered withdrawals?
• Is validator effective balance customizable per curator/NO, or fixed at 32/2048?

[Nansen]

We view this framework as a vital foundation for enabling vault-based staking models without compromising the security, solvency, or credibility of the Lido protocol. It is encouraging to see structured controls like Reserve Ratios (RR), vault-specific caps, and a proposed global stVault TVL limit. In conclusion, we support the direction of this proposal but see room for iterating on the parameters.

As Gauntlet’s contribution highlights, the current framework could benefit from stronger alignment with tail-risk realities and operator concentration risks. Their modeling presents sound arguments for adjusting several parameters. We are aligned with Gauntlet’s recommendations and would support a revised version of this framework that incorporates these changes.

In any case, we are also looking forward to the Lido Analytics team’s formal response to these proposals. Specifically, it would be valuable to see:

• Additional scenario modeling or historical simulations of NO slashing events mapped against this proposed RR structure
• Clarification on how the global cap would be enforced dynamically, especially under volatile market or network participation conditions.
• A framework for RR or cap adjustment governance—will these be parameterized and DAO-controlled, or require new proposals each time?

Additionally, some potential further enhancements as this gets into production:

• Transparency Dashboard: A live dashboard showing RR usage, vault TVLs, and risk classifications would provide comfort and visibility for stakers and delegates.
• Slashing Insurance Disclosure: If any vault or the DAO itself intends to use slashing insurance or backstops, that mechanism should be made explicit and quantifiable.

[Mol_Eliza]

Hi there!
Firstly, really appretiate @Gauntlet and @Nansen feedback on suggested risk framework.
I’m really glad to have a discussion on this milestone, as i see it as a crucial tool for ensuring transparency and supporting any decisions made by Lido DAO.

As a contributor to Analytical Workstream i want to provide my vision and clarification on suggested approach, structured by sections in question:

Vault Global Limit

The purpose on global limit on initial stages is to manage possible reallocation of stake between Lido Core and stVaults, ensuring that even in edge case of stVaults stake would be fully filled with ETH withdrawn from Lido Core, the Core remains at least 2x larger than the total ETH in stVaults (therefore even after that if maximum possible stETH would be minted in stVaults and utilized to further withdraw from Lido Core, stVaults are still less than Lido Core).
Therefore the starting point considered is initial stVaults launch, when the share would be 0%:

Before withdrawal	After withdrawal
Vaults	0 (0%)	3m (32.6%)
Core	9.2m (75%)	6.2m (67.4%)

Definitely the protocol operates in an open market conditions, so there could be a case, when, with further withdrawal pressure, Lido Core share could go even lower, raising a very valid question:

Clarification on how the global cap would be enforced dynamically, especially under volatile market or network participation conditions.

The options considered in the long term are: fee curve providing fiscal incentive to support Lido Core and withdrawals participation, with some of the withdrawals facilitated by the Vaults, outlined in ETH movement from Lido V2 to stVaults section.

While in the short term within the scenario of stVaults > 35% of Lido Core until automatic solution is implemented there is a manual tech for utilizing stVaults for redemption liquidity

Reserve Ratio (RR): Dynamic to Static ratio

As correctly observed, static reserve ratio could not represent the non-linear effect of correlation penalty, the system design should correctly facilitate increase in risk with greater stake concentration.
There is an option for dynamic design, however, attributing the externality of stake concentration and, hence, risk increase for all users affected, would lead to requirement for users to actively manage their collateral position based on external actors actions which seems not feasible in case of collateral in form of ETH staked on validators.
Therefore Vault Groups in general or Tiers for Node Operator specifically are introduced, bringing discretization for a continuous effect:

Liquid Part here is 1-Reserve Ratio, representing share of maximum mintable stETH

The red line (Liquid Part) here represents the continuous nature of increase in risk with greater stake concentration.
The Blue line (Modyfied Liquid Part) - is one of the suggested Tiers structure, ensuring that at any value of ETH staked across all Node Operator vaults, the total collateral share across all tiers is greater than required share to ensure Vault users don’t negatively affect stETH users (in case of chosen risk scenario)

In particular, if 1M total staked on stVaults on one Node operator, only 50k ETH could utilize the first tier of 5% Reserve Ratio, as then the cap on mintable stETH (47,500) would be reached. The whole amount of 1M can only be staked across all tiers with increasing Reserve Ratio leading to total weighted average reserve ratio sufficient to cover risk scenario (14.55% for the case on the suggested numbers)

It’s also worth mentioning that Reserve Ratio is designed based on risk mitigation for the scenarios within stVaults, as there is no intention for risk transferring between stVaults and Lido Core.

The particular risk scenario suggested (100% of stake slashed in the vaults on one Node Operator and 1% in the Lido Core) is based on dramatically risk averse assumption, as overall historical number of slashed validators is less than 500 (<0.05% of network) with a most impactful slashing being at 108 validators. The purpose of this is to ensure sufficient mitigation even in apocalyptical scenarios.

Risk Transfer Between Vaults

As in the previous section, due to dynamic risk structure there is an externally in system with more stake accumulated with chosen risk scenarios (e.g. one Node Operator slashed).

The proposed way is to attribute this effect to actors controlling the source of externally. The intention here is if users bring more stake on a relatively big Node Operator, further concentrating and increasing systematic risk - the increase is attributed to the user, providing a fair decision space, correctly reflecting the effect of possible (again drastic) risk scenarios.

This approach:

1. Incentivize decentralization by design, as, for example:
   1.1 Node Operator A can have 5% and 6% Reserve Ratio Tiers filled, with the option for user to stake and mint only in 9% Reserve Ratio Vaults
   1.2. Node Operator B having capacity at 5% Reserve Ratio Tier

The users aiming for lower Reserve Ratio is incentivized to utilise stVaults of Node Operator B which have less stake in stVaults compared to Node Operator A (hence, capacity in lower-RR Tiers)

2. The competition for low Reserve Ratio Tiers is open and fair to everyone, giving advantage to early adopters of the technology (naturally, due to lower existing risk)

The suggested approach is designed with intention on transparency and simplicity, given it still need to cover two major questions:

• How increase in risk due to concentration should be attributed
• How static parameters on reserve ratio could be achieved to ensure stability for users

But I am open to possible further development here, as both risk transfer could be abstracted (e.g. Node operators or vault curators providing capital for the increase in risk with more stake concentration) and market on tiers could be created.

Reserve Ratio governance

I see framework as a way to transparently discuss and evaluate the possible parameters on vaults on DAO level.
On the operational side it could be managed by separate committee(s), utilising the framework, with clear limits and boundaries on the parameters, transparently functioning on methodology approved by DAO.

Outstanding Questions

Will stVault curators hold the withdrawal key to the validator and be able to initiate EIP-7002 style EL triggered withdrawals?

There would be an option to assign a role for stVault curators to trigger EIP-7002 withdrawals, but the protocol remains control on all stVaults with an option to mint stETH

Is validator effective balance customizable per curator/NO, or fixed at 32/2048?

stVaults are expected to be utilizing 0x02 (EIP-7251) credentials, therefore it’s up to stVaults users to control validators configuration including validators max and effective balances or possible partial withdrawals, providing the tools to build customizable staking solutions.