Lido "Bring Your Own Validator" Alternative Design

Lido is a Liquid Staking Token (LST). We believe that stETH brings many new opportunities to the DeFi space and enables the creation of more efficient protocols on top of it. Moreover, apart from being the primary foundational asset of the entire DeFi ecosystem, stETH enhances Ethereum’s security by increasing the number of validators on the network via staking. However, we have observed that the LST share has stabilized at a certain level and is not experiencing significant growth. Our hypothesis is that everyone interested in staking with LSTs has already done so. To unlock new growth drivers, we need to focus on users who do not want to interact with LSTs directly. This research aims to identify potential new growth drivers and explore how the current Lido implementation can be adapted to attract new stakers to Lido and mint stETH tokens.

It is important to note that this research was conducted in early 2024. While many staking-related constants and concepts in Ethereum remain relevant, they will soon be modified with the Pectra hard-fork (e.g., the initial slashing value or the maximum active stake per validator). Aside from these upcoming changes, the results of this research remain applicable.

We also want to emphasize that this research was conducted in collaboration with Lido Contributors, including Eugene Pshenichnyy, Max Merkulov, and Alexey Potapkin, who played an active role in the study and the preparation of the final report. We are immensely grateful to them for the opportunity to participate in this research, which we believe will contribute to the next phase of DeFi ecosystem development.

The biggest downside of LSTs is lack of flexibility (e.g., lack of ability to select arbitrary risk/reward setup with a particular Node Operator). There are three categories of users interested in more flexibility without losing access to stETH liquidity:

1. Institutional stakers (compliance, no commingling, have legal agreement with NO);
2. Restakers (more rewards and risks, ability to re-stake, unique NO setup);
3. Node Operators (stake with their clients through Lido).

If users are allowed to choose node operators, inevitably one or several dominant node operators will emerge, which will be so large that in catastrophic scenarios of mass slashing, the risks chosen by users when staking with them will spread to all other holders of liquid staked tokens. The possible solution here is to introduce an LTV parameter that accounts for all possible risks and reduces possible effect on the protocol from slashings.

In short, if users are given a choice to select a node operator and are compelled to bear risks, they would prefer their position's APR to align with that of the node operator's APR. Achieving this isn't straightforward, considering the complex reward structure, such as MEV. In theory, it's possible to compensate for underperformance by the node operator compared to the average, using the funds locked by the user. Conversely, if the node operator outperforms, rewards can be added to the locked funds, which can later be withdrawn upon exiting the position. Such a framework is not uncomplicated to implement and would require a cycle across all node operators, but it is feasible.

The proposed framework can be constructed, but even it is not yet flexible enough. Specifically, it fails to address:

1. Commingling;
2. Isolated position covered by legal agreement;
3. Within a single node operator, it is impossible to adjust risk/reward preferences (for example, one user may want to restake, while another may not).

To address these issues, let’s have one more step forward and let’s allow users to build their own positions with a particular Node Operator with a customizable setup. For these purposes we need to dive deep into the similar protocols which are the lending protocols that allows to borrow some tokens (stETH in our case) against some collateral (stake on a validator in our case).

The Overview section analyzes three types of protocols that implement one or more core mechanisms necessary for building Lido v3.

Overcollateralized Borrow Protocols – The section examines protocols such as Morpho Blue and Fluid by Instadapp, whose mechanics are essential for correctly implementing borrowing stETH against ETH (on validators). The borrowed ETH would then be sent to a validator for the specific Volt.

Synthetic Token Against Collateral – This part explores protocols that enable the creation of synthetic assets backed by overcollateralized positions, including Maker DAO, crvUSD, and Stakewise v3. It provides a detailed breakdown of liquidation mechanics and the key features that help these protocols maintain price stability for synthetic assets. Additionally, it discusses specific implementation nuances that arise from each protocol’s unique design.

Restaking – This section examines EigenLayer to determine which additional mechanisms might be required within Volt to support restaking.
Non-custodial Staking - This part outlines the mechanics that must be implemented to ensure decentralized and transparent staking in Lido v3.

General protocols

Definition of Overcollateralized Borrow Protocols

Overcollateralized lending and borrowing protocols require borrowers to provide collateral first. The LTV (Loan-To-Value) ratio controls how many assets can be taken out as a loan for a provided collateral amount (e.g., if LTV = 90%, this means that for collateral value = 1000 ETH a user can borrow up to 900 ETH). Overcollateralization means that borrowers should always provide more value as collateral than they are willing to borrow. This approach ensures that, in cases of a significant drop in the value of collateral, lenders would still have their assets to be redeemed.

LTV ratios can vary for different collaterals. The riskier the collateral, the lower the LTV ratio. It means that if a user brings a large amount of risky assets into the market, they still aren't able to take out a large loan.

Morpho Blue is a permissionless, overcollateralized lending and borrowing protocol where users can create their own markets with a selected pair of tokens - one that will be used as collateral and the second one that will be borrowed. Protocol owners only define allowed LLTV (Liquidation Loan-To-Value) and IRM (Interest Rate Model) parameters, which can be selected by users during market creation. Users also provide their oracles to determine collateral prices during the borrowing or liquidation process.

Fluid by Instadapp is an overcollateralized lending and borrowing protocol that allows users to provide collateral (and take out loans) to vaults created and configured by protocol owners. User positions are assigned with ticks, representing their supply-to-borrow ratio at the current moment. After any position modification, its tick changes if there were more repaid or borrowed tokens or if the collateral price changed.

Mechanics to work with collateral

In the Morpho Blue case, collateral is deposited by calling the supplyCollateral() function. When a user brings collateral tokens to the protocol, information about the amount brought is stored as position info. When a user withdraws their collateral, the same counter for amounts is reduced, and health of the position is checked – the user can only have a borrowed value less than the provided collateral.

Users will always have their collateral withdrawable in the Morpho Blue protocol, as the provided collateral is not loaned to anyone. Despite the fact that the whole protocol liquidity is stored in the one contract for all the markets, borrowers will always have their collateral withdrawable. There is a check at the end of the borrow() function which ensures that the user is not trying to borrow more tokens than there were supplied to that particular market. Thus, each market becomes isolated and there is no possibility that any manipulations in one market would affect others. If there is a malicious oracle added to one particular market which inflates collateral price, then it will only affect positions inside that market - borrowers can get diluted as there could be some borrows at a higher price, but they still would be able to withdraw their supplied tokens as they will have the same share in the market supply liquidity.

In all the cases users should be able to withdraw their collateral if their position is healthy. If a user closes a position, then their share in total borrowed assets is reduced, which won't affect others' positions' health. Position health only depends on the LLTV parameter, individual borrow shares, and the current collateral price.

In the Fluid protocol, users can deposit collateral by calling the operate() function. The deposited amount is stored in the user's position information, and the assets are transferred to a special Liquidity contract. A position is created and assigned a tick only when the user creates debt; their Loan-to-Value (LTV) ratio is calculated, and liquidity data is added to the appropriate branch and the global vault state. Users can also withdraw their collateral by calling the same operate() function, but with a negative collateral amount value. In every call to the operate() function, the user's position is checked to be healthy. If the collateral-to-debt value ratio changes, a new tick is assigned to the position.

As the collateral information is stored in the user's position data, that value can only be changed after liquidations or withdrawals are initiated by the users themselves. If a user's position is healthy and has enough space for collateral to be withdrawn (either a small loan or no borrowed tokens at all), the user should be able to withdraw it.

However, potential issues may arise due to the liquidity layer being shared for all vaults. If the collateral token from the current vault is being loaned in a different vault and there is a significant volatility in its price, it is possible to have too many collateral tokens loaned. When prices normalize, there may not be enough liquidity for withdrawals. While this won't be a Vault contract issue, as all position data is stored correctly, it will be related to the liquidity layer. The health of individual positions is calculated each time the positions are modified, and collateral withdrawal should not impact the health of other positions.

How Loan can be created

The Morpho Blue protocol allows users to take out a loan if they provide sufficient collateral and are willing to borrow an amount of tokens that keeps their position healthy. Loan tokens can be deposited by anyone through a call to the supply() function.

Loan token providers earn interest on the supplied tokens, but they don't have any collateralization in the protocol. Loan tokens are used in the future as liquidity for borrowers. If a user intends to take out a loan, they have to provide collateral first via a call to the supplyCollateral() function. In the Morpho Blue protocol, there are only two tokens for one market - the collateral token provided by borrowers and the loan (borrow) token, which is supplied by liquidity providers and borrowed by borrowers.

If there aren't enough deposited loan tokens available for borrowing, a call to the borrow() function will revert, triggered by a check ensuring that the total borrowed assets are less than the total supplied assets for that specific market. LLTV, collateral price, and the amount of collateral deposited are all considered when taking out the loan, preventing the creation of an initially unhealthy position.

In the scenario where a user attempts to redeem their provided tokens though there are insufficient loan tokens in the protocol (almost all supplied tokens are borrowed), the transaction would fail due to the check ensuring that the total amount of borrowed assets is less than the total amount of loaned assets. It is important to note that when market utilization rises to extremely high values, the interest rate model configured for the market should return increased borrow rates, making borrowing more expensive. In the Morpho Blue protocol, there is a basic model called AdaptiveCurveIRM. It helps to maintain the utilization rate near 90% while avoiding its growth to extremely high values, using a curve for interest rate adjustment. The interest rate grows in multiples as utilization approaches the 100% level. This model would make borrowing more expensive and would lead to more liquidations as users' positions would become unhealthy faster.

In the Fluid protocol, the Liquidity layer serves as a source of assets for borrowing, and a lending protocol is built on top of it to incentivize users to provide liquidity. The provided liquidity is then utilized by borrowers in the Vault protocol. Users in the Vault protocol can borrow tokens by calling the operate() function with a positive debt value amount. The function checks if the user has a healthy position, meaning they have provided enough collateral and the collateral's price allows for the loan. Only when the borrowing occurs, the user's position is assigned a tick and placed on a specific branch. This branch is configured with a liquidation tick, where user positions start to be considered unhealthy.

It is important to mention that there are no restrictions on the Liquidity layer which control using collateral token from one market as a borrow token in another market. There is a possibility to have not enough collateral tokens to be withdrawn if the user tries to do so when that collateral token was fully borrowed out in a different market. Also, there could be a bad debt scenario when there is not enough collateral tokens to be sent to liquidators when they bring borrow tokens back to the protocol. All those issues can be handled by manually depositing totally borrowed-out collateral tokens to the Liquidity layer or offering more lucrative incentives to attract deposits in the missing tokens.

If there are not enough tokens available to borrow on the liquidity layer, a call to the operate() function will fail when attempting to transfer the borrowed tokens to the user. It's important to note that the Vault protocol does not check if there is enough liquidity before executing all operations with the user's position.

