---

title: Lido V3 Staking Infrastructure – Audit Scope Document
tags: scope, V3, stVaults, audits
authors: Lido Contributors

---
# Lido V3 Staking Infrastructure – Audit Scope Document

## Simple summary

This document outlines the audit scope for Lido V3, which introduces **Staking Vaults (stVaults)** as a modular extension to the Lido protocol. These vaults allow stakers to delegate ETH to specific node operators (or DVT clusters) while still minting `stETH` with a reserve ratio. This design supports specialized staking setups yet preserves `stETH` liquidity, stability, and fungibility via overcollateralization.

See also: [Lido Staking Vaults (stVaults): Technical Design and Architecture](https://hackmd.io/@lido/stVaults-design)

## Overview of proposed changes

Lido V3 includes the following key components:

- **Core protocol upgrade**: Extends support for minting `stETH` backed by external ETH holdings (i.e., ETH held in specialized vault contracts rather than the main Lido pool only), enabled EIP-7002 driven triggerable withdrawals support, still on with 0x01 validators within the Lido Core pool but 0x02 for stVaults.
- **Staking Vaults (stVaults)**: New contracts that represent isolated vaults tied to a single operator or a DVT cluster, offering tailored staking arrangements. A central *VaultHub* contract coordinates these vaults, ensuring each remains sufficiently collateralized and healthy.
- **Off-Chain oracle enhancements**: Expands the existing oracle system to handle stVaults, reporting vault-specific data and managing updates asynchronously (so called `Lazy Oracle` for stVaults).
- **Node Operator Predeposit Guarantee**: Mitigates deposit frontrunning by requiring node operators to pre-commit deposit data on-chain, including on-chain BLS signature checks.

All components above are within the audit scope. Each is described in detail below, along with key audit considerations and timelines.

## Detailed description of key components

### Core protocol upgrade: minting stETH backed by external ether

In V3, the Lido core protocol is modified so `stETH` can also be minted based on ETH held outside the conventional Lido/stETH pool contract. In practice, this means the Lido contracts can recognize and account for ETH held in new *Staking Vaults* when minting or burning `stETH`.

**What this enables:**
Previously, users would send ETH to Lido’s main contract, leading to deposits on the Beacon Chain via validator activations guided by the Staking Router and corresponding Staking Modules. With the V3 upgrade, a user (or integrator) can instead deposit ETH into a personalized vault (external to the Lido Core pool) and receive `stETH` representing that submission. Because of the required reserve ratio, the `stETH` amount will be less than the ether amount submitted (e.g. 90 stETH for 100 ETH). `stETH` supply and accounting now includes these newly introduced stVaults.

**How it works:**
A new **VaultHub** contract coordinates interactions between Lido’s Core pool logic and external stVaults. VaultHub handles all `stETH` mint/burn operations across stVaults, ensuring each minted unit of `stETH` is backed by locked ETH plus any additional safety margin. Conversely, burning `stETH` releases the previously locked ETH from the vault. VaultHub enforces that total `stETH` remains fully redeemable (subject to the in-protocol withdrawal queue) and guarantees solvency and overcollateralization at the system level.

**Health invariants:**
The upgrade is designed so that *solvency*, *overcollateralization*, and *fungibility* are preserved system-wide. All `stETH` remains fully redeemable for underlying ETH, though the protocol can socialize extreme losses across the broader `stETH` supply if necessary. Under normal or contained slashing conditions, each vault’s performance remains isolated, meaning it has no direct impact on other `stETH` holders.

### Introduction of stVaults

A **Staking Vault (stVault)** is a new smart contract primitive in Lido V3. Each vault holds ETH staked with a specific node operator or validator cluster, under the control of one owner (an individual, institution, or protocol integrator). This design enables specialized staking arrangements within Lido. Key traits:
- **Isolated operator binding**: Each vault is bound to exactly one node operator (or DVT cluster), allowing flexible validator setups without affecting the broader Lido Core pool.
- **Single-owner control**: A vault has one controlling entity. The owner can fund the vault to perform validator deposits, mint stETH, collect rewards, and initiate withdrawals. The vault enforces Lido’s rules around `stETH` liquidity while allowing custom operator-owner agreements.
- **Reserve ratio requirement**: Each vault must keep a portion of its ETH stake as an unminted reserve. For example, with a 90% reserve ratio, depositing 100 ETH mints 90 `stETH`, leaving 10 ETH as a buffer. This protects against slashing or reward volatility.
- **Minting and burning in the vault**: The vault can mint `stETH` for its owner when additional ETH is deposited and conditions are met. Conversely, it can burn `stETH` and return the corresponding amount of ETH. All such actions route through **VaultHub**, which enforces system-wide rules.
- **Rebalancing**: The vault can move ETH from its balance to the Lido Core pool to pay down `stETH` liabilities on a 1:1 basis. The owner can trigger rebalancing at will, provided ETH is available, or it may be forced by VaultHub if the vault’s health falls below certain thresholds.
- **Forced validator withdrawals**: If a vault becomes unhealthy (e.g., under slashing), VaultHub can trigger validator exits (via EIP-7002) to retrieve ETH from the Beacon Chain and restore solvency via a force rebalance.
- **Risk isolation**: Each vault is designed to mitigate contagion risk. If one vault encounters a serious issue, other vaults and the main pool remain unaffected. Only under extreme conditions would the protocol socialize losses across stVaults managed by the same node operator or, in the most severe scenario, reduce the overall `stETH` supply.
- **Use cases**: stVaults enable specialized operator relationships and new product verticals, e.g., institutions staking with dedicated validators, DeFi platforms running leveraged staking strategies, or support for DVT clusters (multiple node operators jointly validating).

### Off-chain oracle enhancements (asynchronous stVault reporting)

Lido’s Oracle system provides on-chain contracts with updated information about validator balances, rewards, and slashes. In V2, a committee of off-chain operators (5-of-9 quorum) reports aggregated data for rebase updates, withdrawal requests, and more. V3 extends the oracle to include stVaults:
- **Vault-specific data reporting**:
Each vault has its own state (e.g., validator balances, slashing reserve, accrued per-vault lido fees), which the oracle must gather and submit on-chain. A modified *AccountingOracle* contract (and related modules) receives vault-specific data in merkle-root form. On-chain logic then updates each vault’s ETH balance, locked reserve, and related parameters **on demand** in a lazy manner.
- **Asynchronous update flow**:
Different vaults might require updates at different times. The audit should confirm that partial or delayed updates do not break the system and that cross-vault consistency is maintained.
- **Integrity and consistency**:
The sum of all vault balances plus the core pool balance must not exceed the total ETH managed by Lido. Auditors should verify that the updated oracle logic correctly calculates each vault’s fees, ensures no vault evades fees, and prevents double counting.
- **Fee accounting**:
The oracle upgrades must ensure that fees within each vault are accounted for correctly and routed to the Lido DAO treasury. Both on-chain validation and off-chain computation are in scope.

### Node Operator predeposit guarantee (Deposit frontrunning mitigation for stVaults)

Lido V3 introduces a **Predeposit Guarantee mechanism (PDG)** to address deposit frontrunning (where a malicious validator private key holder could intercept and front-run deposits to change the withdrawal credentials). While the Lido Core pool uses the Deposit Security Module (LIP-5), stVaults mitigate this issue via PDG:

1. **Predeposit Commitment**: Before broadcasting a validator deposit to Ethereum’s deposit contract, the node operator calls the PDG contract with 1 ETH (from the operator or a guarantor) and supplies the pubkey and signature. An on-chain BLS signature check (via EIP-2537 precompile) confirms validity, ensuring deposits will correctly activate a new validator or top-up the existing one but excluding the case then the funds might be stuck on the deposit contract due to the incorrect deposit signature.
2. **Deposit Execution**: After the predeposit is established and the withdrawal credentials are proved to be correct via a EIP-4788 compat proof, the vault’s ETH can proceed with the full amount deposit using funds from the stVault to the official Ethereum Deposit Contract. Only the pre-committed public key may be used, preventing operators from frontrunning.

A shortcut mechanism is available for owners and operators who trust each other, still protecting the protocol (though not necessarily the vault owner) from deposit frontrunning.

## Dependencies & Ethereum Considerations

Lido V3 relies on Pectra hardfork features, including:

- **EIP-7002 (Triggerable Exits)**: Allows smart contracts to exit validators. Used by VaultHub for forcefully exiting unhealthy vault validators or can be used voluntary by the node operator or stVault's owner.
- **EIP-7251 (Raised MAX_EFFECTIVE_BALANCE)**: Increases the validator’s max effective balance. Code must handle stakes above 32 ETH.
- **EIP-2537 (BLS12-381 Precompile)**: Enables the PDG mechanism to verify BLS signatures on-chain.
- **EIP-6110 (Supply validator deposits on chain):** Enables stVaults oracle to learn new pending deposits before they appear on Beacon Chain.

Auditors should confirm these EIPs are used securely and remain robust if the maximum stake or slashing amounts increase.

## Audit Scope and Expectations

This section details the components under review and outlines our collaboration goals during the security assessment.

### Tech design document (specification to collate with)

[Lido Staking Vaults (stVaults): Technical Design and Architecture](https://hackmd.io/@lido/stVaults-design)

### In-Scope Components (On-Chain)

The main scope includes **Solidity smart contracts** existed before, newly introduced, or changed by the Lido V3 upgrade. This spans ~10,000 lines of code (Solidity versions 0.4.24–0.8.x), found in the [`feat/vaults` branch of the `lidofinance/core`](https://github.com/lidofinance/core/pull/874) repository.

> :warning: The exact commit hash is: [`22cab0f0372015f2d2fce8bede64e98beae28571`](https://github.com/lidofinance/core/tree/22cab0f0372015f2d2fce8bede64e98beae28571) (as of audit start, 2025-06-17)

### In-Scope Components (Off-Chain)

The upgrade also requires changes to **Lido’s off-chain oracle software** (a Python application). Roughly ~3,500 lines of Python code will be updated to handle stVault-related data (validator balances, fees, etc.).

The audit should include a review of this off-chain logic to ensure the correct calculation and secure reporting of vault data.

* **Code location:** PR [#665](https://github.com/lidofinance/lido-oracle/pull/665)
* **Audit commit:** [`8ad1b432943f0b589852d06b55f282327d240a5a`](https://github.com/lidofinance/lido-oracle/tree/8ad1b432943f0b589852d06b55f282327d240a5a)

:warning: All modified files in the `src` directory of this pull request and new dependencies for BLS verification (`ssz`, `py-ecc`) are considered in-scope for the audit.

### In-Scope Components (Easy Track)

Easy Track is extended with a **new factory suite** dedicated to stVault governance.

These contracts let the Lido DAO create and execute motions that adjust stVault-specific parameters (e.g., reserve ratios, operator limits, fees, etc.) through the familiar Easy Track flow.

* **Code location:** PR [#86](https://github.com/lidofinance/easy-track/pull/86)
* **Audit commit:**
- **actual** 2025-07-09 [`577792736e25502e3c1f211bd6adcc0a7ef3aaf9`](https://github.com/lidofinance/easy-track/tree/577792736e25502e3c1f211bd6adcc0a7ef3aaf9)
- 2025-07-02 [`6a3b4829865adfcf3b6d2721737249ee0197b613`](https://github.com/lidofinance/easy-track/tree/6a3b4829865adfcf3b6d2721737249ee0197b613)

:warning: Only the contracts introduced in this pull request are in scope.

### Key Audit Focus Areas and Expectations

We expect a comprehensive review, with attention to:

- **stVault accounting correctness**: Verify that each vault accurately tracks its total ETH (staked + unstaked) and locked reserve. Confirm no vault can mint excessive `stETH` or lose track of liabilities during deposits, rewards, withdrawals, or slashing events.
- **Reserve ratio enforcement**: Check that minting `stETH` is blocked if a vault’s reserve ratio would drop below the permitted threshold. Examine force rebalance triggers (when the ratio falls too low) for correctness and potential edge cases, including rounding.
- **Mint/burn flow safeguards**: Ensure `stETH` cannot be minted without corresponding ETH or burned without releasing ETH, and that all mint/burn calls go through a single controlled gateway (VaultHub).
- **Forced rebalancing and exits**: Review the logic allowing VaultHub to forcibly rebalance or exit vault validators (via EIP-7002). Confirm triggers are correct and that the process handles races and failures (e.g., delayed oracle updates, partial vs full withdrawals, etc.).
- **Cross-Vault and Global Invariants**: Verify total `stETH` supply never exceeds the system’s total ETH. Check if loss socialization mechanisms are clearly defined for catastrophic events (e.g., large-scale slashing).
- **Oracle data handling**: Confirm that partial or out-of-order oracle reports cannot corrupt vault balances or zero them out inadvertently. Ensure stale reports are rejected and that fees are applied consistently.
- **Permissions and access control**: Validate new roles (vault owner, node operator, Lido DAO, oracle members) and confirm no entity can exceed its authorized capabilities. Check that governance retains ultimate protocol control while also allowing stVault owners to manage their vaults and opt-out from the Lido DAO governance participation under no stETH liabilities conditions.
- **Upgradeability and Initialization**: Many contracts will be upgradeable via proxies. Auditors should verify that initialization logic is safe, and that any mechanism for making an implementation immutable (ossification) is secure and cannot be abused.
- **Invariants and Formal Specs**: Identify major invariants (e.g., total ETH ≥ total `stETH` in circulation plus reserves) and check for possible violations.
- **Known risk scenarios**: Assess how the protocol handles typical worst-case losses, socialization of slashing among multiple stVaults managed by the same operator, or a system-wide meltdown (e.g., mass slashing).

## Timeline & Milestones (Tentative)

- [x] [zkOracle second opinion audit for LIP-23](https://hackmd.io/@lido/zkOracle-SP1-second-opinion) start: 2025-06-16
- [x] Nethermind Security
- [x] **On-chain audit Start**: 2025-06-16
- [x] Certora – 2025-06-24
- [x] Consensys Dilligence - 2025-06-16
- [x] MixBytes – ?
- [x] **On-chain code freeze**: 2025-06-17: [`22cab0f0372015f2d2fce8bede64e98beae28571`](https://github.com/lidofinance/core/tree/22cab0f0372015f2d2fce8bede64e98beae28571)
- [x] **Testnet-2 deployment**: 2025-06-25
- [x] **On-chain Easy Track freeze**:
- **actual** 2025-07-09 [`577792736e25502e3c1f211bd6adcc0a7ef3aaf9`](https://github.com/lidofinance/easy-track/tree/577792736e25502e3c1f211bd6adcc0a7ef3aaf9)
- 2025-07-02 [`6a3b4829865adfcf3b6d2721737249ee0197b613`](https://github.com/lidofinance/easy-track/tree/6a3b4829865adfcf3b6d2721737249ee0197b613)
- [x] **Off-chain code freeze**: 2025-07-15 [`8ad1b432943f0b589852d06b55f282327d240a5a`](https://github.com/lidofinance/lido-oracle/tree/8ad1b432943f0b589852d06b55f282327d240a5a)
- [x] Certora
- [x] Composable Security
- [ ] **Audit Duration**: ~2 months, concluding in mid/late August 2025.
- Certora ETA ~September, 2nd
- [ ] **Additional Services**:
- [ ] Certora - Formal Verification
- [ ] Consensys Dilligence - Core invariants fuzzing
- [ ] MixBytes - cross-audit verification, math crunching, governance and trust model audit
- [ ] **Bug Bounty**: (Tentatively) A public bug bounty program will run before mainnet launch, with auditors consulted for relevant findings.
- [ ] **Mainnet Launch**: Timing contingent on successful audits, community reviews, and DAO approval.

## Important References

- **Code Repositories**:
- Smart contracts: [`lidofinance/core`](https://github.com/lidofinance/core/pull/874) (branch: `feat/vaults`).
- Oracle software: [`lidofinance/lido-oracle`](https://github.com/lidofinance/lido-oracle/pull/665) (branch: `feat/vaults-oracle`).
- Testnet-1: [deployed Lido V3 contracts on Hoodi (archived)](https://docs.lido.fi/deployed-contracts/hoodi-lidov3/#%EF%B8%8Fcore-protocol-1)
- Testnet-2: [deployed Lido V3 contracts on Hoodi](https://docs.lido.fi/deployed-contracts/hoodi-lidov3)
- **Documentation**:
- [Hasu’s 2nd GOOSE proposal (product-line staking approach)](https://snapshot.box/#/s:lido-snapshot.eth/proposal/0xeedef9fea3d782f192410768cabaf6974da40ef36e1d22c7f8fff5fd4cfc7a59)
- [Lido V3 announcement](https://research.lido.fi/t/lido-v3-ethereum-staking-infrastructure-for-a-diverse-product-line/9511)
- [Lido Staking Vaults (stVaults): Technical Design and Architecture](https://hackmd.io/@lido/stVaults-design)
- [Deposit frontrunning vulnerability & mitigations](https://github.com/lidofinance/lido-improvement-proposals/blob/develop/LIPS/lip-5.md)
- [Pectra Meta-EIP](https://eips.ethereum.org/EIPS/eip-7600)
- [Previous protocol & oracle audits](https://github.com/lidofinance/audits)
- [Lido V3 whitepaper draft RFC](https://research.lido.fi/t/lido-v3-whitepaper-rfc/10124)
- [Risk assessment framework for stVaults](https://research.lido.fi/t/risk-assessment-framework-for-stvaults/9978)
- [stVaults fees approach](https://research.lido.fi/t/stvaults-fees-approach/9979)

---

## Edits log

- 2025-06-16 - Audit start prep
- 2025-06-24 - Certora kick-off
- 2025-07-02 - ET factories commit frozen
- 2025-07-15 - Off-chain code freeze