Staking Router v3 — Design & Implementation Proposal (LIP-35)

Proposals
1

Staking Router v3 — Design & Implementation Proposal (LIP-35)

TL;DR

  • Staking Router v3 makes Lido Core ready for large validators. It is the foundational protocol upgrade that brings EIP-7251: Increase the MAX_EFFECTIVE_BALANCE to Lido’s core — letting a single validator hold up to 2048 ETH instead of the old 32 ETH cap.
  • Accounting moves from validator counts to balances. Today the protocol assumes 1 validator = 32 ETH. After the proposed upgrade, the protocol tracks each validator’s actual balance, so a validator holding up to 2048 ETH is accounted for and rewarded fairly.
  • New deposit flows: predeposits + top-ups. A new TopUpGateway lets the protocol top up 0x02 validators up to the 2048 ETH cap, secured by on-chain Merkle-proof verification of validator state rather than trust in any actor.
  • A consolidation pipeline to migrate stake from Curated Module v1 to Curated Module v2. A delayed, permissionlessly-executed, proof-verified flow that moves stake quickly and securely.
  • A deposit reserve for reliable stake rebalancing. Protects a portion of buffered ETH for CL deposits so withdrawal demand can’t starve migration and new-module onboarding.
  • A dedicated Easy Track factory for managing module share limits within pre-defined bounds.
  • The ask: we invite the community, node operators, and integrators to review the full specification and share feedback before this moves to a vote.

:page_facing_up: Full specification: LIP-35. Staking Router v3

Intro

Before the Pectra upgrade, every Ethereum validator had a fixed maximum effective balance of 32 ETH. That let Lido use a very simple accounting model: count validators, multiply by 32, and you have the stake on the Consensus Layer.

EIP-7251 changed this. Validators with 0x02 withdrawal credentials can now hold an effective balance anywhere from 32 up to 2048 ETH, and can be topped up and consolidated. A validator with 2048 ETH generates 64× the rewards of a 32 ETH validator — but Lido’s current count-based accounting treats them identically.

This breaks several core assumptions at once:

  • Rewards calculation — the protocol doesn’t know how much ETH is actually working on the CL.
  • Stake distribution — allocation between modules is based on validator count, not actual balance.
  • totalPooledEther — the key input to the stETH rate becomes inaccurate.

Staking Router v3 is the upgrade that resolves all of this and unlocks a more flexible, efficient protocol: the ability to reallocate stake between modules via consolidations, support deposits into large validators, and lay the groundwork for leaner validator management overall.

Motivation

  • The foundational base layer for the next protocol upgrades. Staking Router v3 is the base layer that LIP-33: Community Staking Module v3 and Curated Module v2 builds on.
  • Fast, secure stake migration from Curated Module v1 to Curated Module v2. The consolidation pipeline provides a transparent, proof-verified way to migrate stake with minimal inefficiency.

Design

The proposal reworks several core components. Here is the high-level map; the full LIP covers each in detail.

  • Balance-based accounting. Lido stops storing clBalance / clValidators and instead tracks active validator balances and pending deposits; rewards are distributed per-module balance, and Pectra’s EIP-6110 lets the oracle drop the virtual “transient balance” entirely.
  • Deposits — a pull model with predeposits & top-ups. The Staking Router pulls ETH from Lido as needed (instead of Lido pushing it), and a new TopUpGateway enables top-ups of active 0x02 validators up to 2048 ETH, gated by on-chain Merkle proofs of CL state. Each module supports only one key type (0x01 or 0x02).
  • Consolidation pipeline (CMv1 → CMv2). An Easy Track motion authorizes source->target operator consolidation. Node operators submit consolidation requests, and after an execution delay a permissionless executor pushes a proof-verified batch through the independently-pausable Consolidation Gateway to the Withdrawal Vault and the EIP-7251 system contract.
  • Deposit reserve. A governance-configured slice of buffered ETH is reserved for CL deposits and protected from withdrawal demand, guaranteeing ETH for migration deposits and new-module onboarding.
  • Balance-based validator exits. Validators Exit Bus Oracle carries the key index so key type is known on-chain, and sanity checks and exit-rate limits are bound by total effective balance (32 / 2048 ETH) rather than validator count.
  • Module Shares Easy Track factory. A dedicated factory adjusts a module’s stakeShareLimit and priorityExitShare within pre-defined bounds, backed by a narrowly-scoped new role instead of the broad STAKING_MODULE_MANAGE_ROLE.

Security

