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
setDepositsReserveTargetselector; theEVMScriptExecutorgains no other authority onLido. No-op motions revert (SAME_DEPOSITS_RESERVE_TARGET). - DAO retains control. The Agent stays role manager of
BUFFER_RESERVE_MANAGER_ROLEand 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
- Get security audit for the factory code.
- Deploy easy-track#130 on mainnet with the CMC multisig as trusted caller and a 9600 ETH cap.
- Next Aragon vote: grant
BUFFER_RESERVE_MANAGER_ROLEto the Easy TrackEVMScriptExecutorand register the factory. - CMC publishes its review cadence and reporting format in a dedicated thread.