Borrow interest

In the Morpho Blue protocol, each created market is configured with an IRM (Interest Rate Model) parameter. This parameter represents the address of an external contract that returns the borrow rate for the created loan markets. This borrow rate is utilized in the calculation of interest accrued by loan token depositors. Consequently, borrowers are required to return more tokens when repaying their debt, and liquidity providers have the opportunity to withdraw more loan tokens.

Additionally, the protocol allows for the configuration of a market fee. This fee is designed to distribute a portion of the borrow fees to the fee recipient specified by the Morpho Blue protocol owners. In this way, the protocol introduces flexibility in managing interest rates and fees, facilitating the allocation of earnings to different participants within the system.

In the Fluid protocol, the interest rate is determined by the underlying Liquidity protocol on which Fluid depends. There is a reward rate model configured for each token supported by the Liquidity protocol. Reward rates are utilized to increase the exchange rate from the underlying token to iToken (minted on the Liquidity layer). Vaults in the Fluid protocol leverage these exchange rates and calculate supply and borrow exchange prices in accordance with the liquidity in vaults. These exchange prices are used when updating users' new collateral and debt amounts during position modification.

Borrow interest is paid in borrow tokens. The borrow rate is configured for each token in the Liquidity protocol and is fetched from there. The borrow rate is applied during borrow exchange price calculation, which then affects users' debt amounts. Interest paid by borrowers (or liquidators in case of a liquidation event) is sent to the Liquidity layer upon position modification.

Health Factor

In Morpho Blue, there is a specialized check on user positions that involves the collateral price returned by the oracle, the LLTV (Loan-to-Value) parameter obtained from the market configuration, and the total amount of assets borrowed by the user. If a user tries to borrow more than the LLTV allows, this check fails. Furthermore, if the collateral price experiences a drop, the position is also deemed unhealthy and becomes subject to liquidation.

It's important to note that different LLTV parameters can be set for various markets, each corresponding to different pairs of collateral and loan tokens. This allows for a flexible configuration tailored to the specific characteristics of each market within the Morpho Blue protocol.

Fluid protocol allows configuring the liquidation threshold parameter for a particular vault. That value is used when checking the health of the user's position. Also, Fluid protocol leverages the usage of oracles to fetch collateral price data. When user's positions are placed on branches, there is a liquidation tick calculated which helps to determine when the position should be considered unhealthy. The collateral price and supply-to-borrow ratio affect the position status and are calculated each time the operate() function is called. If part of a user's position is subject to liquidation, then it is moved to another branch with a lower liquidation tick and marked as subject to partial liquidation.

Liquidations

In Morpho Blue, liquidation is only possible when a position is considered unhealthy. Users can call the liquidate() function and provide the borrower's address and the seized assets amount as parameters. Liquidation occurs for a specific position created by the borrower.

There is a check to determine if the position is healthy, utilizing the oracle price and the LLTV market parameter for collateral. The amount of debt tokens to be repaid is then calculated. A special parameter, the liquidation incentive factor, makes liquidation profitable by reducing the amount of assets to be repaid or increasing the amount of seized collateral tokens, depending on the calculation method.

It is possible to liquidate the entire user's position if it becomes unhealthy. After the liquidation process, the borrower's position collateral and debt values are reduced. If the borrower's collateral tokens amount drops to zero, there is a check for bad debt - global market counters for supplied and borrowed assets are reduced if applicable.

At the end of the liquidation process, the seized collateral is transferred to the liquidator, and the repaid debt tokens are transferred to the Morpho Blue protocol from the liquidator.

It is not possible to have a situation where collateral is inaccessible for transferring to the liquidator. The Morpho Blue protocol leverages the ERC-4626 standard, which ensures that all conversions from borrow to supply assets (and back) are proportional. Users won't be able to liquidate more collateral than what was originally deposited. If a liquidator tries to seize more assets than the user's position controls, then their transaction will revert.

In the Fluid protocol, liquidation happens for all unhealthy positions at once. Liquidators should specify the amount of debt they are willing to liquidate. The current vault top tick (which represents the latest user's opened position) is compared with a tick calculated using the current collateral price returned by the oracle, liquidation threshold set in global vault settings, and the supply-to-borrow exchange price ratio. The liquidation process starts if the current vault top tick is above the liquidation tick. In that case, a special loop starts, going over all accessible branches (representing different tick ranges and amounts of corresponding debt) until there is no liquidatable debt or the liquidator's requested amount is reached.

Collateral is sold at its current price returned by the oracle plus the liquidation penalty set for every vault. There is a special functionality that helps absorb bad debt. If there is no one willing to bring debt tokens or if the collateral price drops significantly, the liquidatable collateral and debt amounts are subtracted from special global variables storing as much liquidity as it was brought to the protocol to cover bad debts.

If there is not enough liquidity of collateral tokens to be transferred to the liquidator, then it is an issue related to the lending protocol or liquidity contract. In normal cases, it shouldn't happen, but if there is an attempt to liquidate more collateral than there is available, then a call to the liquidate function would revert on an attempt to transfer collateral tokens. There are no special checks ensuring that there is enough liquidity before the liquidation process starts.

Synthetic token against collateral

General definition of protocols with synthetic token

There is a subclass of lending protocols where a borrowed token is minted by a protocol itself. The total collateral across all CDPs in the protocol serves as collateral for this synthetic token, the total supply of the token represents the protocol's debt. The overall collateralization of the protocol (the ratio of these values) directly influences the market exchange rate, making liquidation mechanics especially crucial. Since emission is controlled by the protocol, more complex liquidation scenarios (including soft liquidation) can be implemented. Also, protocols of this subclass often have some mechanics for additional control over the market value of the synthetic token (peg mechanisms), but most of them are beyond the scope of this research.

Stablecoins are often built on the basis of lending protocols with synthetic tokens. Stablecoin is a token whose market rate is intended to be pegged to a certain external asset (most commonly the USD) by the protocol. This subclass have some mechanics for an additional control of the rate. Most of peg mechanisms are beyond the scope of this research. But some of them (like redemption in Stakewise) are also used in liquid staking lending protocols.

Borrow rate

Due to market volatility, there is a chance that a number of CDPs can become undercollateralized. Such undercollateralized CDPs make up the protocol's bad debt. The borrow interest rate (a fee that is charged from the users' debt) is one of the main tools for covering the protocol debt. So, to get the collateral back, users must repay more synthetic tokens than it was originally borrowed.

In Maker DAO, the borrow rate is called "stability fee". The interest on the debt is composed of two parts: a base rate for the entire protocol and a specific rate for the given type of collateral. The former is set by the DAO to encourage the opening or closing of CDPs (it depends on the current market situation), while the latter is used as one of the risk parameters for different types of collateral. The total interest collected from all CDPs increases the protocol's surplus, which can be used to repay the protocol's bad debt accumulated due to the liquidation of undercollateralized CDPs.

Liquidations

There are usually three groups of participants in lending protocols: lenders, borrowers, and liquidators. Lenders bring liquidity to the protocol so that borrowers can take that liquidity as a loan and pay a special borrowing fee to the lender to incentivize them to continue providing liquidity. Lenders should have some guarantees that their funds will be repaid, so borrowers are required to provide assets as collateral, which will be returned when the loan is repaid.

