Proposal: Add Easy Track factory for Deposit Reserve Target management by CMC

Proposals
1

TL;DR

Add new SetDepositsReserveTarget Easy Track factory, letting the CMC adjust Lido.depositsReserveTarget via Easy Track motion, capped at 9600 ETH.

Parameter Value
Trusted caller CMC multisig (5/9) 0x2570e0b22AD904501dfB0d49575991ACB801dD91
MAX_DEPOSITS_RESERVE_TARGET 9600 ETH
Scope Lido.setDepositsReserveTarget(uint256) only

What the parameter does

After the latest release of Lido Core (SRv3) the buffer is split by priority: deposits reserve → withdrawals reserve (unfinalized stETH) → unreserved. The deposits reserve is carved out first and stays depositable to the CL regardless of withdrawal demand; it refills to depositsReserveTarget on each accounting oracle report and is consumed as deposits are made.

Without it, sustained withdrawal demand routes the whole buffer to finalization and deposits stop entirely until the queue clears.

Why this parameter is suited to optimistic governance-based changes

The right value for the deposit reserve depends on parameters that change over time, like withdrawal queue pressure and stake allocation capacity in different staking modules. Full Aragon Votes might not be the best fit for the parameter adjustment. Easy Track is a go to option for frequent parameters management.

Why CMC

The original Snapshot mandate for CMC is written mostly in terms of the Curated Modules, while depositsReserveTarget is a core-protocol parameter affecting deposit flow to all modules. This proposal is therefore an explicit, narrow extension of CMC’s permissions, with limited adjustment power over a single parameter - depositsReserveTarget.

Here are a few detailed arguments for CMC as a permission holder:

  • The parameter’s effect is CMC’s subject matter. What it controls is whether operators receive stake new stake during the periods of withdrawal pressure. CMC already owns onboarding rounds, NO Types, and other operator-related parameters — this is the upstream knob that decides whether those actions take effect.
  • CMC already holds the inputs. Setting it requires knowing keys queued per module, which operators are ramping, and the onboarding pipeline. No other body tracks this continuously.
  • The cadence matches its design. CMC was constituted as the fast-response unit for exactly this class of recurring parameter change.

Bounds and risks

  • Adjustment range is capped. 9600 ETH is immutable upper limit within the factory; higher motions revert at script creation, meaning that if there is ever a need to set the value higher, either a full DAO vote would need to be used or a new Easy Track factory made.
  • No value transfer. The parameter cannot move funds, mint, burn, or change fees — only the ordering priority of already-buffered ETH between protocol CL deposits or stETH withdrawals finalization. Worst case at the cap: ≤9600 ETH per frame prioritized to deposits ahead of finalization.
  • Narrow permission. Registered against the single setDepositsReserveTarget selector; the EVMScriptExecutor gains no other authority on Lido. No-op motions revert (SAME_DEPOSITS_RESERVE_TARGET).
  • DAO retains control. The Agent stays role manager of BUFFER_RESERVE_MANAGER_ROLE and can set the target directly, revoke the permission, or drop the factory at any time. Every motion is objectable and published on this forum.

Next steps

  1. Get security audit for the factory code.
  2. Deploy easy-track#130 on mainnet with the CMC multisig as trusted caller and a 9600 ETH cap.
  3. Next Aragon vote: grant BUFFER_RESERVE_MANAGER_ROLE to the Easy Track EVMScriptExecutor and register the factory.
  4. CMC publishes its review cadence and reporting format in a dedicated thread.
3 Likes
LIP-37: Execution Delegation Framework (EDF)
2

Hoodi deployment: 0x68009122a394504E8fD7fee58F92Cd73c6A60717

3

Thanks for the detailed writeup. The mechanism itself makes sense to us. The deposits reserve is a parameter that plausibly needs adjusting more often than full Aragon votes allow, and the narrow selector, immutable ceiling, and revocable role are sensible guardrails. Before this moves to a vote, we would like to clarify a few points.

1. How was the 9600 ETH ceiling derived? SRv3 launched with depositsReserveTarget at 1500 ETH, and that number is backed by a dedicated sizing analysis balancing the CMv2 seeding requirement against withdrawal finalization times. The proposed ceiling is 6.4x higher, but we could not find the methodology behind it. What scenario or capacity requirement makes 9600 ETH the appropriate maximum, and does CMC expect 1500 ETH to remain the operating value initially?

2. How should the DAO think about withdrawal impact near the ceiling? The original sizing analysis already models this trade-off, and it becomes material at higher values. At a 10,000 ETH reserve, which is effectively where the proposed cap sits, average finalization time in the model grows from 6.3 to 15.7 days under high-stress conditions. What conditions would justify moving the reserve that high, and what conditions would require CMC to bring it back down?

3. Is the absolute ceiling intended to be the only constraint on individual motions? As implemented, the factory checks that the new value does not exceed the cap and differs from the current one, nothing else. A single motion can therefore move the target from 1500 to 9600 ETH, or to zero, effectively removing the deposit reserve. We understand every motion passes through the standard objection window, but a passive veto on a parameter most token holders have no intuition for is a weaker check than an explicit bound. Would you consider a per-motion delta limit, or at least published escalation criteria for large changes? A hard cap bounds the maximum state, not the speed at which the parameter gets there.

