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
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
Hi all!
Here’s an update on Phase 3 of the stVaults rollout plan.
Phase 3 is expected to go live in early March 2026.
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%)
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
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:
LazyOracle: 0x96c9a897D116ef660086d3aA67b3af653324aB37Proposed items for the upcoming vote:
LazyOracle proxy 0x5DB427080200c235F2Ae8Cd17A7be87921f7AD6c implementation to 0x96c9a897D116ef660086d3aA67b3af653324aB37.Audit reports can be found here.
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.
The Dual Governance Proposal #9, submitted through on-chain vote #199, has been executed. Lazy Oracle has been upgraded.