It is possible that a borrower would be unable to repay their debt (or intentionally wouldn't do that). In such a case, the liquidation process begins - the borrower's collateral is sold to liquidators with a discount in exchange for the repaid debt.

The liquidation process can be organized in different ways: it could be hard liquidations, soft liquidations, and collateral redemptions.

Hard Liquidations

Hard Liquidation is a classic liquidation mechanism where the liquidation process is irreversible. In Maker DAO, only hard liquidations exist. Any user can report an unhealthy CDP using a contract named Dog. A contract named Clipper is responsible for conducting collateral auctions (one Clipper contract for one collateral type). The debt of the CDP is added to the protocol's bad debt, and the collateral is transferred to the balance of the corresponding Clipper.

The auction is conducted in a Dutch format. Initially, a price in DAI is set for the collateral, exceeding the original debt of the CDP. Over time, the price decreases until a buyer is found for the collateral. The buyer can purchase either a part of the collateral or the entire collateral.

The curve along which the price decreases is determined by the Abacus contract (one Abacus for each Clipper contract). The reduction can be linear or exponential. The Dutch auction allows participants to avoid freezing their funds. Consequently, a liquidator can take a flash loan in a single transaction, purchase part of the collateral, and close the flash loan by selling the collateral on the market.

If a certain time passes since the start of the auction or if the price of the collateral falls below a certain threshold relative to the starting price, the auction can be restarted.

Soft Liquidations

Soft liquidation is a brand-new liquidation mechanism that was introduced by the Curve team in the crvUSD protocol. crvUSD protocol is a stablecoin protocol developed by the Curve team. Soft liquidation is a unique feature of this stablecoin, making users' collateral more robust to price fluctuations.

The collateral that users deposit to the protocol is placed in the internal AMM of the protocol. Internal AMM has bands (or ticks) that accumulate users' collateral. A user can place their collateral on a specific amount of bands. The higher the number of bands, the safer the user position, and the fewer crvUSD they can mint against collateral.

Internal AMM always makes incentivization for arbitrageurs to buy collateral for crvUSD when the price of the collateral drops on the market. Additionally, it makes an incentivization for buying crvUSD for collateral when the price of the collateral is begging to increase on the market. These mechanisms allow liquidations to be soft, which means that when part of the user collateral is liquidated because its price dropped, the collateral can be buy-backed via market actors, and the user will be able to return all the previously deposited collateral with a small fee that was used to incentivize the market actors.

The soft liquidation mechanism is a very powerful tool that guarantees that users' collateral can be returned to the protocol by the market actors if the price of collateral is restored. One of the requirements of this mechanism is that it requires collateral to be always liquid so that it can be easily exchanged for borrowed tokens back and forth. Unfortunately, liquid staking protocols are not able to meet this requirement because all the collateral is stored in the consensus layer, and it is not liquid enough. Moreover, the soft liquidation mechanism is more suitable for assets whose prices do not correlate (e.g., ETH and any stablecoin).

Redeems

Redemption is a mechanism for the protocol to buy its synthetic token back. It's important to note that redemption is distinct from repaying debt. The user conducting redemption may not even have their own CDP; instead, the tokens could have been obtained on the market.

In the StakeWise protocol a redemption mechanism allows to exchange osETH for ETH at the current exchange rate in the protocol.

CDPs whose LTV ratio exceeds the redemption threshold (currently 91.5%) are used for a redemption. Any osETH holder can come to a vault with such CDP and burn a portion of osETH at the exchange rate. Burnt osETH is subtracted from CDP's debt, ETH is taken from it's collateral. Unlike liquidation, there is no bonus for a redemption. Additionally, redemption can only be performed for that portion of the non-healthy CDP's debt which will make the CDP healthy again.

This mechanism serves to put pressure on the market rate of osETH. In the event of a price drop on any exchange, an arbitrageur can purchase cheap osETH, bring it to the protocol, and exchange it for ETH at a fair rate. This helps the market rate to normalize. Moreover, it slightly improves the health of the position for which the redemption was performed, thereby enhancing the overall collateralization of osETH.

Redemption is possible only for the ETH that is in the vaults (the majority of protocol's ETH is on the validators). If the market rate of osETH significantly falls below the exchange rate (meaning there's not enough ETH in the vaults for redemption), oracles must initiate the withdrawal of ETH from the validators.

Maker DAO features

Additional mechanics are also used in this subclass of protocols to make them more flexible during market volatility and to improve the reliability of the synthetic token. The protocol can use a secondary liquid token to absorb excess debt.

In Maker DAO, the governance token MKR is utilized for this purpose. If the system's undercollateralized debt exceeds a certain threshold, users are offered to settle the excess debt in DAI in exchange for some amount of MKR. As the stability fee is collected, the system's surplus grows and may eventually exceed another threshold. At that point, a reverse auction can be conducted, where MKR is repurchased by the protocol in exchange for DAI. The protocol's buy-back mechanism and the governance function of MKR make it liquid. Both the mechanic for selling MKR and the mechanic for buying it back are implemented through auctions, covering the debt or selling the surplus in the most fair way that reflects the current market situation.

The MKR sale auction is conducted by the Flopper contract in the form of a Dutch auction. The amount of DAI debt to be settled is fixed, and users compete over how little MKR they are ready to accept for it. If no one places a bid during the auction, it is restarted with a higher initial MKR price. Thus, if MKR has any value greater than zero, the auction should eventually conclude successfully.

The MKR buyback auction is conducted by the Flapper contract in the form of a classic English auction. The amount of DAI to be sold (from the system's surplus) is fixed, and users compete over how much MKR they are ready to pay for it.

StakeWise features

Apart from the mechanics described above, the StakeWise protocol has additional features necessary to liquid staking protocols with a synthetic token. These features are required because liquid staking protocols do not have equal rewards from the validators and are needed to approximate these rewards between all validators to calculate the average reward rate to increase price/balance of the liquid token. In the case of general liquid staking protocols with a validator set that is controlled by DAO, it is not a very hard task. A protocol can simply choose the average reward of all validators as a liquid token reward rate. But in the case of different subsets of validators in the protocol (StakeWise case), it is a more complex task. The reward rate for the liquid token is calculated as weighted APY from each vault in the StakeWise protocol. This approach is not very complex and leads to the disincentivization of the vaults with APY lower than average. It means that users' stake will move from less effective vaults to more effective ones because of the market and protocol mechanics. This approach increases protocol effectiveness but can be harmful to protocol decentralization.

StakeWise, as a liquid staking protocol, also has an additional feature that is typical for such projects. This feature is a possible slashing that can occur on the validators initialized from a vault. It brings an additional risk to the vault collateralization ratio, making it vulnerable to possible reduction. It is accounted for in the StakeWise protocol by setting the Loan-To-Value factor to 90%, which means that slashings that are not bigger than 10% of the staked amount will not cause a bank run event for the vault. In reality, the magnitude of slashings can be more than 10%, which means that, apart from protection via the LTV ratio, liquid tokens should be able to do a negative rebase or reduce the price. This is also possible in the StakeWise protocol, but only if all vaults report slashings on their validators. It means that an arbitrary vault that poorly manages its validators can cause a possible bank run event because collateralization of that vault can become less than 100%, and the protocol treasury should cover it.

Trust assumptions

Like the general overcollateralized lending protocols, protocols with synthetic tokens rely on trust assumptions to work according to specification. An example of such trust assumption is the mechanism of soft peg in the Maker DAO protocol. This mechanism relies on the fact that users who borrowed DAI from the protocol will buy it on the market when the price of DAI drops beyond the peg to cover their debt in the protocol (protocol always assumes that the DAI price is $1). Such mechanics is out of scope for this paper (the price peg of the token is not a necessary feature for liquid staking protocols), but it is necessary to understand that the protocol usually relies on such mechanics to work according to specification.

One such trust assumption related to liquid staking protocols that the Stakewise protocol has is that liquidators will wait up to 36 days (in case of slashing) to liquidate an unhealthy position in a vault. In case of a slashing on a validator owned by the vault, it is possible that a user's position could become unhealthy. It is also possible that there will be no ETH on the vault that can be used to cover liquidation. In this case, a liquidator will need to wait for some time (until the validator withdrawal is finalized) to liquidate the position.

Apart from that, the Stakewise protocol assumes that a slashing in a vault will not exceed 10%. Slashing events that exceed 10% have a very unlikely but still are possible. For such cases, the protocol should have a backup scenario; otherwise, a bank-run scenario is possible. All trust assumptions should rely on market mechanics that incentivize market actors to interact with the protocol according to specification (e.g., liquidations are always additionally incentivized by the protocol). If a trust assumption doesn't have additional incentivization - emergency actions should be documented and implemented by the DAO to react to such scenarios.

Actively Validated Services (AVS) are blockchain applications that need to determine whether a certain operation on the network is valid or not. AVS includes layer 2 solutions, oracles, keeper networks, etc. Of course, a new network may rely on proof of authority, meaning all operations are performed by nodes controlled by the protocol. However, such a protocol cannot be considered truly decentralized. One solution is to rely on the stakes of protocol participants, acting as a guarantee that all participants act honestly. If a participant engages in malicious actions, they lose their stake. Additionally, a user can provide some stake as a guarantee that a certain trusted actor (operator) performs their work honestly. Organizing staking in a new network can be quite challenging. The network's token usually lacks liquidity initially, so it's possible to rely on ETH as a stake instead. One method to economically attract stakers for AVS is through restaking. Restaking is a mechanism where the same Ethereum is used simultaneously for native staking and for staking in some AVS. Consequently, such a staker earns more. However, the risk also increases: the stake may be subject to slashing both in the consensus layer and in the third-party protocol. Restaking can be native, in this case Ethereum is directly brought into the restaking protocol, or based on Liquid Staking Tokens (LST), where tokens from liquid staking protocols like Lido are used.

EigenLayer is one example of a protocol that utilizes the restaking mechanism. The protocol supports both native restaking and LST restaking, but within the context of this study, the former is more interesting. How does it work? The entry point for a user is the EigenPodManager contract. A new EigenPod contract is deployed for every user through the EigenPodManager. EigenPod is responsible for all interactions with validators for a specific user. The user deposits 32 ETH and a validator credentials to EigenPod. EigenPod then sends the funds to the respective validator via the Beacon Deposit Contract, specifying its own address as the withdrawal address. This is a key point as the withdrawal address can only be set once, ensuring that EigenLayer controls the user's stake. After the user provides a Merkle proof that the deposit has reached the validator, shares in EigenPodManager are credited to the user.

As mentioned earlier, a staker can delegate their stake to a trusted operator. If the operator commits a malicious action, the staker will lose money. Each operator in EigenLayer works with one or several AVS. The delegation of stakes from stakers to operators is carried out through the DelegationManager contract. All shares that the staker has on balance are delegated to the operator at once. If the operator performs an incorrect action, all stakers who have delegated their shares to this operator face slashing. A user who wants to withdraw funds cancels the delegation of shares to the operator and queues for withdrawal. The delay is needed in case slashing occurs just before the withdrawal. Currently, the slashing mechanism in EigenLayer is still under development, as is the mechanism for reward distribution.

Overview

Non-custodial staking allows users to deposit their ETH in a fully transparent and non-custodial way. Full transparency means that ETH flow can be checked on-chain, starting from a user wallet and finishing ETH on the activated validator. Validator deposit data is stored on-chain, allowing users to check its validity before depositing. Non-custodial means that users are guaranteed to retain full custody of their funds during staking. In a nutshell, this means that users can withdraw all of their previously staked ETH + rewards at any time.

Currently, staking in the Ethereum network doesn't allow transferring Execution Layer rewards in a transparent way, which means that non-custodial staking protocols have to monitor all MEV and tips received by the validator and check that the validator sent them to a dedicated address. Apart from that, withdrawal requests also cannot be triggered transparently (EIP-7002 will change this). There are several ways to implement it in a semi-transparent way. One of the options is to allow users to make a call to the contract, which will emit an event. An operator should monitor this event, and after receiving this event, the operator should put the validator in the withdrawal queue. Another option here is to split a validator exit message into parts and send them to a trusted service, e.g., the oracle service of the protocol. This will allow users to build and send a withdrawal request anytime by requesting it from the oracle service. The process of splitting minimizes the risk of one of the oracles' private keys leaking.

For example, in the Kiln protocol, users can transparently stake their ETH. All operations with users' ETH will be transparent, thanks to the on-chain system of contracts. A validator deposit data is submitted on-chain before users' deposits and can be verified before usage. Staking rewards, including execution layer and consensus layer rewards, are accumulated on a special contract deployed for every user. Only the owner of the contract can claim these rewards. Additionally, only the owner can trigger the validator exit by calling a special function, triggering an event that an operator will process.

Distributed Validator Technology or DVT, can significantly increase the security of non-custodial staking by splitting up the validator's private key between shards. This will allow maintaining 100% uptime for a validator (which means no slashing because the validator is offline). Also, it will help store a validator's private key in a non-custodial way, allowing users to send the withdrawal request at any time without relying on event submitting-receiving services of operators.

Front-run vulnerability security measures

Front-run vulnerability allows a malicious node operator to pre-initialize a validator with a small stake and a malicious withdrawal address. According to the Ethereum Consensus Layer specification, the withdrawal address can be initiated only once with the first deposit. This means that the node operator can steal users' funds if NO pre-initializes the validator with its address instead of the withdrawal address selected by the users'. A detailed description of the vulnerability can be found here: https://medium.com/immunefi/rocketpool-lido-frontrunning-bug-fix-postmortem-e701f26d7971.

Trustless protocols, that allow any node operator to bring validator deposit data, should protect themselves from this type of attack. For example, the Stakewise protocol has a special oracle service that is signing validator deposit data by request from the Vault operators. While signing, oracles should check that the current deposit root validator hasn't been initialized yet. If everything is okay, they sign the message that is checked before depositing 32 ETH to the validator.

The Kiln protocol has legal protection from this type of attack. This is possible because the protocol signs a special agreement with the node operators. Additionally, there is an off-chain monitoring service that checks that Kiln validators are not used anywhere.

EIP-7002

EIP-7002 will bring Execution Layer triggerable exits. This EIP will allow the withdrawal address to send a validator exit message directly from the execution layer. It means that some of the mechanics currently used for non-custodial staking will be irrelevant. This will increase the transparency and trustworthiness of liquid staking protocols.

Currently, protocols use different tools and services to allow trustless exit message construction and sending to the Beacon chain. But all of these workarounds require trust from the users to services or providers. EIP-7002 will make liquid and non-custodial staking more trustless and reduce the amount of off-chain services.

Deposit data storage

There are several ways to store validators' deposit data. One of the options is to store all the necessary data on-chain. In this case, all the data can be easily verified by all stakers, which gives more transparency to the protocol. Non-custodial staking protocols should be as transparent as possible, making this option more suitable for such projects.

Another option is to store the deposit data in a way that minimizes on-chain storage usage. For example, the approach from this discussion can be used. Storing deposit data this way will allow to minimize transaction costs significantly.

It is possible not to store deposit data on-chain at all. This can be achieved via a special service that will check and sign deposit data off-chain and send to the protocol operators signed data that can be used to initialize a validator in the Ethereum network.

The main goal of the design described below is to utilize stETH liquidity without participating in socialization mechanisms of classic staking (staking via Lido v2), via providing ETH staked on Validators as collateral with built-in economics.

Constraints of the design:

• A user should not affect the APR of stETH under normal conditions;
• Minted stETH should be backed up by collateral: ETH staked on Validators is considered as collateral;
• Risk on validators (provided as collateral) performance is mitigated up to extreme conditions within a reasonable approach;
• Risk on validators (provided as collateral) ownership is mitigated via Withdrawal Credentials control under the protocol.

This section outlines the core mechanisms that must be implemented in Lido v3 to ensure seamless staking operations while adhering to previously established constraints.

The key idea behind Lido v3’s architecture is the creation of independent, customizable vaults that can accept ETH from users and enable the minting of stETH, using ETH on a validator as collateral.

One of the primary constraints in designing Lido v3 was that Lido v2 must continue operating in its current form (a more detailed explanation of this can be found in the relevant section).

This section describes the mechanisms required to realize Lido v3’s core concept. Since each mechanism can be implemented in multiple ways, we have provided a thorough rationale explaining why the chosen approach is the most effective.

General Flow

Users deposit ETH to a Vault and receive ERC20 tokens from this Vault. The amount of ERC20 tokens represents a user share in the Vault. There are several options for how the user position can be represented in the Vault. It could be ERC20 tokens, an NFT token of that specific Vault, or just internal information in the Vault. Considering that a Vault share has a fungible nature and should allow transferring value between different actors, it is better to use an ERC20 token that represents position in a Vault. This option will also enable to additionally incentivize to stake in a specific Vault by Vault managers. They can easily create a farming pool. Moreover, the option with an ERC20 token will make it easier for integrators to integrate with the protocol.

After making a deposit to the Vault, the user becomes a Vault shares holder, and they can request to withdraw ETH from the Vault at any moment. The possible amount of ETH that can be requested by the user should be calculated taking into account the total ETH controlled by the Vault, the user amount of shares in this Vault, and also the user's possible debt. (We will talk a little bit more about users' debt and how it can be created later.) To fulfill the withdrawal request made by the user, the Vault should use optimal proportion between execution layer rewards accrued by the Vault, new deposits to the Vault, and withdrawn ETH from validators. The proportion should be selected, optimizing the APR of the Vault. Considering the assumption that exiting an old validator and initializing a new one can significantly reduce rewards, as far as activation and exit queue length is concerned, it will always be more profitable to the Vault to use new deposits to cover withdrawals. The withdrawal queue implemented in Lido v2 is a very good example of how the withdrawal process can be implemented for each Vault. A withdrawal queue will also solve possible slashing accounting problems for withdrawal requests.

stETH minting from a Vault is the process of borrowing stETH from the Vault by a user. In this case, collateralization of the user is the amount of virtual ETH (because most of the ETH will be allocated to validators) that the user has in this Vault. This amount can be calculated as (users_shares / total_Vault_shares) * virtual_Vault_ETH. How a Loan-To-Value (LTV) will be calculated for each Vault is described in detail in the risk management section. It is important to note that Lido v2 is "lending" stETH to Vaults using active validators as collateral, so a Vault will have an LTV = 0% until it activates at least one validator. Since stETH is a rebasable token, borrowing stETH means that a user will need to return the initially borrowed amount plus stETH rebase for the period of borrowing. If the Vault APR is less than the Lido v2 APR, the user's debt will increase faster than their collateral and vice versa. The transfer of vault shares should trigger a health factor calculation for a user because it affects the user's collateralization.

Vault Management

Vault management should cover the selection and initialization of new validators, putting old validators in the exit queue, updating the Vault rewards and losses, and updating the state of the withdrawal queue. The Deposit Data storage process is described in detail in the "Storing validators DD" section. Here, it is important to think about the case when there are no new validators that can be initialized from the Vault that has enough free ETH to initialize several validators. This scenario can negatively affect Vault APR and can be triggered by a malicious actor that wants to liquidate positions in the Vault. Depositing excessive ETH to Lido v2 or other Vaults will partially solve the problem with low APR. Still, it will inevitably trigger validator exits in Lido v2 or Vaults in the future, so this option is not very good for the protocol. Another option is to limit ETH deposits to the Vault with the number of available validators that can be initialized from the Vault. The case when the Vault doesn't have new validators to initialize is very unlikely, so the deposit limit shouldn't be triggered in normal cases.

Selection and initialization of new validators should be controlled by Vault Operators. Deposit Data should be approved by Lido DAO via several checks during validator initialization. It is vital because Lido should be able to withdraw funds from the validator at any moment if it starts to act maliciously. For this purpose, the withdrawal address should be checked, and the deposit contract root hash should be checked to be confident that the validator wasn't initialized before with a different withdrawal address. Deposit Data selection should be controlled by Vault Operators by setting a specific order of DD during the upload of the data. Also, the order of putting active validators to the exit queue should be controlled by Vault Operators, so that they will able to put a validator that requires an update to EL or CL clients to the exit queue. The process of putting an active validator in the exit queue is described in detail in the "Putting existing validator into the withdrawal queue" section.

Vaults should have a very important state variable that will account for all ETH that is controlled by the Vault. This variable should account for all new deposits, the current amount of ETH on validators (active validators, validators in the activation queue, validators in the exit queue), Execution Layer rewards, etc. Considering the possible huge amount of Vaults and the fact that a validator balance isn't accessible from the Execution Layer, the Consensus Layer balance of validators should be updated by external oracles. Updating a state variable for each Vault will be too expensive, so it is better to use the Merkle tree technique to minimize storage space consumption. Only the root hash of the Merkle tree can be updated once per epoch, and Vault Operators can update the Vault state after that with the proof for that Merkle Tree.

Merkle Tree root hash should be updated in a particular contract that will be accessible from all Vaults. Root hash cannot be controlled only by one actor because manipulation of this value can be easily used to drain all funds from all Vaults. A special off-chain network of permissionless oracles should be maintained by Lido DAO to update this value.

The withdrawal queue should be updated every epoch; the duration of the epoch can be selected depending on the gas costs for updating (epoch duration can be a day or 8 hours, for example). All newly deposited ETH cannot be used for fulfilling withdrawal requests before the epoch update.

Storing validators Deposit Data

Validators deposit data (DD) can be stored in three ways: fully on-chain, off-chain, or a combination of on-chain logic paired with off-chain services. Let's examine each approach and determine the most suitable one based on the protocol's needs, aiming at efficient and trustworthy solutions.

• Fully On-chain
• Storing validators deposit data entirely on-chain would provide maximum transparency, enabling anyone to verify the stored data. This approach prevents from depositing to unapproved keys and potential reuse of validators' keys. All logic can be implemented at the smart contract level. However, this approach introduces complexity and increases gas usage. Deposit data written to the contract still should be validated - it can be an approval from DAO or built-in checks that will ensure the correctness of the data. It is still possible to have incorrect data written to the contract by a trusted party, and there should be special functions that would help to rewrite it. All these requirements will lead to additionally implemented logic. Vault Operators would need to write validators deposit data to the smart contract storage, resulting in higher operational costs. Users could deposit ether to the contract, triggering a call to the Beacon Chain Deposit Contract with parameters read from the storage.
• Off-chain
• Using an off-chain service to manage all data significantly reduces costs for Vault Operators but makes the data unverifiable. This creates potential vulnerabilities for manipulation and compromise. An off-chain service could monitor user deposits and, when there is enough ether to initialize a validator, directly call the Beacon Chain Deposit Contract with parameters read from the local database and signed on the fly. In this scheme, users have no control over the validator deposit data used during initialization, requiring blind trust in the off-chain service.
• Mixed Off- and On-chain
• A mixed approach involves using both off- and on-chain methods. On-chain storage can be limited to the Merkle tree root of all available validators DD. The off-chain service maintains the Merkle tree structure, adds new validators data (that is verified beforehand), and pushes the tree root to the smart contract. Vault Operators only need to provide a proof that their validator deposit data was included in the Merkle tree, whose root is currently stored in the contract. This approach allows users to validate deposit data before making deposits and reduces gas costs for operators, as they aren't required to store all validators data on-chain.

Choosing the most suitable approach will depend on the trade-offs between transparency, cost-effectiveness, and trust. Considering the need for user validation and reducing operational costs for Vault Operators, the mixed off- and on-chain approach seems to strike a balance by providing transparency while minimizing on-chain storage requirements.

Validators exit messages can be implemented in various ways, and one approach involves Node Operators having control over validators exiting, potentially allowing them to halt withdrawals, which is beyond the user's control. Currently, there's a method utilizing pre-signed exit messages, but it requires additional communication between Vault Operators and the protocol oracles.

In this approach, users need to send a special request to the Node Operator after making deposits. The Node Operator responds by sending a signed exit message back to the user. This process ensures that the user will be able to trigger a validator exit at any time in the future using the pre-signed exit message. However, it also assumes that users will not have control over their funds during the period between making the deposit and receiving the pre-signed exit message from the Node Operator. That naive approach is described in details in the EIP-7002 explainer article.

It's important to note that this communication scheme reduces the security of user funds, as users are responsible for storing the received pre-signed exit message in a secure location. Additionally, the user's lack of control during the interim makes one wonder about the overall security and trustworthiness of the process.

Execution layer triggerable exits (EIP-7002), compared to pre-signed exit messages, introduce a few improvements. Firstly, users have full control over the withdrawal process instead of relying on off-chain services (as an example, the StakeWise oracle system, which helps to rebuild pre-signed exit messages). Secondly, communication between users and Node Operators is significantly reduced - EIP-7002 just brings in new consensus layer functionality instead of additional requests made to Node Operators by users to initiate pre-signed exit message creation. And finally, EIP-7002 strengthens users' fund security, as they won't have to worry about the secure storage of the pre-signed exit messages and just send a withdrawal request whenever they want to.

The approach described in EIP-7002 introduces a special precompile that handles exit messages initiated on the execution layer by an entity holding validator withdrawal credentials. This scheme provides full control of the exiting process to the stakers without any periods of time when stakers aren't able to trigger validator withdrawal.

EIP-7002 is considered a strong solution, especially for non-custodial staking scenarios, where users have the autonomy to decide when they want to initiate the exit.

New Validator initialization

According to the chosen approach, new validator initialization should be carried out in multiple steps, encompassing both off-chain and on-chain processes. Initially, the new validator data needs to be properly packed and added as a leaf to the Merkle tree, which is stored off-chain. This action triggers an update of the Merkle tree root, requiring it to be pushed on-chain to the smart contract responsible for handling user deposits. The updated root can then be used for validators' data initialization.

Once the new tree root is pushed to the contract, the operator making the deposits should be able to provide validator DD along with a Merkle proof. This proof serves to demonstrate the inclusion and validity of the provided data. The proof lengths could also be reduced if the off-chain service stored not only the tree root but also a few subsequent nodes. These nodes won't be the tree leaves if the tree size is chosen according to the total number of validators for a specific Node Operator.

Additionally, an on-chain counter should be implemented for each used validator deposit data. This counter would prevent operators from selecting an already initialized validator, ensuring that the validator initialization process is unique.

Putting an existing validator into the withdrawal queue

Based on the text of EIP-7002, a special precompile is proposed to be introduced. This precompile would enable the sending of a basic Ethereum transaction to a specific precompile address. The transaction should contain the exiting validator's public key and originate from the withdrawal address specified by that particular validator. The purpose of this precompile is to handle an exit messages queue and forward the validators exit messages to the Beacon Chain. The process of submitting a validator exit message on the Ethereum execution layer has a detailed overview. It describes all the necessary checks and state updates that occur during the message submission.

Exit messages sent to this precompile would be processed by the consensus layer in a manner similar to regular voluntary exits. This mechanism allows for a more direct and controlled initiation of the validator withdrawal process by stakers, providing a convenient and secure way for users to manage their staking assets and exit validators when needed.

Finalizing withdrawal request

EIP-7002 introduces a special value in the Beacon Chain block headers - exits_root. This field will be used to store the Merkle tree root of the exit messages stored in the block body. These values can be monitored and validated by an off-chain service, which will then fetch validators' public keys willing to exit and continuously monitor their status.

Once the withdrawal is finalized, the off-chain service pushes that data to the vault contract and updates the information on the available funds (on the validator no longer receiving rewards and having exited). It is important to check the validator's status and update the contract state only at the time when it becomes exited and then becomes withdrawable after 256 epochs. Such an approach will eliminate possible scenarios where a validator gets slashed during the exiting phase and their withdrawal gets delayed.

An off-chain service serving as an oracle can send requests to the Beacon Chain RPC Node, querying data on the recently finalized blocks and their exit messages tree roots. Then, the block body can be used to obtain the list of exiting validators to perform requests on their statuses. As soon as a validator's status is changed to fully exited, on-chain data regarding the validator's status can be updated by the oracle.

General considerations

Lido with Vaults design should allow an arbitrary validator selection and management. This feature brings in an additional risk that a validator will be maintained improperly or maliciously. In both cases, Lido faces the risk that ETH on a validator will not be sufficient to cover minted stETH from the Vault. To mitigate this risk, the following concepts are embedded into the design:

1. Overcollateralization (LTV < 1);
2. Bonds of NO participating within the vault (optional).

Focusing on (1) to determine the possible magnitude of the validator's balance reduction, the potential slashing risk should be decomposed into key components:

1. Initial slashing penalty (1/32 of effective balance, 1 ETH per Validator);
2. Correlated penalty (3S/32 of effective balance, rounded down to the nearest integer, where S is the share of simultaneously slashed validators);

• Inactivity penalties during the exit period, determined by:APR on CL (base reward);
• Length of the exit period (exit queue);

3. Further rebase of stETH during the exit period (the same as (3) + APR on EL).

A risk-based LTV, hence, should be determined based on the scenarios that the provided LTV can cover, with more extreme versions covered by the external sources (protocol cover fund, NO bonds, etc.) or socialized on stETH holders.

Within the assumption on the CL & EL APR, different curves based on various risk appetites could be determined (% of ongoing slashing, churn limit and exit queue size). An additional risk factor for the calculation is the amount of ETH of NO(s) within the whole Lido protocol. Overcollateralization can be considered as a risk-mitigation for risks of NO(s) participating in different modules (Curated set module).

The value of a liquid or synthetic token held by users in liquid staking protocols typically increases over time by APR. Technically, this can be implemented either through a rebasable token (like stETH) or through a token for which there is an exchange rate (like osETH or rETH). While it may seem that in different liquid staking protocols this token plays roughly the same role, there are actually serious differences in business logic.

In StakeWise, users deposit ETH and receive the vault shares in return. Users earn through the increase in value of these shares. The ability to mint osETH serves as a way of additional incentivization. A user may choose not to mint osETH, using the protocol purely for staking purposes. They might also mint tokens and hold them (for instance, as insurance against a sudden mass slashing of validators in their vault). So, in the case of StakeWise, the APR can be adjusted within some limits. If it's set too high, a significant portion of CDPs will become unhealthy over time as the debt grows quicker than the vault's validators' APR. The creators of the protocol chose the protocol's APR to be the weighted average APR among vaults. Probably the goal was to ensure that the health factor of CDPs in vaults performing at or above average does not decrease over time. So, the system is kept healthy on average. Also, if there were no liquidation mechanism, a too high APR would result in the total value of osETH growing faster than the overall amount of ETH on the protocol. This means the protocol would become undercollateralized. But, even with an APR of zero, redeeming any volume of osETH would not be possible as only CDPs with a low health factor can be used for redemption. Furthermore, a significant portion of ETH is on validators and requires substantial time to withdraw, so it can't be called fully liquid.

What could be the strategy for selecting an APR (= borrow rate) in liquid staking protocols with a fully synthetic token (like in Stakewise)? All vaults based on the APR can be divided into two parts. Those with a vault's APR lower than the overall borrow rate and those where it is higher or equal. The first type of vaults will experience two kinds of pressure. Firstly, liquidity in general will tend to move to vaults with similar risk but a higher APR. Secondly, CDPs in the first type of vaults will lose their health factor over time, meaning positions in such vaults will be more prone to liquidations and redemptions (if such a mechanism is implemented). Therefore, liquidity will flow from the first type of vaults to the second type. If all vaults are sorted by APR, the borrow rate will determine where the line dividing these two types is drawn. In other words, what percentage of vaults must either increase profitability (which is not always possible) or face an outflow of funds. The dividing line can be drawn in several places, each option having its pros and cons.

Let's take a part of the vaults with the highest APR, having a quarter of the protocol's liquidity (let's call this the upper quarter). The average APR for the upper quarter is set as the borrow rate for the synthetic token. Advantages of this approach: vaults are forced to compete for the efficiency and reliability of validators, any mistake reduces overall profitability, and hence the chances of survival. Vaults need to introduce additional mechanics such as restaking, involving external protocols in the current protocol, thereby increasing the role of the liquid staking protocol in the overall DeFi market. A high APR is also attractive to holders of the synthetic token, thereby increasing investment attractiveness. The downside is that it lowers decentralization; more than three quarters of the vaults become inefficient and will most likely lose liquidity fast, which will flow into the upper quarter. After the redistribution of funds, the new upper quarter will contain even fewer vaults, which will again pull all the liquidity. Over time, this could lead to all liquidity being in one gigantic vault. Moreover, it's better when the basis of liquid staking is classic conservative staking. However, it will not have such a high APR, and the most efficient vaults will use experimental mechanics such as restaking. If something goes wrong (for example, if problems arise in an external protocol using restaking), the liquid staking protocol will also face problems.

If the line is drawn in the middle of the protocol's total liquidity, one half will be in poor vaults and the other half in good ones. A similar option is used in Stakewise, and it seems like a compromise at first glance. The APR that the vaults should have to survive is lower, so this approach is more democratic. At the same time, the borrow rate is defined as the weighted average APR, so large vaults with high liquidity have more influence. And a large part of ordinary vaults with classic strategies will become not enough profitable again, which will continue to lead to a greater strengthening of large risky vaults and centralization over time.

Finally, what if we take the lower quarter - the vaults with the lowest APR having a quarter of all liquidity and define the borrow rate as their average APR? In this case, most of the liquidity will be in vaults where the profitability exceeds the borrow rate, so users can invest in more conservative strategies without the risk of being liquidated. At the same time, low efficiency will make the asset less attractive. Therefore, holders might prefer other liquid staking tokens with roughly the same risks but a higher APR. Moreover, the yield on the synthetic token should serve as protection in case of bad debt occurring. For example, this could happen if, due to massive slashing, the LTV of a particular position rises above 100%, making it unprofitable to liquidate. Borrowed tokens in this CDP become not collateralized. Such positions are also covered by the interest on the total debt. Therefore, a low borrow rate increases sensitivity to bad CDPs and may require a lower LTV.

The situation is different in the classic Lido V2. The main contract in Lido is stETH. Users bring ETH to the protocol and receive shares of a liquid token. stETH.balanceOf() for a user represents the user's amount of Lido V2's total ETH, most of which are engaged in staking. Therefore, for Lido V2 it's not possible to choose an APR - it simply reflects the changes in the protocol's total funds due to staking rewards/penalties.

In the new system stETH will be minted simultaneously by the classic version of Lido V2 with a curated set of validators and by Lido Vaults. So, there is a question: what should be the APR of stETH in the new system? One option is to make stETH fully synthetic, constructing its APR from the APR of Lido V2 and Lido Vaults (creating an architecture similar to StakeWise). However, this raises several questions. Lido V2 in its current form would have to stop existing - as stated in the previous paragraph the APR in stETH now can't be set externally, it just reflects the current ratio of shares to liquidity in Lido V2. To make this work an additional token wrapper around Lido V2 should be created. From an investor's perspective, a synthetic variant in which the token reflects a certain state of the system, rather than being a share of liquidity, appears less favorable. Therefore, transitioning to a combined variant would cause stETH to lose one of its advantages.

One option that at least makes fewer changes in the current architecture of Lido V2 is the following. stETH continues to represent the user's amount of the total Lido V2's liquidity. When a user mints stETH in Lido Vaults, they are effectively borrowing it from Lido V2 at some borrow rate. The balance of stETH borrowed by the user from Lido Vaults rebases over time, and simultaneously the user's debt increases at the borrow rate. In such an architecture the total volume of Lido V2's liquidity will consist of ETH from Lido V2 on validators and ETH borrowed by Lido Vaults.

What should be the borrow rate in this case? It must be no less than the APR of Lido V2 validators, otherwise, stETH would grow faster than its collateral, leading to undercollateralization. Therefore, the borrow rate can be broken down into two components: the base borrow rate (equal to the APR of Lido V2 validators) and the additional borrow rate. The size of the additional borrow rate determines how much the APR of validators in a given vault must exceed the APR of Lido V2 validators. Otherwise, CDP's of users in that vault will lose health over time.

The new version of the protocol not only sets the APR in Lido V2 but also acts as the base borrow rate in Lido Vaults. The following hypothetical attack is based on the manipulation of the base borrow rate. NO is some node operator managing validators from the curated set of Lido V2. This Node Operator doesn't hold a stake in Lido V2 but earns through staking fees. Also, there's some Vault in Lido Vaults with a standard APR matching the APR of Lido V2 validators. NO might then perform the following actions:

1. Deposit ETH into Vault.
2. Mint stETH collateralized by this ETH.
3. Exchange stETH for ETH.
4. Deposit the obtained ETH back into Vault.
5. Artificially reduce the efficiency of the validators under their control in Lido V2.

Step 5 would lead to a reduction in the APR of Lido V2 validators, consequently lowering the base borrow rate for the NO's debt. After this, the yield of Vault becomes higher than the base borrow rate. So the shares brought in from the step 4 increase in value faster than the debt from step 2. Calculations show that even considering the reduced rewards for running Lido V2 validators and Vault's commission, NO remains profitable. Moreover, to maximize profits, NO could repeat steps 2-4 after step 4, effectively leveraging their stETH position.

One way to mitigate the potential for this exploit is to introduce an additional borrow fee, taken in Lido Vaults in addition to the base borrow fee. In this case Vault would need to operate more efficiently than the curated set from Lido Vaults for the attack to make sense.

Lido with Vaults will have a complex architecture that allows two options for minting stETH token: from Lido v2 via depositing ETH to the Lido contract and via Vaults via depositing ETH to a specific vault and using this collateralization to borrow stETH. It is possible that at some point in time, the Vault option will become more efficient and attractive for users with different risk profiles. Even if Lido v2 option is efficient enough, there is a chance that Vaults depositors will decide to use stETH withdrawal from Lido v2 to boost their leverage in vaults (e.g., it can be much profitable for users to mint stETH from Lido with Vaults, unstake them via Lido v2 and stake more to the Vault with the APR higher than Lido v2 instead of leverage option in Aave). In both cases, there is a chance that all ETH from Lido v2 will be deposited in the Vaults, making the withdrawal process impossible for users without an open position in the Vaults. The second case is more severe because it will leave OG stakers (that deposited ETH to Lido v2 or even to Lido v1) without the option to withdraw their stETH and receive ETH back. This means the option not to withdraw stETH from Vaults for any user will make the protocol insolvent. Insolvency, in this case, means that OG stakers that hold stETH will not have the option to withdraw stETH from Lido v2. They will be able to swap stETH for ETH on the market, but there will be an additional price risk. stETH will lose the LST feature in this case and will become synthetic ETH. Let's compare these two options taking into account previous cases that happened on the market.

Considering this comparison and the fact that stETH is the first LST token on the market (stETH is currently an LST, and losing this feature will negatively affect current stakers), it is inevitable that Lido with vaults architecture should support the LST feature for stETH. This means that stETH should be withdrawable for Vault depositors from Lido v2 and Lido v2 stakers from Vaults or Lido should incentivize users to keep Lido v2 TVL at some secure level so any stETH stakers can withdraw their funds.

It is worth noting that making stETH withdrawable from any Vault for any user is also not secure because it will allow malicious Vault operators to drain small Vaults. This will be possible because operators of huge Vaults can simply borrow stETH from their Vault, withdraw it from any Vault, and deposit ETH to their Vault after the withdrawal process ends.

Taking into account everything said above, we have two options: Lido with Vaults architecture should be able to withdraw ETH from Vaults (and not from any Vault for any user) or should incentivize users to keep Lido v2 ETH supply on some secure level. Lido with Vaults will make Lido v2 to work as a buffer for leverage staking because this will allow more secure and efficient leverage staking. stETH leverage staking via AAVE shows that users are likely to borrow as much as possible ETH to stake them again to increase their rewards from staking. This means that it is very likely that Lido v2 TVL will shrink without additional mechanisms to incentivize some secure level of ETH staked via Lido v2.

The StakeWise v3 protocol doesn't have a legacy part that allows the withdrawal of osETH to receive ETH from v2, which makes this problem not severe. The StakeWise's osETH token cannot be withdrawn from any vault. To withdraw it back to ETH, a user must have an open position in some vault. This means that users who bought osETH on the market did not purchase an LST token that can be redeemed for ETH at any time. Actually, the user bought a synthetic ETH, the price of which relies on the protocol actions and management. It is a fair option because a well-known DAI token works similarly. DAI is not a US Dollar that can be redeemed at any time at face value. DAI can be used as a US Dollar in DeFi, but it is only a synthetic representation. This approach is not suitable for the Lido protocol because it has the legacy part that relies on the fact that the stETH token is an LST and not a synthetic ETH.

Several options can be used separately or together to provide reliable incentives for holding a secure level of TVL on Lido v2 to ensure that the stETH token has an LST feature. The first option is an additional borrowing fee for stETH borrowers from Vaults. This fee increases with the increase of the proportion borrowed_stETH_from_vaults / Lido_v2_TVL, and this additional fee is transferred to the Lido v2 APR (increasing the APR). This approach will disincentivize decentralization as described below. Considering that the borrow rate for borrowing stETH will be equal to the stETH APR in Lido v2, it is more likely that there will be Vaults with an APR not lower than the APR of Lido v2 (Vaults with the APR lower than Lido v2 will be liquidated and redistributed to more profitable Vaults and Lido v2). So, let's consider that we only have vaults with an APR equal to Lido v2 or higher. A case with the Additional Fee will gradually disincentivize stakers from staking to the Vaults with the APR equal to the Lido v2 APR (because the Lido v2 APR will be gradually increasing as leverage stakers that are more likely to restake ETH to the Vaults with the highest APR to accrue more rewards will cause reducing of ETH in Lido v2 which will trigger a borrow rate increase and also a Lido v2 APR increase). This option will leave only very efficient Vaults. Stakers will restake all possible ETH via Lido v2 that can be restaked without liquidation.

The additional Fee mechanism will gradually cause liquidations in Vaults with an APR equal to the Lido v2 APR. Liquidations will require liquidators to bring stETH to Vaults. Taking into consideration that Vaults will have an LTV less than 100%, liquidators will be disincentivized from borrowing stETH from Vaults to liquidate unhealthy positions. A more efficient way for liquidators is to deposit ETH to Lido v2, get stETH from it, and liquidate an unhealthy position with profit (here we assume that the liquidator is holding ETH and wants to conduct a liquidation to receive the same token with profit). This means that the Additional Fee mechanism supposedly will increase Lido v2 TVL.

It is worth noting that Lido v2 could have an additional mechanism for liquidating unhealthy positions in Vaults. The main idea here is to mint virtual stETH to liquidate an unhealthy position. In a nutshell, the process of liquidating an unhealthy position via Lido v2 will transfer staked ETH of a user that created a position in a Vault to staking ETH with Lido v2. A liquidation discount will be used as rewards for stETH stakers that will need to wait for the validator from the Vault to quit from staking and transfer ETH to the Lido v2 and initialization of a new validator from Lido v2.

The second option is to add an additional fee on withdrawal from Lido v2, a disincentivizing leverage via ETH on v2. This option doesn't solve the problem of small liquidity in Lido v2 and also disincentivizes stakers to stake with Lido. Taking into account the scenario from the Additional Fee case that assumes that there will be no Vaults with an APR lower than the Lido v2 APR, withdrawal disincentivization will not help to stop the process of ETH migration from Lido v2 to the Vaults with the highest APR. Additional withdrawal fees will only make it less profitable. The withdrawal fee will reduce the Vaults LTV, but even with a 10% withdrawal fee (which will negatively affect a Lido v2 TVL increase), the Vaults LTV will be higher than the stETH LTV in AAVE. Additionally, the withdrawal fee will disincentivize stakers to stake ETH with Lido v2, which is also bad, considering that Lido v2 will work as a buffer for leverage staking.

The third option is to add a withdrawal controller that will distribute withdrawals between Lido v2 and positions in Vaults with the highest LTV ratio. In short, this option simply makes a variable LTV. For example, if a user has an LTV equal to 95% (let's assume that this user has the highest LTV among all Vaults) and the withdrawal controller contract decides that part of the withdrawals should be covered from Vaults, then the user will be partially or fully liquidated without losing a liquidation bonus. Enabling a variable LTV will disincentivize users from leveraging stETH via vaults because it brings additional risk of being liquidated. The variable LTV feature is more suitable as a disincentive for the riskiest positions. This means that ordinary stakers that will be using Lido with Vaults to participate in liquid staking are less likely to try to borrow stETH with the maximum LTV. If they are looking for maximum utilization of the stETH (which means they need a 100% LTV), they will likely choose to stake with Lido v2. We can distinguish 3 types of stakers in the new Lido with Vaults architecture: 1) Ordinary stakers who are seeking to explore stETH as collateral in other DeFi protocols (they are more likely to stake via Lido v2), 2) Stakers that want to stay liquid and that are looking for the highest APRs (they are more likely to stake via Vaults with the highest APR and not to borrow stETH at all or borrow it with a low LTV) 3) Stakers who are looking for leverage staking (they are more likely to stake via Vaults with the highest APR and borrow stETH with the maximum LTV to restake). The third group of stakers will probably reduce the Lido v2 TVL because of the restaking. The users from this group should be disincentivized to reduce the TVL of Lido v2 too much, so the variable LTV mechanics should help.

Let's take a closer look at what will happen with the liquidated user who had the highest LTV and the withdrawal controller that decided to use the user's position to fulfill the withdrawal request. At the start, we had the user with collateral = 1000 ETH and borrowed 950 stETH with the LTV equal to 95%. Let's imagine that there was a huge withdrawal request, and the withdrawal controller calculated that 500 ETH should be withdrawn from the riskiest position. After the withdrawal, the user will have collateral = 500 ETH, total borrow = 450 stETH, making their LTV equal to 90% (it is important to note that now the user has 500 stETH that doesn't need to be returned to the protocol, but they can be easily redeemed via Lido v2). As we see at the end, the user has the same value (1000 ETH as collateral at the beginning, 500 ETH as collateral, and 500 stETH at the end).

Before moving on to choosing a liquidation architecture, it's important to note several key features of Lido Vaults:

1. Only ETH can serve as collateral. All ETH can be used by Lido V2 to generate profit.
2. The issuance of stETH is controlled by the system (Lido V2 and Lido Vaults). At any moment the system can determine the value ratio of the debt token to the collateral (the stETH rate).
3. A significant portion of the collateral is on validators. Extracting collateral from validators is a predictable and controlled process. However, withdrawing ETH takes a few days (and can take up to 36 days). Therefore, such collateral cannot be considered liquid. This imposes serious restrictions since liquidations usually involve arbitrageurs. They buy out collateral and immediately sell it elsewhere for a profit.

Due to point 3, implementing soft liquidations seems impossible. Transitioning a CDP to an unhealthy state must trigger the withdrawal of ETH from validators. Returning a CDP to a healthy state requires sending funds back to the validators. All this takes time and operational costs.

How was point 3 solved in Stakewise? Oracles monitor the volume of undercollateralized CDPs on vaults. If a certain threshold of the volume of bad debt on the vault is exceeded, the withdrawal of ETH from vault's validators is initiated. Before ETH comes, the liquidation is impossible (any attempt will lead to a revert). After that the position can be liquidated in a common way. The arbitrager pays the required amount of osETH, receiving an amount of ETH corresponding to the current protocol rate + 1% bonus (taken from the remaining ETH of the unhealthy CDP owner). This solution has a downside of a long delay while the funds are transferred from the validator. Consequently, an unhealthy CDP will hang in the system for days, making the overall collateralization of the protocol worse.

Another possibility is to sell out not ETH but the shares of the vault. So, after the liquidator covers the debt of the bad CDP, the vault shares are transferred from the owner of the bad CDP to the liquidator. The advantage is that the CDP can be liquidated immediately once the position becomes unhealthy. The downside is the limited liquidity of shares. It's difficult to determine the price of a share. On one hand, each amount of shares corresponds to a fixed amount of ETH. On the other, shares of different vaults are backed by different sets of validators. It's possible that shares of a particular vault could lose value significantly after a mass slashing. And again, exiting from validators takes a considerable amount of time. Therefore, the interest in participating in such liquidations is likely to be lower than in common liquidations. For some problematic vaults, a liquidator may not be found at all. So the undercollateralized debt will decrease the overall system collaterization.

To find a liquidator, an auction mechanism can be used. The situation here slightly differs from liquidation in Maker DAO. It's required to cover part of the system's debt in exchange for the collateral of a CDP owner in Maker DAO. It's considered normal if some of the debt remains uncovered. It's later extinguished by other mechanisms: accruing a stability fee, selling MKR tokens, etc. There's no concept of bad debt in Lido. As an option, "dead shares" can be introduced. They belong to no one and cannot be burnt. They dilute the proportion of each user in the total protocol's liquidity. In this case, the auction can be performed in a reverse Dutch form. The volume of vault shares being sold is fixed. The amount of stETH debt that needs to be covered to receive them decreases over time. In other words, the price per share of the vault decreases. The initial amount of stETH required to cover (as in the case of Maker DAO) can be made higher than the debt. This prevents users from triggering the liquidation of their CDP to buy back collateral with a discount. The liquidator who agrees with the current price brings stETH to the protocol and receives shares of the vault. Unredeemed stETH turns into dead shares. Dead shares lead to a negative rebase or to reduction of a positive rebase because the validators' income will likely exceed the growth of bad debt. The main problem with dead shares is that their volume will only increase over time. If the overall liquidity of Lido is growing, then it's fine. The relative amount of dead shares might even decrease. But if stagnation begins or Lido's liquidity decreases, the proportion of dead shares will go up. This will lead to a fall in the overall APR.

As an alternative, a classic English auction can be used. Participants submit absolute values of the desired shares of the vault and the debt to be covered (stETH are transferred at the bid). After repaying the part of the debt, the CDP must return to a healthy state. The winning bid is the one that requires fewer shares of the vault for 1 repaid stETH. The advantages of this option include the ability to liquidate part of the position that is better for the CDP owner. The downsides are that this is an English auction, where the stETH of the current auction leader is locked until the next bid or the end of the auction. Also, as already mentioned, the vault shares have limited liquidity. Therefore, liquidators will include a significant discount in their bids. This means that even repaying the debt in exchange for all shares of the vault may not seem profitable, and the auction might end unsuccessfully. To minimize such situations, it would be necessary to limit the LTV.

There is also another way to resolve the situation with illiquid collateral. The liquidator could be Lido V2 itself. This process can be called internal liquidation. As mentioned in point 1, ETH is the collateral (even with a delayed withdrawal). Unlike regular lending protocols, it can be directly used to generate profit. In most cases, the value of the collateral exceeds the value of the borrowed stETH. The withdrawal address of the validators is controlled by Lido. Fluctuations in the market price of ETH during the withdrawal from the validators are irrelevant for Lido's operations since all internal calculations are conducted in ETH. Consequently, Lido V2 does not face the risks that typical liquidators have due to point 3, and the vast majority of internal liquidations should be profitable. Such a mechanism could provide additional support for the flow of funds into Lido V2.

Let's look at how internal liquidation might work in detail. An oracle (or a keeper for a small reward) monitors the health status of the CDP. Most likely, such a mechanism will be needed for withdrawals anyway, to determine which CDPs to use first. If the health of the CDP crosses the LLTV (Liquidation Loan-To-Value) threshold, the liquidation mechanism is triggered. The amount of debt that needs to be repaid on a one-to-one basis with the collateral is calculated. As a result, the LTV of the position must reach the LLTV - a threshold, to prevent the need to liquidate part of the CDP again shortly thereafter. The calculated debt is deducted from the CDP's debt, and the amount of the debt plus some liquidation penalty is deducted from the collateral. A withdrawal of ETH is initiated from the necessary number of validators in the vault. Once the funds are withdrawn, the liquidated volume of ETH is transferred to the balance of Lido V2. As a result of internal liquidation, the stETH collateral moves from the debt of Lido Vaults to ETH in Lido V2.

The funds received through internal liquidation process can also be used for stETH withdrawals. If there are users in the withdrawal queue, Lido should transfer ETH to them first. If there is anything left after that, the reminder should be sent to the Lido V2 validators. Of course, users do not receive a liquidation bonus during such a withdrawal; it goes to Lido V2 anyway.

The redemption mechanism from Stakewise works as an alternative to withdrawals, offering a sometimes possible (sometimes not) feature to exchange osETH for ETH at the official rate. Since the new architecture of Lido keeps a real one-to-one withdrawal mechanism, redemption becomes an unnecessary complication.

It's important to note that during liquidations, there is a potential for griefing by the user. An attacker could open the smallest possible position in the vault, wait for the ETH to be sent to the validator, and then borrow the maximum amount of stETH. Any penalty on the validator would bring the position to an unhealthy state (even though the vault may be overall overcollateralized), thus triggering a withdrawal of funds from the validator. If the vault has a small number of validators, such a situation could lead to a sudden drop in the vault's APR and potentially a chain of liquidations. To make this less possible, a delayed withdrawal from validators can be implemented. If an unhealthy position appeared, the vault is given some time to increase its current ETH balance, for example, by adding a collateral to some CDP. These ETH would be used for liquidation, and the validators would remain untouched.

One of the corner cases of the internal liquidation that should be examined is a massive slashing event occurred on the vault. As a result, the LTV of individual CDPs will rise above 100%. During internal liquidation, such a CDP will be liquidated entirely. The debt issued by Lido V2 will be removed, and ETH from collateral added to the balance of Lido V2 validators. Therefore, as a result of such liquidation, the collaterization of Lido V2 will slightly decrease. In fact, collaterization will have been decreased even before the liquidation, after the massive slashing. The liquidation in this case just records what has happened and allows it to be reflected through a reduction in the APR growth. In some other liquidation scenarios, such a CDP would just continue to hang, not showing in the system at all.

This section explores how the concepts introduced in the previous "Design" section can be applied and function in real-world scenarios. The goal is to test these concepts for their practical applicability in both well-known and targeted use cases of Lido v3.

Institutional staking can be implemented as permissioned vaults hard-capped on deposits created by Node Operators. Node Operators will be able to decide what stakes are allowed. This feature can be implemented via selling SBTs representing an allowance to stake in a specific vault. Each vault has a limit on ETH deposits caused by Deposit Data (DD) configuration for validator initialization (users cannot deposit more ETH than the vault can use in staking, otherwise, it will negatively affect the vault APR) besides a hard cap on deposits. Vaults managed by a Node Operator are configured with an LTV parameter, which decreases for each vault.

Different LTVs for vaults are chosen based on the cumulative number of validators maintained by a Node Operator. It is important to account for staking penalties risk due to the potentially big amounts of staked ETH. The more ETH is staked with a particular NO, the less LTV parameter should be configured for the future set-up vaults. Such an approach will support protocol solvency and eliminate possible bad debt cases. Also, separating vaults by LTVs and limiting them to the maximum deposited amount will help to protect stakers from being diluted by large deposits, which can lead to LTV reduction and make previously created positions liquidatable.

There is a proposed approach to separate vaults for each specific Node Operator by LTVs - a base vault can be created at the 96% LTV level, which accounts for the initial slashing at 1/32 of the effective validator balance. All other vaults should be created with a lower LTV. LTVs for the consequent vaults can be chosen based on the staking demand and stakers risk appetite. Research on the appropriate LTVs for staked ETH amounts can be found in the "Risk Management" section. So vaults created by a specific Node Operator can be imagined as separate ordered limited boxes with specific LTVs. Allowance to stake at the specific vault can be tokenized using SBTs and sold to the stakers willing to participate.

• DD storage

A deposit data storage can be implemented using Merkle tree roots published in the vault contract. As it was described in the sections above, it will reduce operational costs for Node Operators and make it easier for stakers to validate validators' credentials. Also, Node Operators would be able to seamlessly update the Merkle root with new validator data when needed. Stakers would be able to provide proof of validator deposit data inclusion in the Merkle tree while making the deposit or it can be done by NO at the time of calling the Beacon Chain deposit contract.

• SBTs minting and vaults initialization

As soon as there was deposit data added to the vault contract, it should be configured with a hard cap on deposits and an LTV for minting stETH. As the Node Operator total stake across all controlled vaults grows, newly created vaults should have smaller LTVs than the previous ones due to the increased risk of bigger slashings. The greater the deposit limit, the higher the risk of bigger slashings in case of NO underperforming. A Node Operator should be able to estimate the demand for staking in a specific vault and set an allowance for stakers to enter it. Such allowance can be granted via minting/selling SBTs, which grants an access to its owner to stake in a specific vault with a configured hard cap and LTV. SBT represents an agreement between a Node Operator and a staker so that stakers will beforehand know their deposit cap and LTV.

• Making a deposit

When a user makes a deposit, it should be calculated whether there are enough funds for validator initialization. Assuming there would be a large amount of deposited ETH at a time, it should be matched with the accessible deposit data. If there is an attempt to deposit more ETH than the amount of validators to be initialized multiplied by 32 ETH, then the deposit transaction should revert.

• Taking out and returning the loan and liquidation process

When stakers made their deposits to the vault, they will have vault shares represented by the ERC20 tokens minted to their addresses. The shares amount is calculated as a ratio between the user's deposit and total ETH controlled by the vault multiplied by the total existing shares amount. The amount of stETH that can be minted is calculated using the vault LTV and the users' share in that vault.

stETH minting can be allowed at the time when users' deposits were sent to the Beacon Chain staking contract. This can be ensured when the deposit() function was called by a Node Operator or triggered by a user deposit if there is enough funds to initialize a new validator. It will allow vaults to determine a maximum amount of stETH to be minted according to the configured LTV for that vault. The amount of minted stETH should be written to the position info to determine the position's health in the future.

Users should also be able to bring back their stETH to redeem previously deposited ETH. A redeemable amount of ETH can be calculated using the sum of execution and consensus layer balances reported by an oracle. The process of publishing those values using Merkle tree roots was described in the sections above.

A liquidation process can be started for a position if it becomes unhealthy, it can happen if an oracle reports a reduced balance on EL + CL and the user has to have a position with an LTV higher than it is set in the vault. It means that the user's outstanding loans in stETH can be repaid to make their position healthy again. A special period of time should be set for positions that became unhealthy, but not liquidatable yet. It will give stakers enough time to bring back their stETH to the vault or deposit more ETH to make their position healthy in case of a reduced CL + EL balance reported by the oracle. Such an approach will make users' positions safer and reduce operational costs on the potential validators' exits triggered by a position liquidation.

• Reducing (or increasing) LTV with rewards coming to the vault

After the user creates a position by providing ETH as collateral and mints stETH, their position LTV will change with every oracle report. As soon as the underlying amount of ETH increases, the user's LTV will drop, making their position healthier. In case of any slashing or balance reduction, an individual user's LTV will rise to make their position closer to vaults LTV and possibly subject to liquidation.

• Validators exiting

Exit messages to validators can be sent after liquidation events when there is a need to withdraw underlying ETH to the execution layer to be paid to the liquidator when they have repaid an unhealthy stETH debt. It can be implemented using a proposed EIP-7002 so that there is no need for a Node Operator to take action. The vault contract as a withdrawal target set in the validator credentials is able to trigger the validator exit at the end of the liquidation event. It should be checked if that exit should be triggered or there is enough ETH in the vault contract to be paid to the liquidator. The same process should be implemented on the stETH burning - underlying ETH deposited to validators can be withdrawn using an exit message sent to the consensus layer. Also, there is still a Node Operator right to manually trigger the validator exit which will also lead to the validator stake being withdrawn to the vault contract.

CDP owners in the new protocol version can use leverage staking to maximize profit by increasing risks. To create a leveraged position manually a staker exchanges borrowed stETH for ETH, reinvests them in a vault, borrows more stETH and so on. stETH can be exchanged for ETH using either lending protocols (such as AAVE) or the built-in withdrawal mechanism in Lido. Leveraging can also be done by exchanging stETH for ETH through a DEX, but this method is not considered due to fund loss because of swap fees during each exchange.

If AAVE v3 is used, a staker borrows stETH in Lido Vaults and wraps the tokens into wstETH (AAVE v3 uses the wrapped version). wstETH are deposited as collateral into AAVE to borrow more ETH. Since wstETH and ETH are similar assets, AAVE provides a high LLTV (currently 93%). The interest rate on the borrowed ETH is approximately equal to the wstETH exchange rate growth at the moment, so it has additional negative impact on the leveraged APR (it reduces because part of the leveraged rewards will be lost by paying interest on borrowed Eth). However, if AAVE is widely used for leverage staking in Lido Vaults, the dynamic borrow rate on ETH may increase. The advantage of this method is the instant creation of leverage. The disadvantage is the risk of rising an interest rate on borrowed ETH, leading to liquidation in AAVE and the loss of funds. Therefore, stakers using this approach must monitor their CDP in both protocols. The LLTV in AAVE is not 100%, so the leverage size is more limited.

The withdrawal mechanism in the new protocol can be also used for leveraging positions. 100% of stETH borrowed through Lido Vaults is converted to ETH at a 1:1 ratio, then added to the user's CDP collateral. Converting stETH to ETH takes time as it may need to be withdrawn from a validator (around 4-5 days). To create a leveraged position this operation must be repeated several times. While stETH is in the withdrawal queue, the user's balance does not grow during rebases. But the borrow rate continues to accrue, affecting the actual APR.

Let's calculate how a user's income changes using AAVE for leverage staking, assuming reinvestment of stETH into the vault 5 times. For simplicity, let's assume the LLTV in AAVE for the wstETH/ETH pair is 90%, the APR of Lido V2 is 5%, the borrow rate for ETH in AAVE is 5%, the supply rate for wstETH in AAVE is 0%, and the LLTV of the vault is 70%.

The table shows how the actual APR changes for a leveraged position. If the APR of Lido V2 exceeds by 1%, the actual APR increases by 1.25 times. If it's 1% less than the APR of Lido V2, the actual APR decreases by 1.6 times. Furthermore, in the second case the LTV of the position gradually approaches the LLTV. So, both risks and potential profit are increased.

Leveraging of positions will probably actively use the withdrawal mechanism. If a withdrawal relies solely on Lido V2, liquidity from the protocol will flow to high-yield vaults with high risk. As noted in other sections, Lido V2 is the foundation of the new protocol: all stETH for Lido Vaults are actually borrowed from Lido V2. Therefore, it's crucial for a withdrawal to use not only Lido V2 but also CDPs from Lido Vaults. Additionally, it's important to note that a normal position and a leveraged position look the same for Lido Vaults. If the withdrawal mechanism uses CDPs with the highest LTV, the same position can be chosen for a withdrawal, when creating a leverage. One of the solutions to bypass it is to give users time to improve the position's LTV by depositing more ETH before the CDP is actually used for a withdrawal.

At the moment it's difficult to predict how the active use of leverage will affect the new version of Lido. Using external protocols (such as AAVE) will lead to additional ETH being sent to the protocol's validators, which is undoubtedly a benefit. However, the dynamic borrow rate for ETH on popular lending protocols is likely to increase if these protocols are heavily used for a leverage. While the fees might exceed potential profit. The disadvantages of a leverage are more apparent. If a dynamic mechanism for selecting the source for the withdrawal is used, part of the withdrawal funds will come from Lido V2 and part from Lido Vaults. Leverage staking only makes sense for stakers in Lido Vaults. Consequently, some funds will flow from Lido V2 to Lido Vaults. As a result, Lido V2 will always have the minimum allowable part of the entire protocol's liquidity. Furthermore, leverage staking is most beneficial in the highest-yielding and riskiest vaults. Therefore, liquidity will shift from small lower-yield vaults to huge higher-yield vaults, leading to centralization. Leverage staking, in any case, makes CDPs more sensitive to APR fluctuations. In high-risk vaults, these fluctuations are stronger, which could affect the overall reliability of the protocol.

It's impossible to prohibit leverage staking if stETH remains a redeemable LST. Thus, an existence of leverage staking must be considered in all aspects of the protocol's architecture.

If leverage staking by withdrawal is an inevitable mechanic of the new protocol version, perhaps it should be made more convenient? Since funds are redistributed inside the protocol, it's possible to add a feature that allows multiple combinations of stETH borrowing, withdrawal, and increasing the vault position in several transactions. This would involve calculating the total amount of stETH to be borrowed and the total user's position in ETH. Since funds for a leveraged position will be moved from Lido V2/other vaults into the current vault, a withdrawal operation for the total position amount needs to be initiated.

Since the ETH deposited with leverage in the vault will only arrive after some time (several days or more), it makes sense to maintain a separate pending queue for such CDPs. Once the ETH arrives at the withdrawal address, the user finalizes the operation, receiving shares and an increased amount of borrowed stETH (without actual minting of them). There are many nuances to this approach. Firstly, the withdrawal function needs to be expanded for such operations. Secondly, these ETH need to be frozen for a while to prevent them from being sent back to validators or used in other withdrawals. Also, what if a user initiates a leveraged position creation, but by the time the funds arrive, the LTV in the vault has decreased and the position will not be healthy after finalization? In this case, it might be necessary to roll back the position creation and return the funds to validators (or use them for other withdrawals).

Another important aspect is the implicit commission at withdrawal. If a leveraged position is created manually, the user loses some rewards on each withdrawal operation during the process. In the case of automated creation, the user avoids this commission. One option is to record the full debt in stETH at the initiation of the leveraged position creation. However, this issues under-collateralized stETH (since their backing has not yet been withdrawn from Lido V2/other vaults and still used as backing for other stETH). A more rational strategy seems to be adding a commission to the user's stETH debt during the finalization of CDP's creation (possibly a slightly smaller fee than the total losses when creating manually). A leveraged position adds additional risk to the protocol, as described above, but offers the user the opportunity to significantly increase income. Therefore, such a commission seems fair.

The "Bring Your Own Validator" (BYOV) alternative design for Lido v3 presents a scalable, flexible, and decentralized approach to liquid staking, addressing the limitations of the current LST model while preserving Ethereum network security and validator decentralization. By introducing customizable vaults, institutional stakers, restakers, and node operators gain greater control over their risk-reward structures, ensuring efficient capital allocation without compromising protocol integrity.

A key priority remains maintaining stETH as a Liquid Staking Token (LST) rather than transitioning into a purely synthetic asset, safeguarding redemption guarantees and preserving trust within the DeFi ecosystem. The modular vault structure enhances staking accessibility while ensuring Lido v2 continues operating as a liquidity buffer, balancing yield optimization and protocol security.

As Ethereum staking demand evolves, Lido v3, with its vault-based architecture, provides a future-proof solution for institutional and retail stakers alike. By aligning incentives, reducing centralization risks, and fostering capital efficiency, this design solidifies Lido’s position as the leading liquid staking protocol, setting a new standard for sustainable and decentralized staking in DeFi.