4. On the CMC mandate. The proposal correctly notes that the original CMC mandate is focused on the Curated Modules, while depositsReserveTarget is a core-protocol parameter affecting deposit flow across all modules. When CMC was established, the sequence was a Snapshot-ratified mandate first, with the Aragon vote then implementing the corresponding on-chain permissions. Is the upcoming Aragon vote intended to serve as both the mandate extension and the technical grant here? If so, we would like to understand why a Snapshot amendment is no longer considered necessary. We ask less about this specific permission than about the precedent, since future scope extensions will point back to how this one was handled.

5. Operating framework and expected cadence. The review cadence and reporting format are currently planned as the last step, after the factory is registered. We would prefer to see the framework before the Aragon vote, ideally covering the inputs used to select the target, the conditions for increases and decreases, and what gets reported with each motion. It would also help to state the adjustment frequency CMC realistically expects. The parameter still sits at its 1500 ETH launch value, so the DAO has no track record yet from which to judge how often this lever will actually be used, and the expected cadence is part of the case for delegating it in the first place. That way the DAO approves the permission together with the policy under which it will be exercised.

Overall supportive of the direction. The main thing we would like to understand before the vote is how the move from a quantitatively justified 1500 ETH starting point to a delegated range of 0 to 9600 ETH will be governed in practice.

1 Like
4

Thanks for the great questions @cp0x!

Let me address them one-by-one.

How was the 9600 ETH ceiling derived?

The analysis linked shows that deposit reserve of 10000 ETH in the worst case scenario will result in withdrawals finalization time increase of x2 compared to the 1500 ETH. We believe that this is an acceptable border for CMC action. Since this is nothing more than a safety border, and not a target value, the possible impact is limited and DAO can always remove/replace the factory should the value set by the committee be considered bad for the protocol. In case of DAO intervention the period of prolonged withdrawals will not exceed 10 days (governance wondow for the on-chain votes) which is approx the duration of a sweep cycle needed to get ETH from exited CL validators anyway.

How should the DAO think about withdrawal impact near the ceiling?

Partially answered above. CMC does not plan to raise the limit to these values any time soon. In case CMC would decide to set the value close to the upper border and LDO holders consider this value incorrect for the protocol and network conditions, the motion can be objected and blocked.

Is the absolute ceiling intended to be the only constraint on individual motions?

Due to the limited impact we believe that limiting a per-motion change does not add meaningful security or safety.

On the CMC mandate.

You are right that the initial Snapshot framing is more about Curated module. However, CMC has replaced LNOSG that was responsible for the overall operator set. We believe that this additional permission is beneficial for the protocol, upcoming stake migration, and stake reallocation to the upcoming 0x02 CSM. We do not try to set a precedent here, but rather want to have the functionality added to the protocol faster to make protocol more adaptive to the fast changing market conditions.

Now all validator keys required for stake migration in CMv2 have been deposited and CSM has next to none depositable keys on a day by day basis. That means that deposit reserve is used to allocate stake to the now legacy CMv1. Since all of the stake from CMv1 should eventually be migrated to CMv2, we believe that we should temporarily disable deposit reserve by setting it to 0 via ET motion that will follow the on-chain vote (should it pass). Once 0x02 CSM is live (expected in October 2026), we will have a new permissionless module with DAO Fee of 8% (the highest so far), and it will make sense to enable deposit reserve back with the value of 1500 or even 2000 ETH. This will ensure stake migration to the most profitable and permissionless module while CMv1 to CMv2 stake migration via consolidations will be ongoing.

Operating framework and expected cadence.

Covered in the reply above.

5

Thanks for the thorough answers, much appreciated.

The operational plan you describe, setting the reserve to zero once the vote passes since CMv2 seeding is complete, then re-enabling it at 1500 to 2000 ETH when 0x02 CSM goes live in October, is exactly the kind of context that was missing from the original post. It makes the case for the delegation considerably clearer, and we would encourage folding it into the proposal text or the Snapshot description so that voters who never open this thread see it too.

The safety-border framing for 9600 ETH also works for us. Bounded worst case, roughly a doubling of finalization time, and reversible within the governance window is a reasonable answer even without a dedicated derivation for the number itself.

One remaining ask. The proposal lists the CMC review cadence and reporting format as a step that comes after the factory is registered. Given that the committee already has a concrete plan for the first two moves, publishing that framework before the Aragon vote rather than after should be low effort, and it would let the DAO approve the permission together with the policy for using it. We would see that as closing the last open point on our side.

On the mandate question we take your point that no precedent is intended, and we will not press it further here.

1 Like
6

Mainnet deployed address 0x62E9Dc68BDCBC46362f40e0bb9c154C9a42E62b0

3 Likes
7

Security Audit for the proposed ET factory was conducted by MixBytes. You can find the report here - audits/MixBytes Easy Track for Deposit Reserve Target management Audit Report 09-2026.pdf at main · lidofinance/audits · GitHub

1 Like
8

CMC’s position and plan regarding the proposed ET posted Curated Module Committee (CMC) reporting thread - #4 by dgusakov

2 Likes
9

Thanks for moving quickly on this. The CMC plan published in the reporting thread, together with the audit and the mainnet deployment, addresses what we raised. Having the intended first steps written down before the vote rather than after is exactly what we were asking for, and the reporting thread gives a natural home for future updates as plans firm up. No open questions from our side, and we are comfortable supporting this when it goes to a vote

2 Likes
10

Following the single-stage vote process, the vote text for the Add Easy Track factory for Deposit Reserve Target management by CMC has been finalized and frozen on IPFS - this is the exact text the DAO will vote on.

The on-chain vote is planned to start on Wednesday, September 16. Once the vote is live, a link to it and instructions for verifying the vote items will follow in this thread.

1 Like