Both new ETH-moving flows anchor their security on on-chain Merkle proofs of CL state, not trust in the caller:

  • Consolidations verify the target validator’s withdrawal credentials on-chain; the source is guaranteed by the EIP-7251 system contract, since the request is signed by the Withdrawal Vault — the canonical WC for all Lido core validators.
  • Top-ups verify the target’s WC on-chain, so a top-up can’t be routed to a non-Lido validator even if a predeposit front-run slipped past the DSM. Per-validator limits are forced to zero for slashed/exiting/exited validators.
  • The topUp method is gated to the authorized Lido Depositor Bot; combined with the pausable TopUpGateway, a per-block top-up cap, minimum block distance between calls, and automatic skimming of any excess, the worst case of bot misbehavior is bounded to a recoverable inefficiency — not a loss of funds.

The full set of trade-offs (including deposit-reserve sizing) is in the Security Considerations section.

Implementation

Current status

  • Code: onchain feature-complete; offchain components (including oracles, DSM and depositor bot) updated.

  • Audits: To ensure security, Staking Router V3 is undergoing extensive audits by multiple independent firms (each focusing on different aspects):

    • Certora: Specification review + on-chain code audit
    • Statemind: on-chain code audit
    • Composable Security: deep off-chain oracle review, threat models
    • MixBytes: Voting script audit, Easy Tracks audit

    As of this writing, several interim audit reports have already been delivered, with all audits being targeted to conclude by begin-July 2026.

  • Testing: public testnets and multiple internal devnets; public testnet which involved node operators testing consolidations currently in progress, and planned to be finished by the end of June.

Rollout plan

The Accounting transition happens in a single transaction at voting enactment. The stake migration, however, takes several months: stake moves from Curated Module v1 (CMv1) to Curated Module v2 (CMv2) gradually, without forcing exits. Both modules stay live throughout, and CMv1 keeps depositable capacity until migration is complete as a safety fallback.

  • Period 1 — CMv2 launch. CMv2 goes live alongside CMv1 (both at 100% share limit). Operators set up their on-chain entities and upload keys, and CMv2 gets top priority for new seed deposits; overflow falls back to CMv1/CSM by priority. Top-ups are off. Consolidations can start once the first CMv2 validators are active.
  • Period 1.5 — CMv1 → CMv2 transition. Same parameters as Period 1, but top-ups are enabled and consolidations are underway. If CMv2 runs short on capacity, deposits can still go to CMv1.
  • Period 2 — full switch to CMv2. Once CMv2 has enough capacity, CMv1’s share limit drops to 0%: it stops taking new stake and is drawn down via withdrawal-driven exits until empty. Top-ups and consolidations continue.

More details about stake migration can be found in the Deposits and Consolidations Technical Plan.

Next steps

We invite the community to provide feedback on this proposal and the Staking Router 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 Staking Router V3 upgrade.

Tentative timeline

  • Late June 2026: Barring objections, initiate a Snapshot vote for signaling support of Staking Router V3.
  • July 2026:
    • 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.
    • If Snapshot support is positive, deploy the Staking Router V3 contracts to the mainnet, upgrading the main Lido mainnet instance.
    • 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.
    • Enactment of Staking Router V3 upgrade on mainnet, assuming the on-chain vote passes. Contracts will be upgraded, and the new modules (Consolidation flow, TopUpGateway, etc.) will be initialized. Stake migration Period 1 begins immediately at this point.
  • Oct 2026: If everything runs smoothly, transition to stake migration Period 1.5
  • December 2026: Target for transition to stake migration Period 2
  • ~Q1 2027: Stake migrated to CMv2, sunset of CMv1

Note: timing remains subject to security and operational readiness.

Reference materials

For those who want to dive deeper:

14 Likes
2

Staking Router v3 — Suggested deploy parameter values (LIP-35)

Following up on LIP-35, I want to suggest deploy parameter values for the contracts touched by the upgrade. They are listed below as ready-to-use deploy params, grouped by contract. Each group carries a short note and a link to the detailed document with the reasoning behind the specific numbers; the full design rationale lives in LIP-35.

The gist: these are the suggested values; the detailed methodology, risk/loss models and parameter sizing are in the linked documents.

Deploy params

Lido

Deposit reserve target. Details: Deposit Reserve value.

lidoDepositsReserveTarget = 1500000000000000000000     # Deposits reserve target (1500 ETH in wei)

StakingRouter

Top-up per-block cap. Details: LIP-35 Top-Up Limits.

