TL;DR
- NEST creates a direct, rule-based link between Lido DAO success and LDO.
- The mechanism automatically converts a share of excess surplus into LDO via CoW Swap. In LP mode (the initial configuration proposed here), purchased LDO is paired with wstETH and deployed as DAO-owned liquidity in a Curve LDO/wstETH pool.
- This is a governance commitment, not a price-support mechanism. When the DAO earns above its operating baseline, a bounded share of that surplus is directed into LDO. It runs automatically, permissionlessly, under full DAO control.
- Proposed initial parameters: $40M annual revenue baseline · 50% surplus share · $50k daily cap · $10M annual cap · ETH price floor = $0 (inactive). All parameters require a full DAO vote to change.
- The Emergency Brakes on the ETH multisig can pause/unpause NEST; the Treasury Management Committee (TMC) can manage LP positions and fund the NEST controller. Any configuration change requires a full DAO vote.
- LIP-35 draft: LIP-36: NEST by katamarinaki · Pull Request #116 · lidofinance/lido-improvement-proposals · GitHub.
Motivation
Background
This post is a follow-up to the Liquid Buybacks: NEST execution with LDO/wstETH liquidity thread, where Steakhouse first proposed an automated buyback mechanism. That discussion surfaced an appetite for a rule-based economic link between protocol performance and LDO, and raised a set of design questions Lido contributors took away to resolve.
Since then, Lido contributors have:
- Designed the full contract architecture, including revenue source integration, eligibility gates, and emergency controls.
- Modeled cumulative vs. instant surplus mechanics against 2024–2025 historical revenue data to choose a methodology and calibrate parameters.
- Analyzed LP arbitrage leakage and pool dynamics to understand the real cost of liquidity provisioning.
- Drafted LIP-35 with the full formal specification.
This post presents the resulting proposal for community feedback and a governance vote.
The problem
LDO holders have no automatic link to protocol performance. Treasury surplus above operating costs accumulates in the treasury with no rule-based mechanism for deployment.
What NEST does
NEST is a deterministic, on-chain system:
LP mode is the initial operating configuration. Half the daily budget buys LDO; the other half is wrapped to wstETH and paired with it. Both are deposited into a Curve pool; LP tokens remain DAO-owned.
Treasury-only mode (purchased LDO is sent directly to the Aragon Agent) is available as a governance fallback, activatable by a subsequent DAO vote without redeploying contracts.
At launch, NEST tracks only staking revenue. Future revenue sources can be added through governance. Each new source requires a dedicated revenue source contract and a DAO vote.
How NEST works
Funding
NESTController holds stETH, which is deployed for buybacks. The source is Aragon Agent: TMC proposes an EasyTrack motion, which executes a stETH transfer from the Aragon Agent to the NESTController. When triggerExecution() runs, the controller draws on this balance to fund Stonks orders. The EasyTrack limit for stETH transfers will be reviewed before launch and raised if the current limit is insufficient for the expected operating cadence.
Surplus mechanics
NEST uses a cumulative surplus model. Each day, staking revenue is compared to the $40M/year operating baseline (~$109k/day). If revenue exceeds it, surplus increases cumulative buyback capacity. If it falls below, the loss reduces it. Buybacks only execute while that cumulative capacity stays non-negative — meaning we have not already spent more than we have earned. When the gate passes (cumulative balance > 0), the day’s order size is set by that day’s surplus allocation (up to the $50k daily cap), not by the cumulative balance itself.
This acts as a natural brake: after a bad period, new surplus first covers accumulated losses before buybacks resume.
Execution
triggerExecution() is a permissionless function, though in practice the keeper bot handles the routine cadence. The CoW Protocol requires a matching off-chain payload, which the keeper submits to the CoW API after each order-creation event. There is no liveness dependency.
Zero-seed pool
No upfront LDO injection from treasury is needed or beneficial. Seeding the pool from treasury while simultaneously buying LDO from the market partially offsets the buyback signal.
One practical note: deploying the Curve pool itself requires a small amount of LDO and stETH for initialization. These amounts are modest and will be covered by the Foundations from the approved EGG budget.
Parameters
We are asking the DAO to approve the following initial parameter set:
| Parameter | Proposed Value | Notes |
|---|---|---|
| Revenue baseline | $40M/year (~$109k/day) | Surplus computation floor |
| Surplus share | 50% (5000 bps) | Share of daily surplus allocated to NEST. In LP mode: split equally between LDO purchase and wstETH pairing. |
| Daily cap | $50,000 | Primary active safety limiter |
| Annual cap | $10,000,000 | Rolling 365-day ceiling |
| ETH price floor | $0 (disabled) | With the current revenue structure NEST buybacks stop naturally below ~$2,700 ETH. The parameter is retained as a governance lever. For example, if staking APR compresses and the natural break-even shifts upward. |
| Pool slippage tolerance | 2% (200 bps) | MEV guard on Curve deposits |
All parameters are configurable only via Aragon Voting. The daily cap is independently adjustable as surplus and on-chain liquidity grow.
Governance and control: who holds which levers
| Role | Held by | What they can do |
|---|---|---|
| Full admin | Aragon Voting (full DAO vote) | Change any parameter · transfer LP tokens · reset buyback accounting · asset recovery · role management |
| Manager + Emergency | Treasury Management Committee (TMC) 0xa02FC823cCE0D016bD7e17ac684c9abAb2d6D647 |
Remove LP positions and return assets to treasury · emergency pause/unpause · fund the controller via Easy Track |
| Emergency only | Emergency Brakes on ETH 0x73b047fe6337183A454c5217241D780a932777bD |
Pause/unpause any of the five pause domains · cancel or revoke Stonks orders · cannot change configuration |
| Permissionless | Anyone | triggerExecution() · addLiquidity() · retryFromStonks() · unwrapExcessWstEth() |
EasyTrack is used exclusively for proposing funding (stETH transfers to the NEST controller).
Emergency controls
Five independent pause domains, each stoppable without affecting the others:
- NESTController execution: stops
triggerExecution()andretryFromStonks(); assets accumulate in the controller. - LiquidityProvisioner liquidity: stops
addLiquidity();unwrapExcessWstEth()remains callable. - Revenue sources: stop data acceptance; stale sources halt execution without engaging the execution pause.
- Stonks creation/signature: stops new order creation or freezes settlement of existing orders independently.
- OracleRouter: stops all price queries; reverts both execution and LP provisioning.
Asset recovery is always available and is not subject to pause. At the $50k daily cap, maximum exposure during a 6-day governance response window is ~$300k.
Risks and mitigation
| Risk | Mitigation |
|---|---|
| Oracle manipulation | Chainlink feeds validated for staleness; $50k daily cap bounds max exposure per trigger; OracleRouter independently pausable. The 6-day governance response window assumes active monitoring — EC composition and on-call responsibilities will be published before Snapshot. |
| Permissionless execution abuse | Budget computation on-chain at call time; orderPriceProtectionBps absorbs price movement; daily and annual caps enforced regardless |
| Overspend during good streaks | Cumulative model: losses reduce buyback capacity; new surplus must cover accumulated deficit before execution resumes |
| LP pool skew / MEV sandwich | Two-layer protection: Curve EMA divergence gate + LP slippage guard on each deposit |
| Revenue source failure | Sources individually pausable; staleness detection halts execution without requiring emergency pause |
What the DAO is approving
We are asking the DAO to:
- Approve the NEST architecture as specified in LIP-35.
- Approve the initial parameter set listed above.
- Authorize deployment of:
NESTController,StakingRevenueSource,LiquidityProvisioner, modifiedStonks v2andOrdercontracts. - Authorize role grants: TMC receives
MANAGER_ROLEandEMERGENCY_ROLEOn both main contracts, the Emergency Brakes on the ETH multisig receiveEMERGENCY_ROLEon all NEST contracts and revenue sources. - Authorize the operational decision on the TMC Easy Track stETH transfer limit (raise, keep as-is, or deploy a dedicated EasyTrack). Our recommendation will be shared during the forum discussion period and included in the final Snapshot package.
The DAO does not need to approve: individual buyback executions (permissionless), routine LP management within TMC scope, and keeper bot operations.
Next steps
- Forum discussion: community questions and feedback.
- Snapshot vote: community approval of the proposal and parameter set.
- Code external audits
- LP deployment
- On-chain DAO vote: executes deployment, role grants, and TokenRateNotifier registration in a single transaction.
- EasyTrack funding: TMC funds the NESTController with stETH.
- System live: The first protocol rebase after deployment (~24h) automatically activates the mechanism.