Lido V3 — Design & Implementation Proposal

Hey, sorry for the delay!

You can find stVaults onboarding guide for node operators here: 📝 Identified Node Operators | Lido Docs

A guide for basic stVault with optional liquidity: 🧱 Basic stVault with optional liquidity | Lido Docs

2 Likes

:hammer_and_wrench: Update on Phase 3 of the stVaults Rollout Plan

Hi all!

Here’s an update on Phase 3 of the stVaults rollout plan.

:date: Timeline

Phase 3 is expected to go live in early March 2026.

:brick: Gradual Enablement of Permissionless Minting

To enhance protocol security, permissionless minting in stVaults will be introduced gradually. The minting limit for the Default Tier will be increased in phases:

  • At Phase 3 launch:

    5,000 stETH (equivalent to 10,000 ETH with a Reserve Ratio of 50%)

  • Later, based on demand:

    50,000 stETH (100,000 ETH with RR = 50%)

  • Eventually, based on demand:

    500,000 stETH (1,000,000 ETH with RR = 50%)

:puzzle_piece: Tier Upgrades for Identified Node Operators

With Phase 3, all Identified Node Operators (excluding custom setups) will receive upgraded stETH minting terms according to their assigned Category:

  • Higher per-operator stETH minting limits

  • Four additional tiers will be added to support more granular configurations

5 Likes

Hi everyone!

As a follow-up to the Lido V3 mainnet deployment, a bug fix has been identified and addressed in LazyOracle (PR #1730).

The _handleSanityChecks function contained a validation check _maxLiabilityShares > record.maxLiabilityShares that caused false reverts during oracle report processing. The root cause is that record.maxLiabilityShares can increase between the oracle snapshot refSlot and the moment the report is submitted on-chain — for example, due to new minting activity or a previous report trigger that updates the on-chain record. This made a valid report appear stale, blocking oracle updates.

The fix removes the upper-bound check, keeping only the necessary _maxLiabilityShares < _liabilityShares guard. VaultHub already enforces the relevant constraints independently at the time the report is applied, making the removed check redundant.

The updated implementation has been deployed:

Proposed items for the upcoming vote:

  1. Upgrade LazyOracle proxy 0x5DB427080200c235F2Ae8Cd17A7be87921f7AD6c implementation to 0x96c9a897D116ef660086d3aA67b3af653324aB37.

Audit reports can be found here.

3 Likes

The on-chain vote #199 is now live and includes the proposal to upgrade Lazy Oracle.

The vote will be open for your “For” or “Against” input until the end of the main phase: Apr 11, 15:51 UTC.

For instructions on how to verify the vote items, please follow this guide.

1 Like

The Dual Governance Proposal #9, submitted through on-chain vote #199, has been executed. Lazy Oracle has been upgraded.

2 Likes