_maxTopUpPerBlockGwei = 3200000000000                  # Maximum total ETH that can be topped up in a single block (3200 ETH)

ValidatorsExitBusOracle

Only adapted from validator count to ETH. Details: TW limits (incl. SRv3 update for 0x02).

maxValidatorsPerReport = 600                           # Maximum number of validator exit requests per oracle report
maxExitBalanceEth = 358400                             # Maximum cumulative ETH of validators referenced in exit requests
balancePerFrameEth = 32                                # ETH amount restored to the exit-balance bucket per frame
frameDurationInSec = 48                                # Duration of each refill frame, in seconds

OracleReportSanityChecker

Details: SRv3. Sanity checks: VEBO, AO.

exitedEthAmountPerDayLimit = 57600                     # Exited ETH amount per day limit
appearedEthAmountPerDayLimit = 57600                   # Appeared ETH amount per day limit
deprecatedOneOffCLBalanceDecreaseBPLimit = 500         # Deprecated one-off CL balance decrease limit (BP)
annualBalanceIncreaseBPLimit = 1000                    # Annual balance increase limit (BP)
simulatedShareRateDeviationBPLimit = 250               # Simulated share rate deviation limit (BP)
maxBalanceExitRequestedPerReportInEth = 19200          # Maximum exit ETH per report (600*32)
maxEffectiveBalanceWeightWCType01 = 32                 # maxEB equivalent weight for WC type 1
maxEffectiveBalanceWeightWCType02 = 2048               # maxEB equivalent weight for WC type 2
maxItemsPerExtraDataTransaction = 8                    # Maximum items per extra data transaction
maxNodeOperatorsPerExtraDataItem = 24                  # Maximum node operators per extra data item
requestTimestampMargin = 128                           # Request timestamp margin
maxPositiveTokenRebase = 750000                        # Maximum positive token rebase
maxCLBalanceDecreaseBP = 360                           # Max CL balance decrease over sliding window (BP, 360 = 3.6%)
clBalanceOraclesErrorUpperBPLimit = 50                 # CL balance oracles error upper limit (BP)
consolidationEthAmountPerDayLimit = 93375              # Consolidation ETH amount per day limit
exitedValidatorEthAmountLimit = 32                     # Exited validator ETH amount limit in ETH units
externalPendingBalanceCapEth = 300                     # Extra external pending balance cap for bounded side deposits / top-ups

ConsolidationGateway

Details: ConsolidationGateway limits.

maxConsolidationRequestsLimit = 2900                   # Max consolidation requests accepted before rate-limit applies
consolidationsPerFrame = 1                             # Number of consolidations processed per frame
frameDurationInSec = 30                                # Frame duration used for limit refill (seconds)

ConsolidationBus

Details: Consolidation Bus — request limits.

initialBatchSize = 200                                 # Maximum number of consolidation requests per batch
initialMaxGroupsInBatch = 10                           # Maximum number of target validator groups per batch

TopUpGateway

Details: LIP-35 Top-Up Limits.

_maxValidatorsPerTopUp = 32                            # Maximum number of validators a single topUp can process
_minTopUpBlockDistance = 75                            # Minimum block distance between topUp calls
_maxRootAgeSec = 600                                   # Maximum age (seconds) of the beacon root used to prove validator state

TriggerableWithdrawalGateway

Details: TW limits (incl. SRv3 update for 0x02).

maxExitRequestsLimit = 250                             # Maximum number of triggerable exit requests in the limit bucket
exitsPerFrame = 1                                      # Number of exit requests restored to the bucket per frame
frameDurationInSec = 240                               # Duration of each refill frame, in seconds

Deprecated

  • exitedValidatorsPerDayLimit (was 3600 val/day) → exitedEthAmountPerDayLimit = 57600 (converted to ETH, min validator balance 16 ETH).
  • appearedValidatorsPerDayLimit (was 1800 val/day) → appearedEthAmountPerDayLimit = 57600.
  • maxValidatorExitRequestsPerReport (was 600 val/report) → maxBalanceExitRequestedPerReportInEth = 19200.
  • clBalanceGwei → split into clValidatorsBalanceGwei + clPendingBalanceGwei.
  • consolidationEthAmountPerDayLimit = 93375 sized to current network state (37.3M deposit queue + 3.2M + 3M DAO buffer over ~2 months).

Detailed reasoning and per-parameter sizing are available in the supplementary document - Staking Router v3 — Suggested parameter values (LIP-35)

1 Like