# Lido V3 — Design & Implementation Proposal **URL:** \ **Category:** Lido V3\ **Created:** [September 14, 2025, 7:03pm UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665 "2025-09-14T19:03:24Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![TheDZhon](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/thedzhon/32/800_2.png) [@TheDZhon](https://research.lido.fi/u/TheDZhon)\ **Post date:** [September 14, 2025, 7:03pm UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/1 "2025-09-14T19:03:24Z")
## TL;DR - **V3 is near-ready**. Following the [whitepaper](https://research.lido.fi/t/lido-v3-whitepaper-rfc/10124) vision, the first production-ready [Lido V3](https://research.lido.fi/t/lido-v3-ethereum-staking-infrastructure-for-a-diverse-product-line/9511) build has run through two public testnets and is in late audits. Final testnet and follow-up changes from the audits are still to come. - **stVaults** introduce a **non-custodial, over-collateralized** way to choose how and with whom to stake while still minting **stETH**. The existing 1:1 staking path continues as the **Core Pool**. - **Why it matters**. V3 turns the Lido protocol from a single pool into _Ethereum staking infrastructure_: operator-led vaults, DVT/restaking sidecars, leverage loops, and institutional setups. - **Safety first**. stETH minting via stVaults rolls out in phases with global and per-operator caps, backed by a [published risk assessment framework for stVaults](https://research.lido.fi/t/risk-assessment-framework-for-stvaults/9978). - **Ask**. Lido contributors are seeking DAO feedback and sentiment ahead of Snapshot and, if supported, an on-chain Aragon vote after testnets, audits, and final security checks conclude. ## Intro Lido V3 originated in [GOOSE-2](https://snapshot.box/#/s:lido-snapshot.eth/proposal/0xeedef9fea3d782f192410768cabaf6974da40ef36e1d22c7f8fff5fd4cfc7a59) to broaden stETH’s product surface. Since then: early-adopter program, public RFCs, multiple private devnets, two public testnets on Hoodi, and a multi-firm audits campaign (pending completion). Key milestones: - Feb 2025: [Initial V3 reveal](https://research.lido.fi/t/lido-v3-ethereum-staking-infrastructure-for-a-diverse-product-line/9511) + early-adopter program - Apr 2025: Testnet-1 (Hoodi), [Risk Assessment framework for stVaults published](https://research.lido.fi/t/risk-assessment-framework-for-stvaults/9978), [stVaults fees approach](https://research.lido.fi/t/stvaults-fees-approach/9979) - May 2025: [Whitepaper RFC](https://research.lido.fi/t/lido-v3-whitepaper-rfc/10124) posted - Jun 2025: [Testnet-2 (Hoodi)](https://docs.lido.fi/deployed-contracts/hoodi-lidov3) + [Audits kick-off](https://x.com/LidoFinance/status/1934961444891615474) - Aug 2025: [Default risk assessment framework and fees parameters for Lido V3 (stVaults)](https://research.lido.fi/t/default-risk-assessment-framework-and-fees-parameters-for-lido-v3-stvaults) - Sep 2025: [stVaults Committee proposal](https://research.lido.fi/t/stvaults-committee-proposal/10608), Whitepaper RFC wrap-up; deployment lookahead planning With design converged and audits maturing, now is the right time to gauge DAO alignment on upgrading to V3. ## Design ### V3 101: What is Lido V3? (Recap) ![image](https://europe1.discourse-cdn.com/flex013/uploads/lido/original/2X/f/f1b5070ed15c26b82b4f78491e9cf7b81ac70f7f.png) [**stVaults**](https://hackmd.io/@lido/stVaults-design) are isolated within the normal operation mode defined by the [risk assessment framework for stVaults](https://research.lido.fi/t/risk-assessment-framework-for-stvaults/9978). They are opt-in vault contracts that delegate stake to a chosen operator under configurable terms (fees, MEV/sidecars, key management, insurance). They’re non-custodial and connect to Lido’s liquidity layer by over-collateralized stETH minting (a reserve stays in ETH to absorb penalties). Vaults can later be disconnected and ossify their implementation, removing any future DAO-imposed changes. **Core Pool (formerly Lido V2) remains unchanged**. Users who want simple 1:1 battle-tested staking keep the same path. **V3 = Core Pool + stVaults**. The same stETH token is used across both paths; oracle/accounting was upgraded accordingly. ![image](https://europe1.discourse-cdn.com/flex013/uploads/lido/original/2X/e/e4241ce23279d5ed6dc3b1abfd6097e001ed7257.png) **What this unlocks (live examples)** - Operator-led liquid staking: stake directly with a preferred operator and still get stETH. - Custom strategies: DVT clusters, restaking sidecars, specialized MEV/infra. - DeFi loops: use stETH as collateral while ETH keeps compounding in-vault. - Institutional vaults: bespoke terms without sacrificing liquidity. ### Motivation V3 resolves the staking setup control vs liquidity trade-off. Today, many stakers want operator choice, DVT, or compliance requirements — features that a single pooled model can’t serve well. V3 decouples validator selection from the liquidity layer, expanding stETH’s addressable market while improving validator set diversity and resilience. Strategically, V3 delivers on [GOOSE-2](https://snapshot.box/#/s:lido-snapshot.eth/proposal/0xeedef9fea3d782f192410768cabaf6974da40ef36e1d22c7f8fff5fd4cfc7a59): Lido evolves from “the pool” to a platform others can build on, supporting a diverse product line. It aligns incentives: operators win direct demand; builders compose new products; stakers gain choice without losing liquidity. Vault isolation and opt-out mechanics mitigate the risk of DAO-imposed upgrades without a vault owner’s consent, ensuring vault sovereignty and an effective escape hatch. ### Foundations and in-depth design For those interested in diving deeper, here are key reference materials that underpin the Lido V3 design and plan: - **[Lido V3 Whitepaper (Final Draft)](https://hackmd.io/@lido/S1-r1Cdexl)** – Comprehensive overview of the V3 architecture, stVault mechanics, and design rationale. - **[User and integration guides](https://docs.lido.fi/guides/stvaults/)** — Hands-on docs and recipes to build atop of Lido V3. - **[Lido Staking Vaults: Technical Design and Architecture](https://hackmd.io/@lido/stVaults-design)** - The living document, outlining the core stVaults design principles, architecture, and mechanics at a high level. - **Lido Improvement Proposals** - A set of design documents describing important Lido protocol and governance mechanisms aspects, together with their cornerstone changes brought with the Lido V3 upgrade. - [LIP-31: Expanding stETH liquidity layer with over-collateralized minting](https://github.com/lidofinance/lido-improvement-proposals/blob/develop/LIPS/lip-31.md) - Introduces the over-collateralized accounting system enabling stETH to be backed by ether outside the Lido Core pool. Defines the VaultHub registry, external shares mint/burn mechanics, and reserve requirements. - [LIP-32: Sanity checks for stVaults](https://github.com/lidofinance/lido-improvement-proposals/blob/develop/LIPS/lip-32.md) - Describes the comprehensive sanity checks including quarantine periods for suspicious value increases using the “lazy oracle” mechanism. - **[Risk Assessment Framework for stVaults](https://research.lido.fi/t/risk-assessment-framework-for-stvaults/9978)** – A forum post outlining the risk management model for V3. It covers the guiding principles (e.g. stVault users don’t negatively affect stETH holders), defines the global cap on stVault usage (initially ~30% of Lido’s TVL, ~3M ETH), and describes how Reserve Ratios and per-vault caps are set to contain slashing risks and maintain stETH redeemability. This framework informed the secure rollout limits below. - **[stVaults committee](https://research.lido.fi/t/stvaults-committee-proposal/10608)** - A forum proposal to establish a committee, monitoring stVaults’ performance and evolution, facilitating onboarding of new stVaults, and handling requests from stVault Owners and Node Operators for non-default terms. - **[stVaults Fees Approach](https://research.lido.fi/t/stvaults-fees-approach/9979)** – Discussion of the fee model for stVaults. Lido V3 introduces up to three types of fees on vaults (infrastructure fee, reservation liquidity fee, and liquidity fee) to ensure the DAO can fairly charge for use of the system’s resources. The fee approach is flexible to accommodate different use cases (e.g. institutions might accept higher infra fees but need low liquidity fees). The final proposed default fee percentages and their basis are summarized in an update post (August 2025) after community feedback. - **[Default risk assessment framework and fees parameters for Lido V3 (stVaults)](https://research.lido.fi/t/default-risk-assessment-framework-and-fees-parameters-for-lido-v3-stvaults/10504)** - A forum thread, unveiling the set of default parameters that will be proposed for stVaults for risk framework and default fee values. - **[Lido V3 Audit scope](https://hackmd.io/@lido/lido-v3-audit-scope)** – An audit scope, describing related to Lido V3 components (solidity contracts and off-chain oracles) and important design aspects for security experts consideration. ## Implementation ### Current status - **[Code](https://github.com/lidofinance/core/tree/feat/testnet-2)**: feature-complete; offchain stVaults-enabled oracle and accounting rewrites to scale operator count and track vault paths. - **Audits** : To ensure security, Lido V3 has been undergoing extensive audits by multiple independent firms (each focusing on different aspects): - Certora: formal verification + on/off-chain review - ConsenSys Diligence: deep on-chain review + invariant fuzzing - Composable Security: oracle/infra, threat models - MixBytes: vault logic, global accounting math, governance wiring > As of this writing, several interim audit reports have already been delivered, with all audits being targeted to conclude by mid-October 2025. - **Testing** : two public testnets and multiple internal devnets so far; the final public testnet to be launched in October - **Bug bounty** : to be extended on Immunefi post-audit hardening ### Rollout plan > _Secure Rollout with Phased Caps_ While anyone can create a vault and stake ETH from day one, **stETH minting through stVaults will be phased** to limit risk and validate the system in live conditions. Governance and oversight of the phases are split between: - **Lido DAO** — explicitly decides on phase 1→2 transition via an on-chain vote (by adjusting the global minting cap). - **stVault Committee** — monitors performance, operator behavior, and risk metrics; manages parameters (reserve ratios, per-operator caps, minting permissions, fees). It can propose forced exits and adjustments via Easy Track, subject to LDO veto. The rollout follows a three-phase framework, gradually increasing scale and openness: - **Phase 1: Pilot** (starts with Lido V3 upgrade enacted) - **Phase 2: Controlled Expansion** (30 days with zero incidents related to stVaults + next DAO voting slot) - **Phase 3: Permissionless Mode** (30 days with zero incidents related to stVaults + non-objected Easy Track motions) This phased rollout limits systemic risk, builds real-world data, and ensures stability before full-scale adoption. #### Security considerations and emergency mechanisms The protocol implements multiple layers of caps, limits, and pause mechanisms to ensure system safety: **1. Minting Caps and Limits** - **Global external ratio cap** : Enforces maximum percentage of stETH that can be minted through vaults (e.g., 3% in Phase 1, 30% in Phase 2) - **Global staking rate limit** : All stETH minting (Core Pool + vaults) is subject to a 150k stETH/day moving window limit - **Per-vault share limit** : Each vault has an individual limit, restricting the maximum stETH shares it can mint (derived from the risk tier assigned by default) **2. Pause and controls** - Lido DAO Agent can upgrade `VaultHub` and `StakingVault` beacon proxy implementations (except for ossified stVaults), perform technical administrative actions, and assign/resign committees below. - stVaults Committee can initiate Easy Track governance motions related to risk framework parameters and corrective actions for individual vaults; the committee will be assigned by a [dedicated proposal](https://research.lido.fi/t/stvaults-committee-proposal/10608). - **[GateSeal](https://research.lido.fi/t/renew-gateseal-for-the-withdrawal-queue-and-validator-exit-bus-oracle/7081)** Committee: can push a time-limited emergency pause over VaultHub and [Predeposit Guarantee (PDG)](https://docs.lido.fi/guides/stvaults/pdg/) operations; it is proposed that the [existing committee](https://docs.lido.fi/multisigs/emergency-brakes#11-gateseal-committee) be used. - **Vault Owners** : - can manually pause beacon chain deposits - can voluntarily disconnect a vault from the Lido protocol (the vault becomes detached from VaultHub and Oracle) - being disconnected, can ossify its proxy implementation (excluding dependency on the Lido DAO governance) **3. Risk Thresholds** - **Reserve Ratio (RR)**: Minimum reserve percentage (e.g., 10%) - blocks new mints when breached - **Force Rebalance Threshold (FRT)**: Critical reserve level (e.g., 5%) - enables forced rebalancing - **Bad Debt** : When `vault.liabilityShares > stETH.getSharesByPooledEth(vault.totalValue())`, vault enters the bad debt state > Note: as described in the [failure modes of LIP-31](https://github.com/lidofinance/lido-improvement-proposals/blob/develop/LIPS/lip-31.md#failure-modes), the bad debt losses can potentially be covered by: > > - replenishing the staking vaults accrued bad debt with additional funds; > - socializing the bad debt among vaults containing slashed validators of the same node operator; > - executing a self-coverage application (see [LIP-18](https://github.com/lidofinance/lido-improvement-proposals/blob/develop/LIPS/lip-18.md)); > - internalizing the losses to protocol, decreasing stETH token rebase (as it would have been with the Lido Core pool staking penalties) within the next oracle report (using the bad debt internalization mechanism) These mechanisms work together to limit risks while allowing the protocol to scale safely. Emergency responses can be triggered at multiple levels - from individual vault issues to system-wide concerns. ## Next steps We invite the community to provide feedback on this proposal and the Lido V3 design. Please share any concerns, questions, or suggestions you have here in this forum thread. Assuming general support and no blocking issues are raised, the tentative plan is to proceed with a Snapshot vote to signal DAO approval of the V3 upgrade. ### Tentative timeline - _Late Sep 2025_: Barring objections, initiate a Snapshot vote for signaling support of Lido V3. - _Oct 2025_: - If Snapshot support is positive, deploy the Lido V3 contracts to the Hoodi testnet, upgrading the main Lido testnet instance. - Finalize all ongoing audits, address fixes, and complete minor contract changes. A summary of audit results will be published in the thread for DAO review, assuming no pending resolution findings are left. - Schedule an on-chain vote to upgrade and execute the contract changes. The exact details (specific contract addresses, etc.) will be posted before the vote, together with 3rd-party deployment verification notes. - _Nov 2025_: Enactment of Lido V3 upgrade on mainnet, assuming the on-chain vote passes. Contracts will be upgraded, and the new modules (VaultHub, etc.) will be initialized. Phase 1: Pilot begins immediately at this point – all vaults can start accepting deposits, and eligible ones can access minting within the 3% global cap. Close monitoring in the initial weeks post-launch. - _Mid-Dec 2025_: If everything runs smoothly, transition to Phase 2: Controlled Expansion. This would involve lifting the global cap to ~30% via a new DAO vote. Additional node operators and stVaults might be invited to enable minting, possibly in batches. Also, per-node operator minting limits increases expected according to the demand. - _~Q1 2026_: Target for Phase 3: Permissionless Mode activation. By this time, we expect to open stVaults minting to the public. Once enabled, any new vault that connects to the Lido protocol can permissionlessly mint stETH up to its tier limits. > Note: timing remains subject to security and operational readiness. * * * Thanks to everyone who has been reviewing, testing, and pressure-testing V3; let’s keep building on Ethereum and Lido \<3. ---
**Author:** ![governance-data-bot](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/governance-data-bot/32/2204_2.png) [@governance-data-bot](https://research.lido.fi/u/governance-data-bot)\ **Post date:** [September 22, 2025, 4:21pm UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/2 "2025-09-22T16:21:50Z")
## Snapshot vote started The [Lido V3 — Design & Implementation Proposal](https://snapshot.box/#/s:lido-snapshot.eth/proposal/0x01cd474645cc7c3ddf68314d475d421ef833499297f508fee5f7411fafff3954) Snapshot has started! Please cast your votes before Mon, 29 Sep 2025 16:00:00 GMT 🙏 ---
**Author:** ![governance-data-bot](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/governance-data-bot/32/2204_2.png) [@governance-data-bot](https://research.lido.fi/u/governance-data-bot)\ **Post date:** [September 29, 2025, 4:00pm UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/3 "2025-09-29T16:00:37Z")
## Snapshot vote ended Thank you all who participated in the [Lido V3 — Design & Implementation Proposal](https://snapshot.box/#/s:lido-snapshot.eth/proposal/0x01cd474645cc7c3ddf68314d475d421ef833499297f508fee5f7411fafff3954) Snapshot, the proposal passed! 🙏 The results are: **Yes** : 57.9M LDO **No** : 0 LDO ✅ **Winning option: Yes** ---
**Author:** ![tamtamchik](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/tamtamchik/32/4064_2.png) [@tamtamchik](https://research.lido.fi/u/tamtamchik)\ **Post date:** [October 17, 2025, 11:39am UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/4 "2025-10-17T11:39:32Z")
Following Lido DAO’s approval of design and implementation, the Lido V3 contracts were deployed to the Hoodi testnet, updating the main Lido testnet instance. This setup now functions as the long-term testnet environment for Lido contracts, including stVaults. - Deployed contracts: [https://docs.lido.fi/deployed-contracts/hoodi](https://docs.lido.fi/deployed-contracts/hoodi) - Web UI: [http://stvaults-hoodi.testnet.fi](http://stvaults-hoodi.testnet.fi/) - Documentation center: [https://docs.lido.fi/run-on-lido/stvaults/](https://docs.lido.fi/run-on-lido/stvaults/) - stVaults CLI supports new contracts by default (upgrade to latest version required) Mainnet: Coming soon™. Stay tuned. ---
**Author:** ![TheDZhon](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/thedzhon/32/800_2.png) [@TheDZhon](https://research.lido.fi/u/TheDZhon)\ **Post date:** [December 3, 2025, 11:16pm UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/5 "2025-12-03T23:16:12Z")
# Lido V3 — Deployment update and upcoming voting details ## TL;DR - **Technical pre-deployment complete** : All Lido V3 contracts have been pre-deployed to Ethereum mainnet and verified on Etherscan. Source code used matches the latest [audited commit](https://github.com/lidofinance/core/commit/b98371488eb9479cf072bd6c2b682a59c5dd71d8). - **Final verification in progress** : Deployment artifacts have been sent to auditors for independent verification. Before the vote begins, finalized audit reports will be published in a thread, also MixBytes will provide a deployment verification note. - **Vote timeline** : Providing no last-minute security findings and audit reports published, an on-chain Aragon vote is tentatively targeted to commence on **December 10th, 2025** , with enactment _optimistically_ (if supported and non-contentious) expected around **December 19th, 2025** (within the 14:00–23:00 UTC window). - **This follow-up note** provides complete contract addresses, constructor parameters with rationale, voting structure breakdown, and expected next steps. * * * ## Context recap Following the [proposal approval via Snapshot vote](https://snapshot.box/#/s:lido-snapshot.eth/proposal/0x01cd474645cc7c3ddf68314d475d421ef833499297f508fee5f7411fafff3954), testnet phases left behind, and audit campaign finished, Lido contributors have completed the technical mainnet pre-deployment of all V3 contracts. This update serves as the upcoming voting announcement and details thread ahead of the on-chain vote. For those new to this topic, Lido V3 introduces **staking Vaults (stVaults)** — isolated, non-custodial contracts allowing stakers to choose their operator and stake setup while still minting stETH. The existing Core Pool remains unchanged. V3 = Core Pool + stVaults. * * * ## Deployment summary ### Source code references | Component | Repository | Audited Commit | Deploy Commit | | --- | --- | --- | --- | | Core Protocol | [lidofinance/core](https://github.com/lidofinance/core) | [`b98371488`](https://github.com/lidofinance/core/commit/b98371488eb9479cf072bd6c2b682a59c5dd71d8) | [`b8d51cc7`](https://github.com/lidofinance/core/commit/b8d51cc70b96a3b8a406bd1f85de139aa6f2043d) ([UPDATED: 2025-12-11](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/9)) | | Easy Track | [lidofinance/easy-track](https://github.com/lidofinance/easy-track) | [`c64468ca5`](https://github.com/lidofinance/easy-track/commit/c64468ca5126237c33e17b71d9307a6aea0ee5cc) | Same | > **Note** : The deploy commit contains updates to tests, scripts, and voting contracts only. These changes do not affect the bytecode of core protocol contracts — deployed contracts have identical bytecode to the audited commit. [View diff](https://github.com/lidofinance/core/compare/b98371488eb9479cf072bd6c2b682a59c5dd71d8...bb8f7391048cdb69f04c1c52e2610544d9769bb1). * * * ## Contract addresses ### Voting tooling contracts | Contract | Address | Purpose | | --- | --- | --- | | V3TemporaryAdmin | [`0xf738A2C7d69694B618dbB547C1c5A152D7958f06`](https://etherscan.io/address/0xf738A2C7d69694B618dbB547C1c5A152D7958f06) | Auxiliary contract for intermediate admin tasks during deployment; transfers admin to Agent afterward | | V3VoteScript | [`0xE1F4c16908fCE6935b5Ad38C6e3d58830fe86442`](https://etherscan.io/address/0xE1F4c16908fCE6935b5Ad38C6e3d58830fe86442) ([UPDATED: 2025-12-11](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/9)) | Vote script orchestrating all upgrade actions | | V3Template | [`0x34E01ecFebd403370b0879C628f8A5319dDb8507`](https://etherscan.io/address/0x34E01ecFebd403370b0879C628f8A5319dDb8507) | Upgrade template with two-step procedure: `startUpgrade()` / `finishUpgrade()` | ### Core protocol upgrades | Contract | Proxy Address | New Implementation | Notes | | --- | --- | --- | --- | | Lido (stETH) | [`0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84`](https://etherscan.io/address/0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84) | [`0x6ca84080381E43938476814be61B779A8bB6a600`](https://etherscan.io/address/0x6ca84080381E43938476814be61B779A8bB6a600) | Upgrades to V3 logic via Aragon Kernel | | LidoLocator | [`0xC1d0b3DE6792Bf6b4b37EccdcC24e45978Cfd2Eb`](https://etherscan.io/address/0xC1d0b3DE6792Bf6b4b37EccdcC24e45978Cfd2Eb) | [`0x2f8779042EFaEd4c53db2Ce293eB6B3f7096C72d`](https://etherscan.io/address/0x2f8779042EFaEd4c53db2Ce293eB6B3f7096C72d) | Registry with protocol contract addresses | | AccountingOracle | [`0x852deD011285fe67063a08005c71a85690503Cee`](https://etherscan.io/address/0x852deD011285fe67063a08005c71a85690503Cee) | [`0x1455B96780A93e08abFE41243Db92E2fCbb0141c`](https://etherscan.io/address/0x1455B96780A93e08abFE41243Db92E2fCbb0141c) | Upgrades to v4 with stVaults state root reporting (consensus version v5) | ### New protocol contracts (to perform migrations) | Contract | Proxy Address | Implementation | Notes | | --- | --- | --- | --- | | Burner | [`0xE76c52750019b80B43E36DF30bf4060EB73F573a`](https://etherscan.io/address/0xE76c52750019b80B43E36DF30bf4060EB73F573a) | [`0xEe1E3B4f047122650086985f794f0dB5f10Ae49D`](https://etherscan.io/address/0xEe1E3B4f047122650086985f794f0dB5f10Ae49D) | New upgradeable burner replacing old non-upgradeable contract | | OracleReportSanityChecker | [`0xf1647c86E6D7959f638DD9CE1d90e2F3C9503129`](https://etherscan.io/address/0xf1647c86E6D7959f638DD9CE1d90e2F3C9503129) | — | New instance with V3-compatible limits | | TokenRateNotifier | [`0x25e35855783bec3E49355a29e110f02Ed8b05ba9`](https://etherscan.io/address/0x25e35855783bec3E49355a29e110f02Ed8b05ba9) | — | New instance; observers migrated from old notifier | ### Newly introduced stVaults system contracts | Contract | Proxy Address | Implementation | Notes | | --- | --- | --- | --- | | VaultHub | [`0x1d201BE093d847f6446530Efb0E8Fb426d176709`](https://etherscan.io/address/0x1d201BE093d847f6446530Efb0E8Fb426d176709) | [`0x7c7d957D0752AB732E73400624C4a1eb1cb6CF50`](https://etherscan.io/address/0x7c7d957D0752AB732E73400624C4a1eb1cb6CF50) | Central hub for stVault coordination and stETH minting | | PredepositGuarantee | [`0xF4bF42c6D6A0E38825785048124DBAD6c9eaaac3`](https://etherscan.io/address/0xF4bF42c6D6A0E38825785048124DBAD6c9eaaac3) | [`0xCC08C36BD5bb78FDcB10F35B404ada6Ffc71a023`](https://etherscan.io/address/0xCC08C36BD5bb78FDcB10F35B404ada6Ffc71a023) | Protects deposits from front-running attacks | | OperatorGrid | [`0xC69685E89Cefc327b43B7234AC646451B27c544d`](https://etherscan.io/address/0xC69685E89Cefc327b43B7234AC646451B27c544d) | [`0xA612E30D71d7D54aEaf4e5A21023F3F270932C2C`](https://etherscan.io/address/0xA612E30D71d7D54aEaf4e5A21023F3F270932C2C) | Manages operator groups and risk tiers | | Accounting | [`0x23ED611be0e1a820978875C0122F92260804cdDf`](https://etherscan.io/address/0x23ED611be0e1a820978875C0122F92260804cdDf) | [`0xd43a3E984071F40d5d840f60708Af0e9526785df`](https://etherscan.io/address/0xd43a3E984071F40d5d840f60708Af0e9526785df) | New accounting module for V3 | | LazyOracle | [`0x5DB427080200c235F2Ae8Cd17A7be87921f7AD6c`](https://etherscan.io/address/0x5DB427080200c235F2Ae8Cd17A7be87921f7AD6c) | [`0x47f3a6b1E70F7Ec7dBC3CB510B1fdB948C863a5B`](https://etherscan.io/address/0x47f3a6b1E70F7Ec7dBC3CB510B1fdB948C863a5B) | “Lazy oracle” for vault value updates with quarantine | ### stVaults factory stack | Contract | Address | Notes | | --- | --- | --- | | VaultFactory | [`0x02Ca7772FF14a9F6c1a08aF385aA96bb1b34175A`](https://etherscan.io/address/0x02Ca7772FF14a9F6c1a08aF385aA96bb1b34175A) | Factory for creating new stVaults | | UpgradeableBeacon | [`0x5FbE8cEf9CCc56ad245736D3C5bAf82ad54Ca789`](https://etherscan.io/address/0x5FbE8cEf9CCc56ad245736D3C5bAf82ad54Ca789) | Beacon proxy pattern for stVault upgrades | | StakingVault (impl) | [`0x06A56487494aa080deC7Bf69128EdA9225784553`](https://etherscan.io/address/0x06A56487494aa080deC7Bf69128EdA9225784553) | Reference implementation for vaults | | Dashboard (impl) | [`0x294825c2764c7D412dc32d87E2242c4f1D989AF3`](https://etherscan.io/address/0x294825c2764c7D412dc32d87E2242c4f1D989AF3) | Dashboard helper for vault management | | ValidatorConsolidationRequests | [`0xaC4Aae7123248684C405A4b0038C1560EC7fE018`](https://etherscan.io/address/0xaC4Aae7123248684C405A4b0038C1560EC7fE018) | Handles validator consolidation requests | ### GateSeal | Contract | Address | Notes | | --- | --- | --- | | GateSeal (VaultHub + PDG) | [`0x881dAd714679A6FeaA636446A0499101375A365c`](https://etherscan.io/address/0x881dAd714679A6FeaA636446A0499101375A365c) | Emergency pause for VaultHub and PredepositGuarantee | > GateSeal Blueprint: [`0xEe06EA501f7d9DC6F4200385A8D910182D155d3e`](https://etherscan.io/address/0xEe06EA501f7d9DC6F4200385A8D910182D155d3e) > GateSeal Factory: [`0x6c82877cac5a7a739f16ca0a89c0a328b8764a24`](https://etherscan.io/address/0x6c82877cac5a7a739f16ca0a89c0a328b8764a24) > Sealing Committee: [`0x8772E3a2D86B9347A2688f9bc1808A6d8917760C`](https://etherscan.io/address/0x8772E3a2D86B9347A2688f9bc1808A6d8917760C) (existing GateSeal Committee) ### Easy Track factories for stVaults Committee | Factory | Address | Purpose | Phase | | --- | --- | --- | --- | | RegisterGroupsInOperatorGrid | [`0x194A46DA1947E98c9D79af13E06Cfbee0D8610cC`](https://etherscan.io/address/0x194A46DA1947E98c9D79af13E06Cfbee0D8610cC) | Register new operator groups | Phase 1 (50k stETH max) | | RegisterGroupsInOperatorGrid | [`0xE73842AEbEC99Dacf2aAEec61409fD01A033f478`](https://etherscan.io/address/0xE73842AEbEC99Dacf2aAEec61409fD01A033f478) | Register new operator groups | Phase 2/3 (1M stETH max) | | UpdateGroupsShareLimitInOperatorGrid | [`0x8Bdc726a3147D8187820391D7c6F9F942606aEe6`](https://etherscan.io/address/0x8Bdc726a3147D8187820391D7c6F9F942606aEe6) | Update group share limits | Phase 1 (50k stETH max) | | UpdateGroupsShareLimitInOperatorGrid | [`0xf23559De8ab37fF7a154384B0822dA867Cfa7Eac`](https://etherscan.io/address/0xf23559De8ab37fF7a154384B0822dA867Cfa7Eac) | Update group share limits | Phase 2/3 (1M stETH max) | | RegisterTiersInOperatorGrid | [`0x5292A1284e4695B95C0840CF8ea25A818751C17F`](https://etherscan.io/address/0x5292A1284e4695B95C0840CF8ea25A818751C17F) | Register new risk tiers | All phases | | AlterTiersInOperatorGrid | [`0xa29173C7BCf39dA48D5E404146A652d7464aee14`](https://etherscan.io/address/0xa29173C7BCf39dA48D5E404146A652d7464aee14) | Modify existing tier parameters | Phase 1 (0 default tier limit) | | AlterTiersInOperatorGrid | [`0x73f80240ad9363d5d3C5C3626953C351cA36Bfe9`](https://etherscan.io/address/0x73f80240ad9363d5d3C5C3626953C351cA36Bfe9) | Modify existing tier parameters | Phase 2/3 (1M default tier limit) | | SetJailStatusInOperatorGrid | [`0x93F1DEE4473Ee9F42c8257C201e33a6Da30E5d67`](https://etherscan.io/address/0x93F1DEE4473Ee9F42c8257C201e33a6Da30E5d67) | Jail/unjail vault minting capability | All phases | | UpdateVaultsFeesInOperatorGrid | [`0x5C3bDFa3E7f312d8cf72F56F2b797b026f6B471c`](https://etherscan.io/address/0x5C3bDFa3E7f312d8cf72F56F2b797b026f6B471c) | Update vault fee rates | All phases | | ForceValidatorExitsInVaultHub | [`0x6C968cD89CA358fbAf57B18e77a8973Fa869a6aA`](https://etherscan.io/address/0x6C968cD89CA358fbAf57B18e77a8973Fa869a6aA) | Trigger forced validator exits | All phases | | SocializeBadDebtInVaultHub | [`0x1dF50522A1D868C12bF71747Bb6F24A18Fe6d32C`](https://etherscan.io/address/0x1dF50522A1D868C12bF71747Bb6F24A18Fe6d32C) | Socialize bad debt between vaults | All phases | | VaultsAdapter | [`0xe2DE6d2DefF15588a71849c0429101F8ca9FB14D`](https://etherscan.io/address/0xe2DE6d2DefF15588a71849c0429101F8ca9FB14D) | Helper contract for Easy Track operations | All phases | > **Notes** : > > 1. `SetLiabilitySharesTargetInVaultHub` ([`0x4E5Cc771c7b77f1417fa6BA9262d83C6CCc1e969`](https://etherscan.io/address/0x4E5Cc771c7b77f1417fa6BA9262d83C6CCc1e969)) is deployed but will **not** be connected in the initial vote, as there are no current plans to use it. > 2. Phase 2/3 factories `RegisterGroupsInOperatorGrid` [`0xE73842AEbEC99Dacf2aAEec61409fD01A033f478`](https://etherscan.io/address/0xE73842AEbEC99Dacf2aAEec61409fD01A033f478), `UpdateGroupsShareLimitInOperatorGrid` [`0xf23559De8ab37fF7a154384B0822dA867Cfa7Eac`](https://etherscan.io/address/0xf23559De8ab37fF7a154384B0822dA867Cfa7Eac), `AlterTiersInOperatorGrid` [`0x73f80240ad9363d5d3C5C3626953C351cA36Bfe9`](https://etherscan.io/address/0x73f80240ad9363d5d3C5C3626953C351cA36Bfe9) are deployed but also will **not** be connected in the initial vote. ### Discontinued Contracts | Contract | Address | Notes | | --- | --- | --- | | Burner (old) | `0xD15a672319Cf0352560eE76d9e89eAB0889046D3` | Non-upgradeable; replaced by new Burner | | OracleReportSanityChecker (old) | `0x6232397ebac4f5772e53285b26c47914e9461e75` | Replaced by new instance | | TokenRateNotifier (old) | `0xe6793B9e4FbA7DE0ee833F9D02bba7DB5EB27823` | Observers migrated to new notifier | | LegacyOracle | `0x442af784A788A5bd6F42A01Ebe9F287a871243fb` | Fully deprecated; no longer referenced | * * * ## Constructor/initializer parameters and rationale ### V3Template Constructor ```auto constructorArgs: [ V3AddressesParams (struct with 29 addresses and lido app id), expireSinceInclusive: 1768435200, // Unix timestamp: Jan 15, 2026 initialMaxExternalRatioBP: 300 // 3% = 300 basis points ] ``` | Parameter | Value | Rationale | | --- | --- | --- | | `expireSinceInclusive` | `1768435200` (Jan 15, 2026 00:00:00 UTC) | Safety mechanism: if the upgrade isn’t enacted by this date, the template becomes unusable. Provides ~4 weeks buffer from expected enactment. | | `initialMaxExternalRatioBP` | `300` (3%) | **Phase 1 global cap** : At most 3% of total stETH supply can be minted via stVaults initially. Ensures Core Pool remains ≥97% of Lido TVL during pilot phase. Per the [Risk Assessment Framework](https://research.lido.fi/t/risk-assessment-framework-for-stvaults/9978) and Phase 1 limits ratified via the snapshot. | ### V3VoteScript Constructor ```auto constructorArgs: [ upgradeTemplate: 0x34E01ecFebd403370b0879C628f8A5319dDb8507, timeConstraints: 0x2a30F5aC03187674553024296bed35Aa49749DDa, odcSlashingReserveWeRightShiftEpochs: 8192, odcSlashingReserveWeLeftShiftEpochs: 8192 ] ``` | Parameter | Value | Rationale | | --- | --- | --- | | `timeConstraints` | `0x2a30F5aC03187674553024296bed35Aa49749DDa` | An axuliary contracts that allows to create time windows eligible for the vote enactments, used in DG before | | `odcSlashingReserveWeRightShiftEpochs` | `8192` | Oracle daemon config: epochs to look back from `withdrawable_epoch` when including slashings in stVault oracle reports. 8192 epochs ≈ 36 days — covers possible correlation penalty period effects. | | `odcSlashingReserveWeLeftShiftEpochs` | `8192` | Oracle daemon config: forward-looking window for slashing inclusion. Symmetric with right shift for consistent accounting. | | `ENABLED_DAY_SPAN_START` | `50400` (14:00 UTC) | Execution window start — ensures enactment happens somewhere after regular AccountingOracle report arrival. | | `ENABLED_DAY_SPAN_END` | `82800` (23:00 UTC) | Execution window end — 9-hour window accommodates global contributors availability. | ### VaultHub Constructor ```auto constructorArgs: [ lidoLocator: 0xC1d0b3DE6792Bf6b4b37EccdcC24e45978Cfd2Eb, lido: 0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84, hashConsensusForAccountingOracle: 0xD624B08C83bAECF0807Dd2c6880C3154a5F0B288, maxRelativeShareLimitBP: 1000 // 10% ] ``` | Parameter | Value | Rationale | | --- | --- | --- | | `maxRelativeShareLimitBP` | `1000` (10%) | Maximum share limit any single vault can have relative to total stETH. Sanity check defensive parameter. | ### OperatorGrid Initialization ```auto initialize params (encoded): admin: 0xf738A2C7d69694B618dbB547C1c5A152D7958f06 (V3TemporaryAdmin), defaultTierId: 0, defaultTierReserveRatio: 5000, // 50% defaultTierForceRebalanceThreshold: 4975, // 49.75% defaultTierInfraFeeBP: 100, // 1% defaultTierLiquidityFeeBP: 650, // 6.5% defaultTierReservationFeeBP: 0 // 0% ``` | Parameter | Value | Rationale | | --- | --- | --- | | Default Tier Reserve Ratio | `5000` (50%) | Permissionless vaults must hold 50% collateral unminted. Identified operators get lower RR via custom tiers. Per [Default Parameters Proposal](https://research.lido.fi/t/default-risk-assessment-framework-and-fees-parameters-for-lido-v3-stvaults/10504). | | Default Tier Force Rebalance Threshold | `4975` (49.75%) | 0.25% below RR. If a vault’s reserve falls below this (e.g., due to slashing), forced rebalancing becomes possible. Small buffer prevents trivial fluctuations triggering rebalance. | | Default Tier Infrastructure Fee | `100` (1%) | DAO’s share of vault rewards for platform usage. Covers oracle/operational costs. Per [Default Parameters Proposal](https://research.lido.fi/t/default-risk-assessment-framework-and-fees-parameters-for-lido-v3-stvaults/10504). | | Default Tier Liquidity Fee | `650` (6.5%) | Fee for stETH liquidity provision. Compensates for liquidity risk. Per [Default Parameters Proposal](https://research.lido.fi/t/default-risk-assessment-framework-and-fees-parameters-for-lido-v3-stvaults/10504). | | Default Tier Reservation Fee | `0` (0%) | Initially 0% to simplify initial Lido V3 design. May be revisited to incentivize efficient capital use in future protocol versions. | ### LazyOracle Initialization ```auto initialize params (encoded): admin: 0x3e40D73EB977Dc6a537aF587D48316feE66E9C8c (Agent), quarantinePeriod: 259200, // 3 days in seconds rewardRatioBP: 350, // 3.5% maxLidoFeeRatePerSecond: 2880000000000000000 // ~0.0029 ETH/s ``` | Parameter | Value | Rationale | | --- | --- | --- | | `quarantinePeriod` | `259200` (3 days) | Per [LIP-32](https://github.com/lidofinance/lido-improvement-proposals/blob/develop/LIPS/lip-32.md): suspicious vault value increases are quarantined for 3 days before being credited. Prevents manipulation via fake value increases. | | `rewardRatioBP` | `350` (3.5%) | Maximum reward ratio per oracle report. Sanity check against abnormal reward spikes. | | `maxLidoFeeRatePerSecond` | `~2.88e18` | Maximum **theoretical** fee rate the protocol can charge per second. Safety bound. | ### Easy Track Factory Limits | Factory Type | Phase 1 Limit | Phase 2/3 Limit | Rationale | | --- | --- | --- | --- | | Group registration/update | 50,000 stETH | 1,000,000 stETH | Phase 1: Conservative per-operator cap. Later phases allow larger operators. | | Default tier share limit | 0 stETH | 1,000,000 stETH | Phase 1: Permissionless minting disabled. Phase 3 enables permissionless **minting** vaults. | | Fee bounds (infrastructure) | ≤1% (100 BP) | — | Committee can adjust within bounds; higher requires DAO vote. | | Fee bounds (liquidity) | ≤10% (1000 BP) | — | Committee can adjust within bounds; higher requires DAO vote. | | Fee bounds (reservation) | =0% (fixed) | — | Currently unused. | | Validator exit fee limit | 0.1 ETH | — | Max EIP-7002 fee paid for forced exit operations (under EL requests congestion). | ### OracleReportSanityChecker Constructor ```auto constructorArgs: [ lidoLocator, accountingOracle, accounting, agent, limits: [3600, 1800, 1000, 50, 600, 8, 24, 7680, 750000, 8, 101, 50] ] ``` | Limit | Value | Meaning | | --- | --- | --- | | `exitedValidatorsPerDayLimit` | `3600` | The max possible number of validators that might be reported as `exited` | | `appearedValidatorsPerDayLimit` | `1800` | The max possible number of validators that might be reported as `appeared` | | `annualBalanceIncreaseBPLimit` | `1000` (10%) | Max annual CL balance increase rate | | `simulatedShareRateDeviationBPLimit` | `50` (0.5%) | Max share rate deviation in simulation | | `maxValidatorExitRequestsPerReport` | `600` | Max exit requests per validator exit bus oracle report | | `maxItemsPerExtraDataTransaction` | `8` | Max extra data items in accounting reports | | `maxNodeOperatorsPerExtraDataItem` | `24` | Max operators per extra data item | | `requestTimestampMargin` | `7680` | Timestamp margin for requests (seconds) | | `maxPositiveTokenRebase` | `750000` | Max positive rebase (in 1e9 precision) | | `initialSlashingAmountPWei` | `8` | Initial slashing amount (peta-wei) | | `inactivityPenaltiesAmountPWei` | `101` | Inactivity penalties (peta-wei) | | `clBalanceOraclesErrorUpperBPLimit` | `50` | CL balance oracle error upper bound | Note: these parameters are 1:1 with the currently plugged and used [`OracleReportSanityChecker`](https://etherscan.io/address/0x6232397ebac4f5772e53285b26c47914e9461e75) version. ### AccountingOracle Constructor ```auto constructorArgs: [ lidoLocator: 0xC1d0b3DE6792Bf6b4b37EccdcC24e45978Cfd2Eb, secondsPerSlot: 12, genesisTime: 1606824023 ] ``` | Parameter | Value | Rationale | | --- | --- | --- | | `secondsPerSlot` | `12` | Ethereum mainnet slot duration | | `genesisTime` | `1606824023` | Ethereum mainnet beacon chain genesis (Dec 1, 2020) | | Post-upgrade consensus version | `5` | Bumped from 4 to support stVaults state root reporting | | Post-upgrade contract version | `4` | Bumped from 3 to reflect new capabilities | ### GateSeal Configuration | Parameter | Value | Rationale | | --- | --- | --- | | Seal Duration | 14 days | Pause duration before automatic expiry. Ensures system can’t be halted indefinitely. | | Sealing Committee | `0x8772E3a2D86B9347A2688f9bc1808A6d8917760C` | Existing GateSeal Committee multisig. | | Sealables | VaultHub, PredepositGuarantee | New V3 contracts requiring emergency pause capability. | | Expiration timestamp | 1796302499 | Roughly 1 year duration, corresponds to Thursday, December 3, 2026 12:54:59 PM | * * * ## Voting Structure The on-chain Aragon vote is an omnibus proposal with **two distinct parts** : ### Part 1: Voting Items (8 items) — Execute Immediately These items are executed when the Aragon vote passes (no Dual Governance delay): | # | Action | Contract Target | Permission Granted | | --- | --- | --- | --- | | 2 | Add AlterTiersInOperatorGrid (Phase 1) factory to Easy Track | EasyTrack | `operatorGrid.alterTiers` | | 3 | Add RegisterGroupsInOperatorGrid (Phase 1) factory to Easy Track | EasyTrack | `operatorGrid.registerGroup`, `operatorGrid.registerTiers` | | 4 | Add RegisterTiersInOperatorGrid factory to Easy Track | EasyTrack | `operatorGrid.registerTiers` | | 5 | Add UpdateGroupsShareLimitInOperatorGrid (Phase 1) factory to Easy Track | EasyTrack | `operatorGrid.updateGroupShareLimit` | | 6 | Add SetJailStatusInOperatorGrid factory to Easy Track | EasyTrack | `vaultsAdapter.setVaultJailStatus` | | 7 | Add UpdateVaultsFeesInOperatorGrid factory to Easy Track | EasyTrack | `vaultsAdapter.updateVaultFees` | | 8 | Add ForceValidatorExitsInVaultHub factory to Easy Track | EasyTrack | `vaultsAdapter.forceValidatorExit` | | 9 | Add SocializeBadDebtInVaultHub factory to Easy Track | EasyTrack | `vaultsAdapter.socializeBadDebt` | ### Part 2: Dual Governance Items (21 items) — Subject to DG Veto Period These items go through Dual Governance and execute only after the veto period: | # | Action | Purpose | | --- | --- | --- | | 1.1 | Check execution time window (14:00–23:00 UTC) | Ensure DG proposal enactment aligned with oracle reports and during monitored hours | | 1.2 | Call `V3Template.startUpgrade()` | Lock upgrade window, record initial state | | 1.3 | Upgrade LidoLocator implementation | Point to new V3 contract registry | | 1.4 | Grant `APP_MANAGER_ROLE` to Agent | Temporary permission for Lido upgrade | | 1.5 | Set Lido implementation in Aragon Kernel | Upgrade stETH contract to V3 logic | | 1.6 | Revoke `APP_MANAGER_ROLE` from Agent | Clean up temporary permission | | 1.7 | Revoke `REQUEST_BURN_SHARES_ROLE` from Lido on old Burner | Remove obsolete permission | | 1.8 | Revoke `REQUEST_BURN_SHARES_ROLE` from Curated Module on old Burner | Remove obsolete permission | | 1.9 | Revoke `REQUEST_BURN_SHARES_ROLE` from SimpleDVT on old Burner | Remove obsolete permission | | 1.10 | Revoke `REQUEST_BURN_SHARES_ROLE` from CSM Accounting on old Burner | Remove obsolete permission | | 1.11 | Upgrade AccountingOracle implementation | Enable stVaults state root reporting | | 1.12 | Revoke `REPORT_REWARDS_MINTED_ROLE` from Lido on StakingRouter | Transfer responsibility to Accounting | | 1.13 | Grant `REPORT_REWARDS_MINTED_ROLE` to Accounting on StakingRouter | New rewards reporting path | | 1.14 | Grant `CONFIG_MANAGER_ROLE` to Agent on OracleDaemonConfig | Temporary permission for config update | | 1.15 | Set `SLASHING_RESERVE_WE_RIGHT_SHIFT` in OracleDaemonConfig | Configure oracle slashing lookback (8192 epochs) | | 1.16 | Set `SLASHING_RESERVE_WE_LEFT_SHIFT` in OracleDaemonConfig | Configure oracle slashing look-ahead (8192 epochs) | | 1.17 | Revoke `CONFIG_MANAGER_ROLE` from Agent on OracleDaemonConfig | Clean up temporary permission | | 1.18 | Grant `PAUSE_ROLE` to Agent on `PredepositGurantee` | Temporary permission for PDG state update | | 1.19 | Pause `PredepositGurantee` indefinitely | Disable PDG-guided deposit flows | | 1.20 | Revoke `PAUSE_ROLE` to Agent from `PredepositGurantee` | Clean up temporary permission | | 1.21 | Call `V3Template.finishUpgrade()` | Finalize upgrade, migrate burner state, set external ratio | > **NOTE:** Items 1.18—1.20 added according to the [2025-12-11 update by @tamtamchik](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/9) ### Role Changes Summary **New Burner roles (post-upgrade):** - `DEFAULT_ADMIN_ROLE`: Agent - `REQUEST_BURN_SHARES_ROLE`: Accounting, CSM Accounting - `REQUEST_BURN_MY_STETH_ROLE`: ∅ (none) **VaultHub roles:** - `DEFAULT_ADMIN_ROLE`: Agent - `VALIDATOR_EXIT_ROLE`: VaultsAdapter - `BAD_DEBT_MASTER_ROLE`: VaultsAdapter - `PAUSE_ROLE`: GateSeal, ResealManager - `RESUME_ROLE`: ResealManager - `VAULT_MASTER_ROLE`: ∅ (none) - `REDEMPTION_MASTER_ROLE`: ∅ (none) **OperatorGrid roles:** - `DEFAULT_ADMIN_ROLE`: Agent - `REGISTRY_ROLE`: EVMScriptExecutor, VaultsAdapter **PredepositGuarantee roles:** - `DEFAULT_ADMIN_ROLE`: Agent - `PAUSE_ROLE`: GateSeal, ResealManager - `RESUME_ROLE`: ResealManager **StakingRouter changes:** - `REPORT_REWARDS_MINTED_ROLE`: Lido → Accounting * * * ## Tentative Timeline > **NOTE** : Timing subject to security findings and operational readiness. Any delays will be communicated. | Date | Milestone | | --- | --- | | **December 10th** | On-chain Aragon vote commences (~3 days voting + 2 days objection) | | **December 15th** | Vote enactment; Easy Track factories become active; DG submission for core upgrade | | **December 15th–19th** | Dual Governance veto collection period (~3 days) + pre-execution timelock (~1 day) | | **December 19th** | **Rollout date** — Enactment window 14:00–23:00 UTC. First stVaults can be created and connected to VaultHub. | | **December 20th** | First AccountingOracle report containing stVaults state data (may have slight delays) | | **Late Dec 2025+** | Active monitoring, running-in period, phase transition planning | | **~Jan 2026** | If 30 days pass with no incidents, DAO considers Phase 2 transition (30% cap) | | **~Q1 2026** | Target for Phase 3 (permissionless minting) if conditions met | * * * ## Verification and Audit Status ### Audits Lido V3 has undergone multiple independent audits: | Firm | Scope | Status | | --- | --- | --- | | **Certora** | Formal verification + on/off-chain audit rounds | Completed, reports to be published | | **ConsenSys Diligence** | An on-chain audit + invariant fuzzing | Completed, report to be published | | **Composable Security** | Oracle/infra audit, threat models beyond | Completed, report to be published | | **MixBytes** | Vault logic, global accounting math, Easy Track factories, governance wiring | Completed, reports to be published | Final audit reports will be published in the [Lido Audits repository](https://github.com/lidofinance/audits) and linked here once available. ### Deployment Verification An independent deployment verification report by **MixBytes** will be published before the vote begins. This report will confirm: - Bytecode matches audited commit - Constructor parameters are correct - Access control is properly configured - State initialization is valid ### Bug Bounty The [Immunefi bug bounty program](https://immunefi.com/bug-bounty/lido/) are to be extended to cover V3 contracts. Also, there is an [ongoing Lido V3 bug bounty competition](https://immunefi.com/audit-competition/lido-v3-bug-bounty-competition/information/) with boosted rewards for any severe vulnerabilities found. * * * ## What this means for stakers **Existing stETH/wstETH holders** : No action required. The upgrade is backward-compatible. All existing functionality (staking, wrapping, withdrawals, transfers, permits) continues to work exactly as before. **New vault users** : After enactment, you can create stVaults and stake ETH immediately. stETH minting will be available for identified operators within the 3% global cap (Phase 1). Permissionless minting is disabled until Phase 3. **Node Operators** : Early adopters and Lido V3 supporters will be onboarded first. Contact the [stVaults Committee](https://research.lido.fi/t/stvaults-committee-proposal/10608) for participation details. * * * ## Next Steps 1. **Final audit reports** — To be published and linked 2. **MixBytes deployment verification report** — Expected before vote launch 3. **On-chain vote** — Tentatively penciled for December, 10th 4. **Community monitoring** — Post-upgrade observation period * * * If you have questions about the upgrade mechanics, contract parameters, or any edge cases, please ask below. Lido contributors are here to address your queries. Thank you for your engagement in the Lido DAO governance. Onwards to Lido V3! 🚀 ---
**Author:** ![Izzy](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/izzy/32/320_2.png) [@Izzy](https://research.lido.fi/u/Izzy)\ **Post date:** [December 4, 2025, 8:48am UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/6 "2025-12-04T08:48:52Z")
That’s really great to see. Can’t wait for Lido V3 and stVaults to be a reality on mainnet! ---
**Author:** ![tamtamchik](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/tamtamchik/32/4064_2.png) [@tamtamchik](https://research.lido.fi/u/tamtamchik)\ **Post date:** [December 8, 2025, 3:13pm UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/7 "2025-12-08T15:13:04Z")
# Vote Script Discrepancy Report Following the DAO-Ops established voting verification procedures, a discrepancy has been identified in the pre-deployed `V3VoteScript` contract ([`0xa47Ca1d2029D8e735237ea4E74c607426d4aA07e`](https://etherscan.io/address/0xa47Ca1d2029D8e735237ea4E74c607426d4aA07e)). ## Issue Details The `IVaultsAdapter` interface within `V3VoteScript` contains outdated function signatures that don’t match the deployed `VaultsAdapter` contract ([`0xe2DE6d2DefF15588a71849c0429101F8ca9FB14D`](https://etherscan.io/address/0xe2DE6d2DefF15588a71849c0429101F8ca9FB14D)). ### Function Signature Mismatches 1. **`updateVaultFees()` function** - `V3VoteScript` interface: Uses `uint16` for fees - Deployed `VaultsAdapter`: Uses `uint256` for fees 2. **`forceValidatorExit()` function** - `V3VoteScript` interface: Includes an extra `address _feeRecipient` parameter - Deployed `VaultsAdapter`: Does not include the `_feeRecipient` parameter ### Impact These mismatches generate incorrect function signatures. Since these signatures are used in the ACL for EasyTrack factories, calls will be blocked as unauthorized and will fail to execute. ## Resolution A fix has been implemented and deployed: - Fix PR: [fix: update hardcoded IVaultsAdapter by dry914 · Pull Request #1595 · lidofinance/core · GitHub](https://github.com/lidofinance/core/pull/1595) - Deployment PR: [feat: redeploy V3VoteScript with correct VaultsAdapter interface by failingtwice · Pull Request #1596 · lidofinance/core · GitHub](https://github.com/lidofinance/core/pull/1596) **New `V3VoteScript` address** : [`0xf2BeCc7aF0AA50DaD54781e06d5ce1A7eAD59AfA`](https://etherscan.io/address/0xf2BeCc7aF0AA50DaD54781e06d5ce1A7eAD59AfA) The fix and newly deployed address have been sent to the auditors, and an additional layer of test coverage is in progress. ---
**Author:** ![TheDZhon](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/thedzhon/32/800_2.png) [@TheDZhon](https://research.lido.fi/u/TheDZhon)\ **Post date:** [December 10, 2025, 7:43pm UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/8 "2025-12-10T19:43:49Z")
# Lido V3 Launch Update ## **TL;DR** After extensive audits across three testnets, contributors are ready to bring **Lido V3** to mainnet. **Voting begins December 15th** , with an assumed **enactment date of December 24th** if the proposal passes. * * * ## **Phase 1 → Soft-Launch Mode** Given the complexities and cross-component interactions in Lido V3, contributors propose a more cautious rollout by executing the previously defined **[Phase 1: Pilot](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665#p-22926-rollout-plan-9)** as a **soft launch** , followed by a full launch shortly after. ### **Soft Launch Goals** The soft launch will make **Lido V3 and stVaults** available for builders on mainnet as early as **late December** , enabling partners to integrate and properly test. ### **Soft Launch Caveats** During soft launch, some V3 features (comparing with the described Phase 1 modes) will intentionally remain disabled: - PredepositGuarantee (PDG) functionality, meaning that vault owners and users should only interact with node operators who are trusted, and certain advanced operations may be limited (e.g. using direct deposit top-ups or flash-loans to interact with stVaults and DeFi together) until the PDG mechanism’s edge-case handling is hardened further. - The stVaults UI and broader API/SDK components, meaning that vaults will be created, managed, and interacted with either via use of the stVaults CLI, direct contract interactions, or custom integrations. #### **Phase 1 Operational Limits** General **[Phase 1 limits](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665#p-22926-rollout-plan-9)** will apply, including: - Global cap of ~300k stETH available for minting - stETH minting restricted to permissioned node operators only #### **Audience** Soft launch is intended for **known partners and integrators**. The broader public is **not** expected to interact with vaults during this phase. Public-facing communications and promotional activities will begin at full launch. * * * ## **Phase 2 → Full Launch Mode** The **full launch** , aligned with **[Phase 2](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665#p-22926-rollout-plan-9)**, is expected in **late January**. Phase 2 will: - Enable **advanced Lido V3 functionality** - Open the door for **wider public usage** - Be accompanied by **broader communications and promotion** * * * More details coming shortly, thanks for bearing with Lido V3 💙 ---
**Author:** ![tamtamchik](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/tamtamchik/32/4064_2.png) [@tamtamchik](https://research.lido.fi/u/tamtamchik)\ **Post date:** [December 11, 2025, 7:46pm UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/9 "2025-12-11T19:46:27Z")
According to the Launch update provided, there is a voting script contract deployed supporting the “soft launch” course suggested: [`0xE1F4c16908fCE6935b5Ad38C6e3d58830fe86442`](https://etherscan.io/address/0xE1F4c16908fCE6935b5Ad38C6e3d58830fe86442) — commit: [`b8d51cc7`](https://github.com/lidofinance/core/commit/b8d51cc70b96a3b8a406bd1f85de139aa6f2043d) The voting script contract follows the previously suggested voting plan, adding **three** new Dual Governance items (1.18-1.20, 18 → 21 items overall), postponing the PDG mechanism usage till the Full launch period: | | | | | --- | --- | --- | | 1.17 | Revoke `CONFIG_MANAGER_ROLE` from Agent on `OracleDaemonConfig` | Clean up temporary permission | | **1.18** | **Grant `PausableUntilWithRoles.PauseRole` to Agent on `PredepositGurantee`** | **Temporary permission for PDG state update** | | **1.19** | **Pause `PredepositGurantee` indefinitely** | **Disable PDG-guided deposit flows** | | **1.20** | **Revoke `PausableUntilWithRoles.PauseRole` to Agent from `PredepositGurantee`** | **Clean up temporary permission** | | 1.21 | Call `V3Template.finishUpgrade()` | Finalize upgrade, migrate burner state, set external ratio | ---
**Author:** ![tamtamchik](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/tamtamchik/32/4064_2.png) [@tamtamchik](https://research.lido.fi/u/tamtamchik)\ **Post date:** [December 11, 2025, 8:44pm UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/10 "2025-12-11T20:44:12Z")
There are Lido V3 codebase audits published on the audits repository: - **Consensys Diligence [[diligence.security](https://diligence.security)]** - [Lido V3 On-chain audit report](https://github.com/lidofinance/audits/blob/main/Consensys%20Diligence%20Lido%20V3%20Security%20Audit%20-%2011-2025.pdf) - **MixBytes [[mixbytes.io](https://mixbytes.io)]** - [Lido V3 On-chain audit report and deployment verification](https://github.com/lidofinance/audits/blob/main/MixBytes%20Lido%20V3%20Security%20Audit%20Report%20-%2012-2025.pdf) - [Easy Track factories for stVaults Committee audit report](https://github.com/lidofinance/audits/blob/main/MixBytes%20Lido%20V3%20Easy%20Track%20Security%20Audit%20Report%20-%2012-2025.pdf) - **Certora [[certora.com](https://www.certora.com/)]** - [Lido V3 On-chain audit report](https://github.com/lidofinance/audits/blob/main/Certora%20Lido%20V3%20Audit%20Report%20-%2012-2025.pdf) - [Lido V3 Formal verification report](https://github.com/lidofinance/audits/blob/main/Certora%20Lido%20V3%20Formal%20Verification%20Report%20-%2012-2025.pdf) - [Lido V3 Off-chain audit report (Oracle V7)](https://github.com/lidofinance/audits/blob/main/Certora%20Lido%20V3%20Oracle%20V7%20Audit%20Report%20-%2012-2025.pdf) - **Composable Security [[composable-security.com](https://composable-security.com/)]** - [Lido V3 Off-chain audit report (Oracle V7)](https://github.com/lidofinance/audits/blob/main/Composable%20Security%20Lido%20V3%20Oracle%20V7%20Audit%20Report%20-%2012-2025.pdf) All audits with total issues and statuses are published at [https://docs.lido.fi/security/audits](https://docs.lido.fi/security/audits). ---
**Author:** ![ichi](https://avatars.discourse-cdn.com/v4/letter/i/e9a140/32.png) [@ichi](https://research.lido.fi/u/ichi)\ **Post date:** [December 14, 2025, 6:06am UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/11 "2025-12-14T06:06:46Z")
Thanks for the detailed proposal — this is one of the clearer attempts I’ve seen to reconcile Lido’s scale with its decentralization goals in a concrete, implementable way. What I find most compelling in the v3 design is that it doesn’t treat modularity as an abstract principle, but as an incentive-aligned mechanism: different staking modules can evolve independently while still being evaluated under a common risk and performance framework. That feels like a necessary step given Lido’s current size. One area I’d like to understand better is how “soft” versus “hard” governance boundaries are expected to work in practice. For example, when a module underperforms or exhibits elevated risk, is the intention that corrective action is primarily automated (through weights, caps, or incentives), or governance-driven (via explicit DAO intervention)? My concern is not about either approach individually, but about clarity: ambiguity here could lead to delayed responses in high-stress scenarios. I also think v3 raises an important cultural question for the DAO. As more logic moves on-chain and becomes algorithmic, governance risks shifting from _decision-making_ to _parameter-setting_. That’s not necessarily bad, but it does place a higher burden on transparency around why certain parameters exist and how often they’re expected to change. Overall, I’m supportive of the direction. If executed well, v3 could make Lido more resilient not by reducing complexity, but by making complexity more legible and governable. ---
**Author:** ![ichi](https://avatars.discourse-cdn.com/v4/letter/i/e9a140/32.png) [@ichi](https://research.lido.fi/u/ichi)\ **Post date:** [December 14, 2025, 6:10am UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/12 "2025-12-14T06:10:07Z")
One follow-up thought: v3 seems to implicitly assume that risk can be continuously quantified and priced across modules. That’s a strong and reasonable assumption, but it also depends heavily on the quality of inputs and the community’s tolerance for model error. It might be worth explicitly acknowledging this uncertainty in the design and baking in expectations around iteration and correction. In other words, treating early versions of v3 not as “correct by design,” but as intentionally adjustable as real-world behavior diverges from assumptions. Making that mindset explicit could help prevent overconfidence in the framework and encourage healthier governance engagement over time. ---
**Author:** ![nikita.p](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/nikita.p/32/5751_2.png) [@nikita.p](https://research.lido.fi/u/nikita.p)\ **Post date:** [December 15, 2025, 12:31pm UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/13 "2025-12-15T12:31:47Z")
**The [Vote #194 - Lido V3: Phase 1 (Soft Launch)](https://vote.lido.fi/vote/194) has started!** The vote will be open for your “For” or “Against” input until the end of the main phase: **Dec 18, 12:04 UTC.** For instructions on how to verify the vote items, please follow [this guide](https://enchanted-direction-844.notion.site/How-to-check-the-Lido-DAO-on-chain-vote-194-Lido-V3-Phase-1-Soft-Launch-2c2bf633d0c980d9878adf55df6e36cd). ---
**Author:** ![nikita.p](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/nikita.p/32/5751_2.png) [@nikita.p](https://research.lido.fi/u/nikita.p)\ **Post date:** [December 24, 2025, 3:32pm UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/14 "2025-12-24T15:32:41Z")
# Lido V3 Phase 1 Is Live ### TL;DR The [Dual Governance proposal #6](https://dg.lido.fi/proposals/6), submitted via [Vote #194](https://vote.lido.fi/vote/194), has passed and been enacted. **Lido V3 Phase 1 is now live on mainnet in soft-launch mode.** ### What’s Live Lido V3 and stVaults are now available on mainnet for partners, enabling early integrations and real-world testing ahead of full launch. ### Phase 1 Scope & Limits During the soft launch: - **Predeposit Guarantee (PDG)** remains disabled — users should interact only with trusted node operators. - **UI, API, and SDK** are not yet live; vaults are managed via CLI, direct contract interaction, or custom integrations. - Phase 1 limits apply, including a ~300k stETH global minting cap and permissioned node operators only. ### What’s Next The **full Lido V3 launch (Phase 2)** is expected in **late January or early February** , bringing advanced functionality and broader public access. Stay tuned and thanks for your patience as Lido V3 rolls out 💙 ---
**Author:** ![TheDZhon](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/thedzhon/32/800_2.png) [@TheDZhon](https://research.lido.fi/u/TheDZhon)\ **Post date:** [January 14, 2026, 9:20pm UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/15 "2026-01-14T21:20:32Z")
## Lido V3: Phase 2 voting (Full Launch) Hi everyone! Following the successful Lido V3: Phase 1 (soft launch), we’re ready to kick off the **Phase 2 (Full Launch)** governance process for Lido V3 and stVaults. ## TL;DR - **Phase 2 unlocks** : - PDG on mainnet (now hardened and production-ready) - Global stVaults minting limit raised to ~3M ETH (via 30% max external ratio) - stVaults UI + DeFi wrapper rollout + broader API/SDK components - Governance tooling refresh (updated Easy Track factories for stVaults Committee operations) - **Tentative timeline** - On-chain voting start: Jan 20, 2026 - Expected enactment: ~Jan 29, 2026 (subject to the vote outcome + execution scheduling) ## Context (Phase 1 → Phase 2) Phase 1 has been live on mainnet in soft-launch mode since late December. It intentionally shipped with conservative guardrails: - Predeposit Guarantee (PDG) was disabled - UI / API / SDK were not live (partners used CLI / direct contract interaction / custom integrations) - A conservative ~300k stETH global minting cap and permissioned trusted-mode node operators were used for the initial rollout Since Phase 1 went live (including the initial stETH minting capacity allocation for the first 22 Node Operators on Dec 29), we’ve had **no incidents on Lido V3** , and the system has been behaving as expected. This phased approach is intentional: as [discussed in the original proposal](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665), early versions of Lido V3 are meant to be _iterated on and adjusted_ as real-world usage provides better signals about risk, demand, and operational constraints. ## PDG is hardened and production-ready The Predeposit Guarantee (PDG) is now ready for mainnet usage, following an [additional audit/review by Sigma Prime](https://github.com/lidofinance/audits?tab=readme-ov-file#01-2026-sigma-prime-lido-bls-library-security-audit) of the updated underlying BLS library. PDG enables: - Non-custodial validator depositing - Smoother validator top-ups - Leveraged staking flows (e.g., via flash loans), where applicable > PDG has also been already re-enabled on the **Hoodi testnet** and can be tested end-to-end. ## Full launch deliverables Phase 2 is the “full launch” package, completing the items we previously communicated to partners: - **Higher global minting capacity** : set Lido’s **max external ratio to 30%** , bringing the global minting limit to roughly **~3M ETH** (≈30% of Lido Core TVL). - **stVaults UI + DeFi wrapper + broader components** : rolling out the UI and wrapper components promised for the full release, making integrations and day‑to‑day operations significantly easier. - **Updated governance tooling** : refresh of stVaults Committee Easy Track factories to the new versions and updated permissions wiring. ## Voting items The Phase 2 vote contains: - A **Dual Governance (DG) proposal** containing actions **1.1–1.13** (the core protocol changes) - A **Lido DAO on-chain vote** with items **1–15** that submits the DG proposal and updates Easy Track factories ### New deployments | Contract | Address | Repository | Description | | --- | --- | --- | --- | | PDG (Predeposit Guarantee) — new implementation | [`0xE78717192C45736DF0E4be55c0219Ee7f9aDdd0D`](https://etherscan.io/address/0xE78717192C45736DF0E4be55c0219Ee7f9aDdd0D) | [`lidofinance/core@33f2f59`](https://github.com/lidofinance/core/commit/33f2f59156697aae93cdea2d0984de7be347e3af) | New PDG implementation for Phase 2 | | RegisterGroupsInOperatorGrid (Phase 2 and 3) | [`0xE73842AEbEC99Dacf2aAEec61409fD01A033f478`](https://etherscan.io/address/0xE73842AEbEC99Dacf2aAEec61409fD01A033f478) | [`lidofinance/easy-track@aa2f545`](https://github.com/lidofinance/easy-track/commit/aa2f5456962dbd8f8599d1450fd8a576b84ade34) | Easy Track factory for Phases 2/3 | | UpdateGroupsShareLimitInOperatorGrid (Phase 2 and 3) | [`0xf23559De8ab37fF7a154384B0822dA867Cfa7Eac`](https://etherscan.io/address/0xf23559De8ab37fF7a154384B0822dA867Cfa7Eac) | [`lidofinance/easy-track@aa2f545`](https://github.com/lidofinance/easy-track/commit/aa2f5456962dbd8f8599d1450fd8a576b84ade34) | Easy Track factory for Phases 2/3 | | AlterTiersInOperatorGrid (Phase 2 and 3) | [`0x73f80240ad9363d5d3C5C3626953C351cA36Bfe9`](https://etherscan.io/address/0x73f80240ad9363d5d3C5C3626953C351cA36Bfe9) | [`lidofinance/easy-track@aa2f545`](https://github.com/lidofinance/easy-track/commit/aa2f5456962dbd8f8599d1450fd8a576b84ade34) | Easy Track factory for Phases 2/3 | | VaultsAdapter (contract code changes) | [`0x28F9Ac198C4E0FA6A9Ad2c2f97CB38F1A3120f27`](https://etherscan.io/address/0x28F9Ac198C4E0FA6A9Ad2c2f97CB38F1A3120f27) | [`lidofinance/easy-track@aa2f545`](https://github.com/lidofinance/easy-track/commit/aa2f5456962dbd8f8599d1450fd8a576b84ade34) | Adapter used by factories | | SetJailStatusInOperatorGrid | [`0x6a4f33F05E7412A11100353724Bb6a152Cf0D305`](https://etherscan.io/address/0x6a4f33F05E7412A11100353724Bb6a152Cf0D305) | [`lidofinance/easy-track@aa2f545`](https://github.com/lidofinance/easy-track/commit/aa2f5456962dbd8f8599d1450fd8a576b84ade34) | Redeployed Easy Track factory | | UpdateVaultsFeesInOperatorGrid | [`0xDfA0bc38113B6d53c2881573FD764CEEFf468610`](https://etherscan.io/address/0xDfA0bc38113B6d53c2881573FD764CEEFf468610) | [`lidofinance/easy-track@aa2f545`](https://github.com/lidofinance/easy-track/commit/aa2f5456962dbd8f8599d1450fd8a576b84ade34) | Redeployed Easy Track factory | | ForceValidatorExitsInVaultHub | [`0x6F5c0A5a824773E8f8285bC5aA59ea0Aab2A6400`](https://etherscan.io/address/0x6F5c0A5a824773E8f8285bC5aA59ea0Aab2A6400) | [`lidofinance/easy-track@aa2f545`](https://github.com/lidofinance/easy-track/commit/aa2f5456962dbd8f8599d1450fd8a576b84ade34) | Redeployed Easy Track factory | | SocializeBadDebtInVaultHub | [`0xaf35A63a4114B7481589fDD9FDB3e35Fd65fAed7`](https://etherscan.io/address/0xaf35A63a4114B7481589fDD9FDB3e35Fd65fAed7) | [`lidofinance/easy-track@aa2f545`](https://github.com/lidofinance/easy-track/commit/aa2f5456962dbd8f8599d1450fd8a576b84ade34) | Redeployed Easy Track factory | ### Deployment parameters Below are the key deployment parameters used for verification. **New PDG implementation** | Component | Address | Parameters (constructor/proxy) | | --- | --- | --- | | PDG implementation (new) | `0xE78717192C45736DF0E4be55c0219Ee7f9aDdd0D` | Constructor args: `0x00000000`, `0x0000000000000000000000000000000000000000000000000096000000000028`, `0x0000000000000000000000000000000000000000000000000096000000000028`, `0` | **New Easy Track factories (stVaults Committee)** | Contract / factory | Address | Constructor parameters | | --- | --- | --- | | stVaults Committee | `0x18A1065c81b0Cc356F1b1C843ddd5E14e4AefffF` | Committee used by the factories below | | VaultsAdapter (new) | `0x28F9Ac198C4E0FA6A9Ad2c2f97CB38F1A3120f27` | `committee=0x18A1065c81b0Cc356F1b1C843ddd5E14e4AefffF`, `lidoLocator=0xC1d0b3DE6792Bf6b4b37EccdcC24e45978Cfd2Eb`, `0xFE5986E06210aC1eCC1aDCafc0cc7f8D63B3F977`, `0.1 ETH` | | AlterTiersInOperatorGrid (new) | `0x73f80240ad9363d5d3C5C3626953C351cA36Bfe9` | `committee=0x18A1065c81b0Cc356F1b1C843ddd5E14e4AefffF`, `lidoLocator=0xC1d0b3DE6792Bf6b4b37EccdcC24e45978Cfd2Eb`, `limit=1_000_000e18` | | RegisterGroupsInOperatorGrid (new) | `0xE73842AEbEC99Dacf2aAEec61409fD01A033f478` | `committee=0x18A1065c81b0Cc356F1b1C843ddd5E14e4AefffF`, `lidoLocator=0xC1d0b3DE6792Bf6b4b37EccdcC24e45978Cfd2Eb`, `limit=1_000_000e18` | | UpdateGroupsShareLimitInOperatorGrid (new) | `0xf23559De8ab37fF7a154384B0822dA867Cfa7Eac` | `committee=0x18A1065c81b0Cc356F1b1C843ddd5E14e4AefffF`, `lidoLocator=0xC1d0b3DE6792Bf6b4b37EccdcC24e45978Cfd2Eb`, `limit=1_000_000e18` | | SetJailStatusInOperatorGrid (new) | `0x6a4f33F05E7412A11100353724Bb6a152Cf0D305` | `committee=0x18A1065c81b0Cc356F1b1C843ddd5E14e4AefffF`, `vaultsAdapter=0x28F9Ac198C4E0FA6A9Ad2c2f97CB38F1A3120f27` | | SocializeBadDebtInVaultHub (new) | `0xaf35A63a4114B7481589fDD9FDB3e35Fd65fAed7` | `committee=0x18A1065c81b0Cc356F1b1C843ddd5E14e4AefffF`, `vaultsAdapter=0x28F9Ac198C4E0FA6A9Ad2c2f97CB38F1A3120f27` | | ForceValidatorExitsInVaultHub (new) | `0x6F5c0A5a824773E8f8285bC5aA59ea0Aab2A6400` | `committee=0x18A1065c81b0Cc356F1b1C843ddd5E14e4AefffF`, `vaultsAdapter=0x28F9Ac198C4E0FA6A9Ad2c2f97CB38F1A3120f27` | | UpdateVaultsFeesInOperatorGrid (new) | `0xDfA0bc38113B6d53c2881573FD764CEEFf468610` | `committee=0x18A1065c81b0Cc356F1b1C843ddd5E14e4AefffF`, `vaultsAdapter=0x28F9Ac198C4E0FA6A9Ad2c2f97CB38F1A3120f27`, `lidoLocator=0xC1d0b3DE6792Bf6b4b37EccdcC24e45978Cfd2Eb`, `1000`, `0`, `100` | ### Dual Governance proposal (core Phase 2 activation) - **1.1.** Revoke `vaults.OperatorsGrid.Registry` role `a495a3428837724c7f7648cda02eb83c9c4c778c8688d6f254c7f3f80c154d55` on OperatorGrid `0xC69685E89Cefc327b43B7234AC646451B27c544d` from old VaultsAdapter `0xe2DE6d2DefF15588a71849c0429101F8ca9FB14D` - **1.2.** Grant `vaults.OperatorsGrid.Registry` role `a495a3428837724c7f7648cda02eb83c9c4c778c8688d6f254c7f3f80c154d55` on OperatorGrid `0xC69685E89Cefc327b43B7234AC646451B27c544d` to new VaultsAdapter `0x28F9Ac198C4E0FA6A9Ad2c2f97CB38F1A3120f27` - **1.3.** Revoke `vaults.VaultHub.ValidatorExitRole` role `2159c5943234d9f3a7225b9a743ea06e4a0d0ba5ed82889e867759a8a9eb7883` on VaultHub `0x1d201BE093d847f6446530Efb0E8Fb426d176709` from old VaultsAdapter `0xe2DE6d2DefF15588a71849c0429101F8ca9FB14D` - **1.4.** Grant `vaults.VaultHub.ValidatorExitRole` role `2159c5943234d9f3a7225b9a743ea06e4a0d0ba5ed82889e867759a8a9eb7883` on VaultHub `0x1d201BE093d847f6446530Efb0E8Fb426d176709` to new VaultsAdapter `0x28F9Ac198C4E0FA6A9Ad2c2f97CB38F1A3120f27` - **1.5.** Revoke `vaults.VaultHub.BadDebtMasterRole` role `a85bab4b576ca359fa6ae02ab8744b5c85c7e7ed4d7e0bca7b5b64580ac5d17d` on VaultHub `0x1d201BE093d847f6446530Efb0E8Fb426d176709` from old VaultsAdapter `0xe2DE6d2DefF15588a71849c0429101F8ca9FB14D` - **1.6.** Grant `vaults.VaultHub.BadDebtMasterRole` role `a85bab4b576ca359fa6ae02ab8744b5c85c7e7ed4d7e0bca7b5b64580ac5d17d` on VaultHub `0x1d201BE093d847f6446530Efb0E8Fb426d176709` to new VaultsAdapter `0x28F9Ac198C4E0FA6A9Ad2c2f97CB38F1A3120f27` - **1.7.** Update PredepositGuarantee proxy `0xF4bF42c6D6A0E38825785048124DBAD6c9eaaac3` implementation to `0xE78717192C45736DF0E4be55c0219Ee7f9aDdd0D` - **1.8.** Temporarily grant `PausableUntilWithRoles.ResumeRole` `a79a6aede309e0d48bf2ef0f71355c06ad317956d4c0da2deb0dc47cc34f826c` on PredepositGuarantee `0xF4bF42c6D6A0E38825785048124DBAD6c9eaaac3` to Agent `0x3e40D73EB977Dc6a537aF587D48316feE66E9C8c` - **1.9.** Unpause PredepositGuarantee `0xF4bF42c6D6A0E38825785048124DBAD6c9eaaac3` - **1.10.** Revoke `PausableUntilWithRoles.ResumeRole` `a79a6aede309e0d48bf2ef0f71355c06ad317956d4c0da2deb0dc47cc34f826c` on PredepositGuarantee `0xF4bF42c6D6A0E38825785048124DBAD6c9eaaac3` from Agent `0x3e40D73EB977Dc6a537aF587D48316feE66E9C8c` - **1.11.** Temporarily grant `STAKING_CONTROL_ROLE` `a42eee1333c0758ba72be38e728b6dadb32ea767de5b4ddbaea1dae85b1b051f` on Lido `0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84` to Agent `0x3e40D73EB977Dc6a537aF587D48316feE66E9C8c` - **1.12.** Set max external ratio to `30%` on Lido `0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84` - **1.13.** Revoke `STAKING_CONTROL_ROLE` `a42eee1333c0758ba72be38e728b6dadb32ea767de5b4ddbaea1dae85b1b051f` on Lido `0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84` from Agent `0x3e40D73EB977Dc6a537aF587D48316feE66E9C8c` ### Lido DAO on-chain vote (what changes on-chain in the vote) - **1.** Submit a Dual Governance proposal to activate Lido V3 Phase 2 - **2.** Remove old `ALTER_TIERS_IN_OPERATOR_GRID_FACTORY` `0xa29173C7BCf39dA48D5E404146A652d7464aee14` from Easy Track `0xF0211b7660680B49De1A7E9f25C65660F0a13Fea` - **3.** Add new `ALTER_TIERS_IN_OPERATOR_GRID_FACTORY` `0x73f80240ad9363d5d3C5C3626953C351cA36Bfe9` to Easy Track `0xF0211b7660680B49De1A7E9f25C65660F0a13Fea` (permissions: operatorGrid.alterTiers `0xc69685e89cefc327b43b7234ac646451b27c544d54544bcb`) - **4.** Remove old `REGISTER_GROUPS_IN_OPERATOR_GRID_FACTORY` `0x194A46DA1947E98c9D79af13E06Cfbee0D8610cC` from Easy Track `0xF0211b7660680B49De1A7E9f25C65660F0a13Fea` - **5.** Add new `REGISTER_GROUPS_IN_OPERATOR_GRID_FACTORY` `0xE73842AEbEC99Dacf2aAEec61409fD01A033f478` to Easy Track `0xF0211b7660680B49De1A7E9f25C65660F0a13Fea` (permissions: operatorGrid.registerGroup, operatorGrid.registerTiers `0xc69685e89cefc327b43b7234ac646451b27c544de37a7c0bc69685e89cefc327b43b7234ac646451b27c544d552b91da`) - **6.** Remove old `UPDATE_GROUPS_SHARE_LIMIT_IN_OPERATOR_GRID_FACTORY` `0x8Bdc726a3147D8187820391D7c6F9F942606aEe6` from Easy Track `0xF0211b7660680B49De1A7E9f25C65660F0a13Fea` - **7.** Add new `UPDATE_GROUPS_SHARE_LIMIT_IN_OPERATOR_GRID_FACTORY` `0xf23559De8ab37fF7a154384B0822dA867Cfa7Eac` to Easy Track `0xF0211b7660680B49De1A7E9f25C65660F0a13Fea` (permissions: operatorGrid.updateGroupShareLimit `0xc69685e89cefc327b43b7234ac646451b27c544de52b6085`) - **8.** Remove old `SET_JAIL_STATUS_IN_OPERATOR_GRID_FACTORY` `0x93F1DEE4473Ee9F42c8257C201e33a6Da30E5d67` from Easy Track `0xF0211b7660680B49De1A7E9f25C65660F0a13Fea` - **9.** Add new `SET_JAIL_STATUS_IN_OPERATOR_GRID_FACTORY` `0x6a4f33F05E7412A11100353724Bb6a152Cf0D305` to Easy Track `0xF0211b7660680B49De1A7E9f25C65660F0a13Fea` (permissions: vaults\_adapter.setVaultJailStatus `0x28f9ac198c4e0fa6a9ad2c2f97cb38f1a3120f27285f591c`) - **10.** Remove old `SOCIALIZE_BAD_DEBT_IN_VAULT_HUB_FACTORY` `0x1dF50522A1D868C12bF71747Bb6F24A18Fe6d32C` from Easy Track `0xF0211b7660680B49De1A7E9f25C65660F0a13Fea` - **11.** Add new `SOCIALIZE_BAD_DEBT_IN_VAULT_HUB_FACTORY` `0xaf35A63a4114B7481589fDD9FDB3e35Fd65fAed7` to Easy Track `0xF0211b7660680B49De1A7E9f25C65660F0a13Fea` (permissions: vaults\_adapter.socializeBadDebt `0x28f9ac198c4e0fa6a9ad2c2f97cb38f1a3120f2796c4d514`) - **12.** Remove old `FORCE_VALIDATOR_EXITS_IN_VAULT_HUB_FACTORY` `0x6C968cD89CA358fbAf57B18e77a8973Fa869a6aA` from Easy Track `0xF0211b7660680B49De1A7E9f25C65660F0a13Fea` - **13.** Add new `FORCE_VALIDATOR_EXITS_IN_VAULT_HUB_FACTORY` `0x6F5c0A5a824773E8f8285bC5aA59ea0Aab2A6400` to Easy Track `0xF0211b7660680B49De1A7E9f25C65660F0a13Fea` (permissions: vaults\_adapter.forceValidatorExit `0x28f9ac198c4e0fa6a9ad2c2f97cb38f1a3120f2733eb1f1a`) - **14.** Remove old `UPDATE_VAULTS_FEES_IN_OPERATOR_GRID_FACTORY` `0x5C3bDFa3E7f312d8cf72F56F2b797b026f6B471c` from Easy Track `0xF0211b7660680B49De1A7E9f25C65660F0a13Fea` - **15.** Add new `UPDATE_VAULTS_FEES_IN_OPERATOR_GRID_FACTORY` `0xDfA0bc38113B6d53c2881573FD764CEEFf468610` to Easy Track `0xF0211b7660680B49De1A7E9f25C65660F0a13Fea` (permissions: vaults\_adapter.updateVaultFees `0x28f9ac198c4e0fa6a9ad2c2f97cb38f1a3120f27ed7139a7`) ## Implementation highlights (BLS + Oracle) - **BLS library parity with CL deposit signature verification** : the deployment includes improvements to the BLS library to better match consensus-layer expectations by failing explicitly on malformed deposit signature data during its verification. See the core reference: [`lidofinance/core@33f2f59`](https://github.com/lidofinance/core/commit/33f2f59156697aae93cdea2d0984de7be347e3af). - **Oracle fee reporting** : aligned with a time-based (timestamp) model rather than block-number-based, improving correctness under missing-block conditions. ## Tentative timeline - **Jan 20** : Phase 2 vote goes live on mainnet - **~Jan 29** : expected enactment/execution window (assuming the vote and DG challenge period pass) - **Post-enactment** : PDG enabled on mainnet under the hardened implementation; UI + DeFi wrapper rollout continues ## What’s next - Updated audit reports and a 3rd-party deployment verification note will be shared shortly in the thread before the vote starts - **stVaults onboarding continues** — Node Operators can apply by following the [stVaults Node Operators Identification guide](https://docs.lido.fi/run-on-lido/stvaults/operational-and-management-guides/node-operators-identification/) - We’ll keep monitoring Phase 2 in production and propose further parameter adjustments where needed * * * If you have questions, integration proposals, or co-marketing plans around the full launch, please reach out — happy to sync. Happy building! 💧 💙 ---
**Author:** ![tamtamchik](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/tamtamchik/32/4064_2.png) [@tamtamchik](https://research.lido.fi/u/tamtamchik)\ **Post date:** [January 15, 2026, 7:44pm UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/16 "2026-01-15T19:44:18Z")
**Lido V3 Phase 2 audits finalized:** - SigmaPrime’s Review of Onchain BLS Library [audits/Sigma Prime - Lido BLS Library Security Assessment Report v2.0 - 01-2026.pdf at main · lidofinance/audits · GitHub](https://github.com/lidofinance/audits/blob/main/Sigma%20Prime%20-%20Lido%20BLS%20Library%20Security%20Assessment%20Report%20v2.0%20-%2001-2026.pdf) **Updated Lido V3 audits (incorporating BLS strengthen patch review):** - Consensys Diligence Lido V3 Security Audit [audits/Consensys Diligence Lido V3 Security Audit - 11-2025.pdf at main · lidofinance/audits · GitHub](https://github.com/lidofinance/audits/blob/main/Consensys%20Diligence%20Lido%20V3%20Security%20Audit%20-%2011-2025.pdf) - Certora Lido V3 Audit Report [audits/Certora Lido V3 Audit Report - 12-2025.pdf at main · lidofinance/audits · GitHub](https://github.com/lidofinance/audits/blob/main/Certora%20Lido%20V3%20Audit%20Report%20-%2012-2025.pdf) - MixBytes Lido V3 Security Audit Report [audits/MixBytes Lido V3 Security Audit Report - 12-2025.pdf at main · lidofinance/audits · GitHub](https://github.com/lidofinance/audits/blob/main/MixBytes%20Lido%20V3%20Security%20Audit%20Report%20-%2012-2025.pdf) - MixBytes Lido V3 EasyTrack Security Audit Report [audits/MixBytes Lido V3 Easy Track Security Audit Report - 12-2025.pdf at main · lidofinance/audits · GitHub](https://github.com/lidofinance/audits/blob/main/MixBytes%20Lido%20V3%20Easy%20Track%20Security%20Audit%20Report%20-%2012-2025.pdf) ---
**Author:** ![khanhwizardpa](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/khanhwizardpa/32/6622_2.png) [@khanhwizardpa](https://research.lido.fi/u/khanhwizardpa)\ **Post date:** [January 17, 2026, 9:21am UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/17 "2026-01-17T09:21:28Z")
> [@TheDZhon](#): > > stVaults onboarding How and where to follow **stVaults onboarding programs?** ---
**Author:** ![khanhwizardpa](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/khanhwizardpa/32/6622_2.png) [@khanhwizardpa](https://research.lido.fi/u/khanhwizardpa)\ **Post date:** [January 17, 2026, 9:22am UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/18 "2026-01-17T09:22:10Z")
And any strong condition required for apply. ---
**Author:** ![Kate\_Alekseeva](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/kate_alekseeva/32/4891_2.png) [@Kate\_Alekseeva](https://research.lido.fi/u/Kate_Alekseeva)\ **Post date:** [January 20, 2026, 11:19am UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/19 "2026-01-20T11:19:05Z")
**The [Vote #198](https://vote.lido.fi/vote/198) has started!** The vote will remain open for your “For” or “Against” input until the end of the main phase on **January 23 at 11:09 UTC.** For instructions on how to verify the vote items, please follow [this guide](https://enchanted-direction-844.notion.site/How-to-check-the-Lido-DAO-on-chain-vote-198-2ecbf633d0c9805685e8efe0281330f0). ---
**Author:** ![nikita.p](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/nikita.p/32/5751_2.png) [@nikita.p](https://research.lido.fi/u/nikita.p)\ **Post date:** [January 29, 2026, 1:56pm UTC](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665/20 "2026-01-29T13:56:12Z")
# Lido V3 Phase 2 (Full Launch) Is Live The [Dual Governance proposal #8](https://dg.lido.fi/proposals/8), submitted via [Vote #198](https://vote.lido.fi/vote/198), has passed and been enacted. **Lido V3 Phase 2 (Full Launch) is now live on mainnet!** [Next page](https://research.lido.fi/t/lido-v3-design-implementation-proposal/10665.md?page=2)