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:
- 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)
- 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.