---
title: Lido Staking Vaults (stVaults) Technical Design and Architecture
tags: Vaults
---

# Lido Staking Vaults (stVaults): Technical Design and Architecture

> **Disclaimer!**
>
> This is a living **Work-in-Progress** draft of the Lido stVaults technical design document. It outlines the core design principles, architecture, and mechanics at a high level.
>
> It's not a product specification or goals document—though those are briefly referenced for context. Detailed technical reference materials will follow in subsequent documents.

## 1. Abstract

Lido Staking Vaults (stVaults) are modular primitives that connect stakers, node operators, and protocols—enabling them to define custom fee structures, tailor validator configurations, and fine-tune risk/reward. This flexibility is achieved without compromising decentralization, security, or access to stETH liquidity.

## 2. Design

### 2.1 Goals
StVaults are designed to:
1. Enable customizable risk-reward profiles for liquid staking while preserving stETH's stability and fungibility.
2. Improve alignment with node operators who wish to onboard clients and actively participate in the Lido protocol.
3. Support the development of structured staking products and deeper protocol integrations.

These goals are built on the vision outlined in [Hasu's 2nd GOOSE voted-in proposal](https://snapshot.box/#/s:lido-snapshot.eth/proposal/0xeedef9fea3d782f192410768cabaf6974da40ef36e1d22c7f8fff5fd4cfc7a59), establishing a foundational layer for diverse staking product lines.

### 2.2 Principles

The introduction of stVaults brings major changes to the existing Lido protocol contracts (hereafter referred to as **Lido Core**). To ensure protocol stability, it's essential to define the foundational constraints that remain unchanged:

1. StVaults users don't negatively affect stETH users:
a. StVaults don't negatively affect stETH user APR
b. Slashing risk consequences are contained within vaults up to the level agreed by the DAO
2. StVaults have a set reserve ratio that determines the quantity of stETH that can be minted based on ETH provided, and that can only be changed by the DAO
3. The impact of possible reallocation of stake between Lido Core and stVaults is contained and manageable
4. StETH solvency - all existing stETH can be converted into ETH at a 1:1 ratio

So, it remains the key priority to maintain the stability and security of the Lido Core and the whole Lido staking infrastructure.

## 3. Architecture

To balance protocol safety with design agility, the architecture is layered into two domains:
- **Essential Layer**: The foundational and rigorously governed contracts that secure the relationship between Lido Core and the Lido Vaults platform:
- StakingVault,
- VaultHub,
- AccountingOracle v3,
- OperatorGrid,
- PredepositGuarantee.
- **Utility Layer**: Optional, composable components that extend the essentials with richer user experience and integrations—without compromising foundational safety:
- VaultFactory
- Dashboard

### 3.1.1 Essentials: StakingVault

The StakingVault contract is a fundamental building block of the Lido Vaults platform. It represents an isolated staking position managed by a single **owner** and serviced by a single **node operator**. On its own, a StakingVault is an independent delegated staking solution. When connected to Lido, the StakingVault's **totalValue** (the sum of validator balances plus contract balance) can be used as collateral for minting stETH.

With a StakingVault, the owner can:
- Stake their funds directly with their preferred node operator without giving up the custody;
- Tap into various block proposing and validation flavors,
- Mint stETH backed by the StakingVault's `totalValue`; and
- Build structured products by integrating protocols and risk curators.


#### State

Each StakingVault has two important parameters that define its state and determine its lifecycle: **totalValue** and **locked**.

- `totalValue`: The estimated total of all the vault's validator balances plus any ETH held by the vault contract itself.
- `locked`: The amount of ETH on this vault that is _blocked_ from withdrawal. This amount backs the stETH tokens minted via this stVault.

> **EIP-6110 and `totalValue` Calculation**
> `totalValue` includes both active and pending validators on the consensus layer. Thanks to [Pectra's EIP-6110](https://eips.ethereum.org/EIPS/eip-6110), pending validators that have been deposited but aren't yet active are now visible to the CL protocol right in the same block (mind epoch finalization still apply for the off-chain software). This eliminates the accounting blind spot where funds have left the vault contract but haven't yet appeared on the active validators on the consensus layer, ensuring coherent collateralization for all minted stETH.

If `locked > totalValue`, the StakingVault cannot:
- mint stETH
- withdraw ETH
- deposit new validators
- trigger partial validator withdrawals.

To control stETH minting, `VaultHub` tracks these parameters for each stVault:

- **liabilityShares**: The current amount of stETH shares minted on behalf of the vault (liability towards Lido Core).
- **reserveRatio** (**RR**): The percentage of the vault's collateral that is locked as an additional reserve (safety buffer) for minted stETH (e.g., if `reserveRatio` is 30%, 100 ETH in the vault can back only 70 stETH).
- **forcedRebalanceThreshold**: The minimum percentage of the vault's totalValue that must remain locked to avoid _force rebalancing_. The invariant is `forcedRebalanceThreshold < reserveRatio`.
- **shareLimit**: The absolute flat cap on stETH shares that a stVault can mint.

*Diagram. Vault totalValue breakdown*

#### Liquidity

Unlike Lido Core, which mints stETH at a 1:1 ratio to supplied ether, Lido Vaults mints stETH at a more conservative ratio. A lower ratio effectively means that the StakingVault must maintain a reserve margin (**Reserve Ratio** or **RR**) determined by risk parameters and limits.

To mint stETH, the owner must **lock** the corresponding amount of ether (plus some reserve due to RR) as collateral on the StakingVault. The system tracks [stETH shares](https://docs.lido.fi/guides/lido-tokens-integration-guide#steth-internals-share-mechanics) (**liabilityShares**) minted for each StakingVault and updates the **locked** amount (denominated in ether) on the StakingVault according to the stETH rebase (with the same rate plus fees). To unlock ether for withdrawal, the StakingVault must burn the outstanding amount of stETH (i.e., repay stETH) and wait for the report to reset the liabilityShares counter.

**StakingVault source code**: https://github.com/lidofinance/core/blob/feat/vaults/contracts/0.8.25/vaults/StakingVault.sol

### 3.1.2 Essentials: VaultHub

VaultHub acts as the central registry for all StakingVaults in the Lido protocol. It manages "sockets" that track each vault's parameters, including liability shares, share limits, reserve ratios, Lido fees, and forced rebalance thresholds. The contract enforces protocol invariants and ensures that only authorized vaults with approved proxy implementations can connect to the system. VaultHub also interfaces with OperatorGrid to propagate stETH minting limits to individual vaults.

The main functions of VaultHub include processing vault connections and disconnections, minting and burning stETH backed by vaults, accepting Oracle reports, and handling rebalancing operations. When a vault's health drops below the forced rebalance threshold, VaultHub enables permissionless rebalancing and can trigger validator exits if necessary.

VaultHub uses a lazy oracle mechanism where a Merkle root represents the global state of all vaults, with individual vault states updated on-demand via proofs. This approach scales efficiently with many vaults. Share limits are enforced at both individual vault level, preventing concentration risk. For users, VaultHub is the primary gateway for all stETH minting operations and ensures proper collateralization throughout the system.

*Diagram. VaultHub interactions*

VaultHub source code: https://github.com/lidofinance/core/blob/feat/vaults/contracts/0.8.25/vaults/VaultHub.sol

### 3.1.3 Essentials: AccountingOracle v3

> Accounting Oracle v3 is the new iteration of the Lido Accounting Oracle, which includes the existing Accounting Oracle v2, which is employed for reporting Lido Core updates, and an additional extension for Lido Vaults.

The Lido Vaults platform employs a "lazy oracle" mechanism to efficiently handle state updates across potentially thousands of individual vaults. Rather than updating each vault's state in a single transaction—which would be prohibitively expensive in terms of gas costs—the system uses a Merkle tree-based approach where only the root hash representing the global state is stored and updated daily by the AccountingOracle v3 as a part of the main accounting protocol report.

Individual vault updates happen on-demand by providing Merkle proofs verifying a specific vault's data against the stored root. When a vault's data needs updating, anyone can submit the proof along with the vault's latest `totalValue`, `inOutDelta`, `treasuryFee`, and `liabilityShares`. The system verifies this data against the Merkle root and, if valid, updates the vault's state and forwards the relevant information to the StakingVault contract. The protocol defines clear freshness requirements—some critical operations, like withdrawals, require up-to-date reports, while others, like funding, can proceed with older data.

There is no separate contract for this lazy oracle concept, but rather, its functionality is spread over Accounting and VaultHub.

Accounting source code: https://github.com/lidofinance/core/blob/feat/vaults/contracts/0.8.25/Accounting.sol

VaultHub source code: https://github.com/lidofinance/core/blob/feat/vaults/contracts/0.8.25/vaults/VaultHub.sol

### 3.1.4 Essentials: OperatorGrid

The OperatorGrid contract controls mint parameters of vaults connected to the Lido protocol. Its primary purpose is to organize vaults into groups of tiers with specific stETH minting limits while ensuring no single node operator can service a disproportionate amount of stETH.

A **group** represents a node operator. Each group has a total shareLimit that caps the total stETH shares that can be minted across all of the operator's vaults. A group contains one or more tiers. Groups track their liability shares (total shares minted by all vaults in the group).

A **tier** represents a set of minting parameters. Each tier belongs to a specific node operator group (except the default tier). Each tier has its share limit, reserve ratio, forced rebalance threshold, and Lido fee. Tiers track their liability shares (minted by vaults in that tier).

OperatorGrid source code: https://github.com/lidofinance/core/blob/feat/vaults/contracts/0.8.25/vaults/OperatorGrid.sol

#### Default Tier

All vaults start in the default tier. The default tier has no specific node operator group. It has its stETH minting limits defined at initialization. Vaults in the default tier don't contribute to any operator group's liability. When a vault moves from the default tier to an operator tier, its shares are added to that operator's group liability.

A new vault is placed in the default tier even if the vault node operator has a registered group. The vault owner must explicitly request to join one of the node operator tiers, and the latter must also approve the request.

#### Tier Parameters

Each tier defines critical parameters that control a vault's stETH minting capacity:
- **share limit**: the number of stETH shares that can be minted by all vaults in this tier,
- **reserve ratio**: how much ETH must be reserved for each stETH minted,
- **forced rebalance threshold**: a threshold for forced rebalancing,
- **Lido fee**: the fee percentage charged to the Lido treasury.

These parameters are propagated to VaultHub when a vault connects or changes tier.

Diagram. An example group with a 100k limit and three tiers

### 3.1.5 Essentials: PredepositGuarantee

To prevent the [deposit frontrunning exploit](https://medium.com/immunefi/rocketpool-lido-frontrunning-bug-fix-postmortem-e701f26d7971), the StakingVault enforces a predeposit-and-verify mechanism. Node operators cannot directly deposit locked assets backing stETH into the beacon chain. Instead, they must use the `PredepositGuarantee` (PDG) contract, which requires node operators to post an equivalent guarantee amount.

Through PDG, node operators make 1 ETH predeposits and lock a matching guarantee. They must then provide proof of correct withdrawal credentials using [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788) beacon block roots, which unlocks their guarantee. Only after verification can they make full deposits to these validators.

> 💡 For unlocked ETH not backing any stETH, vault owners can opt for a simplified "PDG shortcut" (see below) flow that bypasses the guarantee requirement. This easier method assumes trust between the vault owner and node operator (potentially backed by off-chain legal agreements), as the node operator could technically frontrun these deposits. In this flow, any theft would only impact the vault owner.

*Diagram. Node operator deposit happy path*

The complete flow of the stVault's validator deposit is as follows:
1. The node operator locks a `1 ether` on the `PredepositGuarantee` contract as a guarantee.
2. Node operator then must submit a minimal deposit of `1 ether` using the StakingVault funds through the same `PredepositGuarantee` contract.
3. Once the validator appears on the beacon chain, the node operator generates the proof of valid withdrawal credentials and submits it to the `PredepositGuarantee`, unlocking their bonded `1 ether`.
4. The node operator may then make full, uncapped deposits to validators whose withdrawal credentials have been validated through the `PredepositGuarantee` contract.
5. If a validator's withdrawal credentials are proven invalid (i.e., they do not match the StakingVault withdrawal credentials), the vault owner may withdraw the provided bonded ether.

*Diagram. Proven validator deposit flow*

> **Important to know!**
> - Node operator guarantee can come from a dedicated guarantor account (which trusts the operator).
> - The **1 ETH guarantee** from the operator or guarantor **stays** in the `PredepositGuarantee` contract; **only stVault ETH** ever goes to the validator.
> - StakingVaults support Pectra's [EIP-7251 `MAX_EB`](https://eips.ethereum.org/EIPS/eip-7251) right away, so `1 ETH` is enough to deploy a 2048-ETH validator.
> - The steps listed above are not separate transactions. All of them can be conducted in just two transactions.
> - One can sequentially reuse the same posted 1 ETH guarantee to set up and prove multiple validators for the same operator.
> - The contract supports batched operations.

##### Onchain BLS12-381 signature verification

The predeposit operation must include a valid BLS12-381 signature to pass on-chain verification using the precompiles introduced in [EIP-2537](https://eips.ethereum.org/EIPS/eip-2537). This is why the transaction must also carry the necessary signature transformation data. Signature verification is essential—it ensures that the predeposit is a legitimate deposit and a validator with the specified pubkey will eventually appear the consensus layer. This will make it possible to generate the presense proof for the validator and its withdrawal crendentials.

##### Proving unknown validators

The Lido protocol supports direct deposits to the deposit contract and validator consolidations targeting vault-associated validators. To handle such cases, PDG includes a special method for proving the withdrawal credentials of _side_ or _consolidated_ validators—those that either bypassed the standard predeposit flow or were later merged into a vault's validator set.

This method allows these validators to be cleared in PDG without going through the predeposit process. However, the balance of such validators is excluded from the vault's `totalValue` until it is acknowledged via the oracle report.

*Diagram. Proving unknown validator to PDG*

PredepositGuarantee source code: https://github.com/lidofinance/core/blob/predeposit-guardian/contracts/0.8.25/vaults/predeposit_guarantee/PredepositGuarantee.sol

### 3.2.1 Utilities: Dashboard

Dashboard is a utility extension for StakingVault and deals with:
- Granular role-based access control to the StakingVault operations,
- Management and claiming of the node operator fee,
- PDG predeposit bypass,
- UX-friendly methods and various token helpers.

> While technically optional, Dashboard is highly recommended for easier operational management of StakingVaults. Without Dashboard, Lido's web interface and CLI utilities **will not function**. Vault owners who choose to operate without Dashboard should possess strong technical knowledge of the underlying contracts and be prepared to manage their vault through raw transaction calls. For most users, Dashboard provides essential quality-of-life improvements that significantly reduce operational complexity when managing validators and stETH minting operations.
>
#### Architecture

StakingVault is a minimal staking primitive that manages only immediate staking operations and tracks its totalValue and locked ether. It implements a simple single-owner model. Dashboard is optional and plugs into a StakingVault by taking over its ownership while the actual vault admin becomes the admin of the `Dashboard` contract.

*Diagram. Dashboard access control model*


#### Roles

With Dashboard, every operation in the StakingVault requires the respective role. For example, funding the StakingVault requires that the sender has the `FUND_ROLE`. All of these roles have their [role admin](https://docs.openzeppelin.com/contracts/5.x/api/access#AccessControl-_setRoleAdmin-bytes32-bytes32-).

*Diagram. Role-restricted operations*


> **Important to know!**
>
> - The `Dashboard` contract includes functions for batch-granting and batch-revoking roles;
> - Some operations (like rebalance) can be pre-funded if ether is > attached to the transaction and the sender has `FUND_ROLE`.

Dashboard implements an **autolock mechanism** that automatically increases the locked amount when minting stETH to ensure proper collateralization. Without this feature, users would need to manually calculate and lock the correct amount before the mint operation, risking transaction failures if the locked amount is insufficient.

The autolock feature requires the sender to also have the `LOCK_ROLE`, otherwise the transaction will revert. This deliberate design prevents accidental lock increases by requiring explicit role authorization.

#### Multi-role confirmation

The multi-role confirmation mechanism restricts some administrative actions, thus preventing unilateral decisions. This means that a member of each of the required roles must send the transaction with the same parameters within a configurable duration (lifetime).

*Diagram. Example of a multi-role confirmation process*


#### Node operator fee

The StakingVault intentionally does not include any accounting for extraneous fees (e.g., node operator, reward share) to allow for flexibility in different setups. Instead, this logic was implemented in `Dashboard` with room for configuration. Dashboard includes the Node operator manager role which is granted to an address representing node operator's interests.

The node operator fee calculation is as follows:
1. Calculate the total rewards
$$ r = V_{l} - V_{c} - δ_{l} - δ_{c} - A
$$
Where:
- $r$ is the total rewards,
- $V_{l}$ is the vault totalValue at the last report,
- $V_{c}$ is the vault totalValue when the fee was last claimed,
- $δ_{l}$ is the in-out delta at the last report,
- $δ_{c}$ is the in-out delta when the fee was last claimed,
- $A$ is the rewards adjustment (see PDG bypass and rewards adjustment section below)

2. Multiply the total rewards by the fee percentage. If $r$ is zero or less, the accumulated fee will be zero.
$$
{f} =
\begin{cases}
\displaystyle
{r \times F}, & r > 0, \\
0, & \text{otherwise}.
\end{cases}
$$
where $f$ is the accumulated fee, $F$ is the normalized fee percent and satisfies $0\leq F \leq1$.

> **Important to know!**
> - Before setting a new fee, the accumulated fee must be claimed. Otherwise, the transaction will revert;
> - Fee percentages are represented in basis points, with 1 point equivalent to 0.01% and 10000 to 100%.
##### PDG bypass and rewards adjustment

The Dashboard contract provides a shortcut flow for node operators, allowing them to perform deposits that bypass the standard PDG predeposit process—specifically, skipping the 1 ETH guarantee requirement and BLS signature verification. This path is intended for situations where the vault owner trusts the node operator not to frontrun deposits, or where a formal legal agreement governs the arrangement.

These _unguaranteed deposits_ are executed by withdrawing ETH from the vault (excluding the locked portion) and making the deposits to the Ethereum deposit contract directly, without routing the transaction through PDG. As a result, the vault's `totalValue` is reduced by the deposit amount, and the protocol assumes no risk associated with the deposit.

This shortcut flow automatically adjusts the vault's node operator fee accounting by updating the rewards adjustment. The associated validator is excluded from reward calculations, so the node operator only receives rewards actually earned—not a share of the full validator balance. Once the validator becomes active, its withdrawal credentials can be proven using PDG's "unknown validator" proving method. After being proven, the validator can receive top-up deposits through the standard PDG flow.

*Diagram. PDG shortcut*

Other scenarios—such as validator consolidation or direct deposits made to the deposit contract without passing through the vault—can also result in vault-affiliated validators receiving new stake. To ensure accurate reward attribution in these cases, the node operator can manually update the rewards adjustment in the Dashboard contract.

### 3.2.2 Utilities: VaultFactory

The VaultFactory contract offers a smooth, one-transaction approach to creating and configuring a StakingVault with Dashboard. This factory automates a complex setup process that would otherwise require multiple separate transactions (See Flows: Connecting and Disconnecting).

The factory performs the following sequence of operations:
- deploys a StakingVault proxy
- deploys a Dashboard clone,
- initializes both contracts with specified parameters,
- optionally configures initial permissions,
- sets up the **connect deposit of 1 ETH**
- authorizes the VaultHub
- requests connection to the vault to VaultHub.

This approach reduces the number of transactions required for vault setup, minimizes configuration errors, and ensures proper authorization from the moment of creation.

#### 1 ETH Connect Deposit

The creation function is payable and requires at least 1 ETH to be sent during the call. This mandatory connect deposit functions as an anti-sybil mechanism that prevents the creation of spam vaults that would burden the oracle network. The factory verifies sufficient ETH was provided before proceeding with vault creation, locks this deposit during setup, and remains locked for the duration of the vault's connection to VaultHub.

## 4. Flows

#### Staking and Unstaking


1. **Funding**
- The _vault owner_ calls `fund()` to send ETH to the stVault.
- Increases the vault's `totalValue`.

2. **Depositing Validators**
- The _node operator_ sends deposits via _predeposit guarantee_ to create or top up a validator.
- Can be done in batches.
- Uses `0x02` withdrawal credentials pointing to the vault's address.
- Does not change `totalValue`.
- Reverts if `locked > totalValue`.

3. **Receiving EL and CL validation rewards**
- Validator fee recipient can be set to the vault address.
- Although increasing the vault's balance is not reflected in `totalValue` until updated with a report

4. **Exiting Validators**
- The _vault owner_ can call `requestValidatorExits()` to ask for a voluntary exit.
- The _node operator_, _vault owner_, or `VaultHub` (under extreme conditions) can call `triggerValidatorWithdrawal()` to perform [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) "triggerable withdrawal".
- Once exited, the validator's balance is transferred to the vault.
- Partial withdrawals may also be requested.

5. **Withdrawing**
- The _vault owner_ calls `withdraw()` to take out any amount of **unlocked** ETH (i.e., `totalValue - locked`) from the vault's balance.
- Exiting validators or partial withdrawals are necessary to withdraw staked ETH.

#### Accessing stETH

1. **Minting**


- The *vault owner* calls `lock()` on the vault and thus locks ether on the vault.
- The _vault owner_ calls `mint()` on the `VaultHub` to mint stETH up to the amount coverable by the locked ether (including RR).
- Increases the vault's `liabilityShares`.
- The minting capacity is limited by current `totalValue`, `liabilityShares`, `shareLimit`, and `reserveRatio`.

2. **Burning**


- The _vault owner_ calls `burn()` on the `VaultHub` to burn stETH on behalf of the vault.
- Decreases the vault's `liabilityShares`.
- The `locked` amount gets reduced with the next proven update.

3. **Rebalancing**

- Reduces both `liabilityShares` and `totalValue` simultaneously by taking ETH from the vault, submitting it 1:1 for stETH via Lido Core, and then burning it on behalf of the vault.
- Improves vault health at the cost of reducing its totalValue.
- Requires validators to be exited or partially withdrawn if staked ETH is intended to be used.
- Can be performed by the _vault owner_ or executed permissionlessly if the vault's `forcedRebalanceThreshold` is breached.

#### Connecting and Disconnecting

Each staking vault can operate independently as a basic delegated staking setup. However, to enable stETH minting, it must be connected to the Lido VaultHub—a central contract that manages vault registry and controls minting.

**Connection Process:**
1. **Authorization:** The vault owner explicitly authorizes VaultHub to interact with the vault—to submit reports and trigger force rebalancing.
2. **Locking ether:** The owner funds and locks 1 ETH in the vault. This lock acts as a Sybil-resistance mechanism, discouraging spam creation of empty vaults that would otherwise burden oracles.
4. **Creating a socket in VaultHub**: Then the vault owner calls the connect function in VaultHub creating a socketm, i.e. a storage space for the vault state. All the vault parameters (share limits, reserve ratio, forced rebalance threshold, treasury fee) are retrieved from OperatorGrid (using the default tier for unregistered vaults).
5. **Report Confirmation:** The following report finalizes the connection by updating the vault's totalValue, including both execution layer (EL) and consensus layer (CL) balances.

> It is highly recommended to use VaultFactory rather than attempting a manual vault connection. As evident from the multi-step connection process, manual setup requires precise sequencing of authorization, funding, locking, and connection operations. The VaultFactory eliminates these potential points of failure by automating the entire process in a single atomic transaction. This significantly reduces the risk of configuration errors or incomplete setup that could lead to operational issues or security vulnerabilities.

**Disconnection Process:**

1. **Burn Outstanding stETH:** The vault owner must fully burn any stETH still backed by the vault.
2. **Request Disconnection:** The owner calls the disconnect function on VaultHub, flagging the vault for removal.
3. **Report Confirmation:** The disconnection is finalized during the next VaultHub report—the vault is removed from the sockets array. NB: the vault is not removed from its tier in OperatorGrid. If it chooses to connect again, it retains its tier parameters.
4. **Revoke Authorization:** The vault owner can now safely deauthorize VaultHub from interacting with the vault.

#### OperatorGrid Tier change

All vaults are initially placed into the default tier in OperatorGrid, which means all vaults have the same individual share limits, reserve ratio, forced rebalance threshold, treasury fee and a shared total limit of shares. However, the vault can change the tier by joining a NodeOperator group with custom parameters set by the Lido DAO.

Step-by-step process:
1. **Tier change request**: the vault owner requests a tier change in OperatorGrid. The requested tier must belong to the node operator set in the vault.
2. **Node operator approval**: The node operator approves the tier change request. Now the vault is operating under the new params.

#### Vault Ossification

Staking vaults are deployed using a custom BeaconProxy pattern. Disconnecting a vault from the VaultHub does **not** prevent it from receiving future upgrades via the beacon controlled by the Lido DAO.

To permanently freeze the vault's logic and reject any future upgrades, the vault owner can _ossify_ it—by pinning the current implementation address in the proxy. This ossification can only be performed **after** the vault has been fully disconnected from VaultHub.

#### Accounting

Each vault's accounting state is updated individually and permissionlessly using a Merkle proof. Once per day, the AccountingOracle submits a new Merkle root representing the global state of vaults. After this submission, each vault must be updated separately by providing its corresponding data and Merkle proof tied to that specific root update.

The individual vault update does the following:

1. **Updates `totalValue`**
- Reflects the changes of the vault's ether balances, staked or unstaked.
- Required to confirm that stETH minted is sufficiently backed (including RR).

> **NOTE**: The precise and immediate totalValue $V_{precise}$ of the vault on the given block can be presented as:
> $$ V_{precise} = CL_{balance}+ EL_{balance} $$
> where $CL_{balance}$ is the sum of all validator's balances that have withdrawal credentials set to the vault, and $EL_{balance}$ is the balance of the vault contract itself.
>
> However, validators' balances are not immediately available on the execution layer, which makes the Oracle totalValue inherently out of sync, although one can estimate it:
>
> $$ V = V_i + δ - δ_i + (X_i) $$
>
> where:
> - $V_i$ is vault's totalValue brought in the _i_ the Oracle report
> - $δ$ is the difference between cumulative deposits to and cumulative withdrawals from the vault stored in the contract
> - $δ_i$ is the difference at the _i_ Oracle report slot
> - $X_i$ is the unknown difference of the vault's CL balance accumulated since the _I_ the Oracle report. In this model, we assume that the _reserveRatio_ is chosen so that _reserve_ covers $X_i$ if it's negative and prevents minted stETH insolvency.
> Therefore, the `totalValue` of the vault can be calculated as:
> $$ V = V_i + δ - δ_i $$
> given that `reserveRatio` is chosen accordingly to prevent negative discrepancies from influencing stETH holders' risk profile.

2. **Adjusts `locked`**
- `locked` ETH grows as minted shares appreciate from stETH positive rebasing.
- `locked` ETH decreases if `stETH` was burned prior to the current Oracle report and/or stETH negative rebasing.

3. **Collects Lido protocol treasury fees**
- They are minted as stETH on the treasury address on behalf of the charged vault, increasing the `sharesMinted` value for that vault.

#### Forced rebalancing

A cornerstone principle of stVaults design is:
> stETH solvency - all stETH existing could be converted into ETH at a 1:1 ratio

Thus, each vault must remain solvent, preventing any vault-specific losses from spilling over to stETH holders. The mechanism to enforce this is called _forced rebalancing_:

- Triggered when the vault's _reserve_ for minted stETH falls below its `reserveRatioThreshold` (e.g., due to slashing or prolonged penalties).
- Comprises two parts:
1. **Forced Validator Withdrawals** (permissionless, via [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002)).
2. **Forced Rebalance** (permissionless rebalancing using available vault unstaked ETH).
- Once triggered, no further deposits or withdrawals are allowed until the vault's health is restored.
- The maximum rebalancing amount \(X\) satisfies:
$$
\frac{(mintedShares - X)}{(totalValue - X)} = 1 - RR
$$

## 5. Risks

Stakers and ecosystem participants are advised to carefully consider these risks and conduct their own research before participating in stVaults.

### 5.1 Ecosystem risks

1. Stake concentration: Mitigated through stVault permissionless creation, risk parameters, and limits, balancing for a diverse node operator participation.
2. Token insolvency: Addressed via risk parameters to maintain a reasonable reserve margin for minted stETH alongside local and global limits for the max mintable stETH through the stVaults.

### 5.2 Risks for stVaults stakers

1. Deposit Frontrunning: Mitigated through the PredepositGuarantee module.
2. Forced rebalancing: Managed with deterministic rules, policies, and continuous monitoring.
3. Slashing Risk: While mitigated through careful node operator selection and monitoring, the possibility of intentional misbehavior or technical issues remains.
4. Liquidity Risk: Potential challenges in converting large amounts of stETH to ETH quickly for Lido Core, especially during market stress, would require stETH redemptions through stVaults.
5. Interoperability risks: Integration with other DeFi protocols may introduce additional complexities and potential vulnerabilities.

### 5.3 Inherited Risks

1. Ethereum Risks: Issues with the Ethereum network, such as consensus failures or major protocol changes, could impact stVault operations.
2. Lido Infrastructure Risks:
- stETH Market Price: Stakers risk an exchange price of stETH lower than the inherent value due to prolonged withdrawal times, expecting validator exits and making arbitrage and risk-free market-making impossible.
- Smart Contract Security: There is an inherent risk that Lido could contain a smart contract vulnerability or bug; to minimize this risk, the Lido protocol codebase remains open-source, reviewed, audited, rolled out on testnets, and covered by extensive tests and a bug bounty program.
- Oracle failures and data manipulation: Oracle may affect protocol's accounting state by bringing malformed data, the risk is mitigated with a consensus mechanisms for the oracle committee and smart contract safety nets.
- Correlated in-protocol mass-slashing: In case of mass-slashing events in Lido Core, the bunker mode activates to socialize conversion rate losses among stETH holders.
- Governance risks: The protocol is maintained and upgraded by the LDO tokenholders. The mitigation of governance risks includes a two-phase voting system, a public delegate voting platform, and an anticipated 2025 H1 Dual Governance activation.

## 6. Useful Links

- [Lido V3 testnet instance on Hoodi](https://docs.lido.fi/deployed-contracts/hoodi-lidov3)
- [stVaults PR on GH](https://github.com/lidofinance/core/pull/874)
- [the Hasu's 2nd GOOSE voted-in proposal](https://snapshot.box/#/s:lido-snapshot.eth/proposal/0xeedef9fea3d782f192410768cabaf6974da40ef36e1d22c7f8fff5fd4cfc7a59)
- [EIP-7002 "Triggerable Withdrawals"](https://eips.ethereum.org/EIPS/eip-7002)
- [EIP-7251 "Increase the MAX_EFFECTIVE_BALANCE"](https://eips.ethereum.org/EIPS/eip-7251)
- [LIP-5 "Mitigations for deposit frontrunning vulnerability"](https://github.com/lidofinance/lido-improvement-proposals/blob/develop/LIPS/lip-5.md)
- [EIP-6110: Supply validator deposits on chain](https://eips.ethereum.org/EIPS/eip-6110)

## 7. Changelog

2025-02-11: Initial version
2025-04-24: Revamp for Lido V3 testnet on Hoodi