# Liquid Buybacks: NEST execution with LDO/wstETH liquidity **URL:** \ **Category:** Proposals\ **Created:** [November 11, 2025, 9:48am UTC](https://research.lido.fi/t/liquid-buybacks-nest-execution-with-ldo-wsteth-liquidity/10894 "2025-11-11T09:48:17Z")\ **Posts on this page:** 12\ **Page:** 5
**Author:** ![hamatim](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/hamatim/32/6655_2.png) [@hamatim](https://research.lido.fi/u/hamatim)\ **Post date:** [June 9, 2026, 5:43am UTC](https://research.lido.fi/t/liquid-buybacks-nest-execution-with-ldo-wsteth-liquidity/10894/107 "2026-06-09T05:43:43Z")
NEST buyback should be activated sooner is better because it give our protocol another revenue stream by act as CowSwap LP provider. It also can give good signal for token which DAO already buy back by [Utilizing Market Opportunities: stETH / LDO trade - #49 by hamatim](https://research.lido.fi/t/utilizing-market-opportunities-steth-ldo-trade/11358/49) Make [$LDO](https://x.com/search?q=%24LDO&src=cashtag_click) great again ---
**Author:** ![katamarinaki](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/katamarinaki/32/5721_2.png) [@katamarinaki](https://research.lido.fi/u/katamarinaki)\ **Post date:** [July 2, 2026, 4:03pm UTC](https://research.lido.fi/t/liquid-buybacks-nest-execution-with-ldo-wsteth-liquidity/10894/108 "2026-07-02T16:03:52Z")
I’d like to share a small update from NEST workgroup. ## tl;dr Following the approved [Snapshot vote](https://snapshot.box/#/s:lido-snapshot.eth/proposal/0x022e901a6368573d18b150eecda563dd2ee17ad2aa6a0ef9772151cc7ba55187) to proceed with NEST the workgroup moved from design into implementation. During that work the architecture was updated in several places. We’ve now refreshed the technical specification and posting this as a transparency notice over what changed and why. Most important update is: **the economic commitment the DAO approved is intact.** NEST still converts a constrained share of surplus staking revenue into LDO via Stonks v2, pairs it with wstETH as DAO-owned Curve liquidity, is permissionless to run, fully DAO-controlled, and bounded by hard daily/yearly caps. The proposed initial economic parameters are unchanged. One Curve-deposit guard parameter was superseded by structural guards, covered below. What changed is the contract architecture and a few mechanics, in the direction of less code, fewer trusted surfaces, and more rule-based logic. The updated spec is available [here](https://hackmd.io/TKXZh2lKSLG6m9QDo5kpVg?view). ## Details ### What stayed the same - Surplus-gated buybacks: stETH only leaves the system when the protocol has earned revenue above a configured baseline, and never faster than the caps allow. - LP mode as the launch configuration; treasury-only mode available as a governance fallback. - Permissionless execution, DAO as sole admin, not under Dual Governance (same as the rest of treasury ops), EasyTrack used only for funding. - Proposed initial values: **$40M/yr revenue baseline, 50% surplus share, $50k daily cap, $10M yearly cap, price floor disabled at launch.** ### What changed, and why **1. Budget logic separated from execution.** The contracts were reorganized and renamed (`NESTController`/`LiquidityProvisioner` → `BuybackAllocator`/`BuybackExecutor`). The meaningful change here is the boundary: budget accounting now lives in a contract that only meters stETH out under the caps, so the side that trades and provisions liquidity can’t decide how much it spends. Execution is correspondingly two permissionless steps, `allocate()` then `placeOrder()`, rather than a single call. **2. Simpler revenue tracking.** Revenue sources now expose a single monotonic `getCumulativeRevenueUSD()` and the allocator diffs it over time. The per-source daily-rate normalization, staleness windows, and source-level pausing are gone. The staking source’s rebase callback is now oracle-free. It accrues the treasury’s minted-fee slice into a pending bucket, and a separate permissionless `convertPendingRevenueToUSD()` settles that bucket to USD. **3. One signed budget accumulator + a clock-based reserve.** The initial design tracked several running counters on a once-per-day accounting cadence against a fixed revenue threshold. The implemented version banks a single signed budget: each call adds the surplus earned since the last checkpoint (the configured share of revenue, net of the reserve), and a release spends the non-negative part, clamped by the daily and yearly caps, the held balance, and a per-call floor. The revenue threshold became a clock-based reserve, so the cadence no longer needs the special anti-griefing timestamps the original design carried. **4. No more excess-wstETH handling.** The initial design wrapped half the budget to wstETH on every trigger and pushed it to the provisioner, which left a wstETH overhang on partial or unfilled fills and needed a cooldown-gated cleanup path to unwrap it back. The implemented version keeps the pairing half as stETH and wraps to wstETH only at deposit time, so there’s no overhang and nothing to clean up. Unfilled sell-side stETH is simply swept back to Stonks and re-sold by the next order. **5. Mode switching via the Stonks receiver.** Operating mode is now derived from the active Stonks instance’s settlement receiver (executor ⇒ LP, treasury ⇒ treasury-only), switched via `setStonksAndOperatingMode` under a full DAO vote, rather than a `liquidityProvisioner` address. **6. Removed surfaces.** The configurable order-price-protection haircut is gone; the minimum buy amount now comes directly from the Stonks trade estimate. The Curve LP-token slippage guard (the 2% pool slippage tolerance from the approved parameter table) is gone too: since the divergence gate compares against the pool’s cross-block EMA price, the deposit leans on that gate for sandwich resistance instead. The implemented version adds per-deposit USD bounds and a bootstrap TVL threshold that bypasses the divergence gate while the pool is still shallow. ### Changes that affect behavior These reduce or alter guarantees relative to the initial design, so we want them on the record rather than buried in a diff: - **Spending draws on the banked surplus, not the day’s surplus.** In the approved proposal each day’s order was sized by that day’s surplus allocation, so a below-baseline day meant no buyback. The implemented version spends from the accumulated budget instead, still under the daily and yearly caps. Buybacks can now continue through below-baseline days while the budget stays positive. Such days eat into the budget until it runs out and buybacks stop on their own. - **Slashing response is softer.** The initial design held the revenue baseline at its pre-slash high-water mark, so revenue stayed at zero until the protocol fully recovered past it, pausing buybacks in proportion to slash severity. The implemented version counts the fees actually minted each rebase: during a downturn less revenue accrues while the reserve keeps growing, so the budget shrinks and pauses, then resumes as revenue returns. The pause now tracks how long revenue stays below the reserve, generally shorter than the old behavior. - **No manual accounting reset.** The initial design had a `resetBuybackAccounting` escape hatch for an indefinitely-blocking deficit. The implemented version drops it: a negative budget self-heals only as surplus rebuilds. Governance can raise the share or lower the reserve rate, but only going forward; an already-banked deficit can’t be cleared. More rule-based and less discretionary, at the cost of that escape hatch. - **Fewer emergency surfaces.** Pause domains drop from five to three: the executor pause (which also halts allocation, since `allocate()` calls the executor hook), the Stonks creation/signature pauses, and the OracleRouter pause. Revenue sources and the allocator no longer have pauses of their own. Asset recovery to the treasury stays available at all times and is never subject to pause. ## Next steps - Audit of the implemented contracts (already ongoing). - Onchain vote, which is now targeted after Staking Router v3 release. ---
**Author:** ![katamarinaki](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/katamarinaki/32/5721_2.png) [@katamarinaki](https://research.lido.fi/u/katamarinaki)\ **Post date:** [July 15, 2026, 12:58pm UTC](https://research.lido.fi/t/liquid-buybacks-nest-execution-with-ldo-wsteth-liquidity/10894/109 "2026-07-15T12:58:45Z")
Ahead of the NEST onchain vote, expected after Vote #203, this post shares remaining parameters and an intent of a change to the launch plan. ## tl;dr - **The team proposes that the launch mode is treasury-only, not LP.** Snapshot vote approved launching in LP mode, but challenges that surfaced during development put that path in question, so the Aragon vote will propose launching in treasury-only mode, with backed LDO transferred directly to Treasury. - **The Curve LDO/wstETH pool is deployed.** Parameters published below, per the LIP-36 commitment. - **LDO/wstETH pool potential EMA deadlock was mitigated** via NEST implementation, with `poolBootstrapMinTvlUsd` set to **$250,000**. ## Details ### 1. **LDO/wstETH pool deployment** Despite the shifting market, the workgroup kept both directions open until the DAO vote: the pool was deployed as committed in LIP-36. Enabling LP mode later needs no additional deployments. The Curve LDO/wstETH TwoCrypto-NG pool is deployed with following params: | Parameter | Value | | --- | --- | | Pool address | `0xD7f1dA0a28E39dd0dB70E6Acdc2B49846AD22760` | | Name / symbol | [Curve.fi](http://curve.fi/) LDO/wstETH · `LDOwstETH-f` | | Coins | LDO (`0x5A98…1B32`) / wstETH (`0x7f39…2Ca0`) | | `A` | `400000` | | `gamma` | `145000000000000` (0.000145) | | `mid_fee` | `500000` (0.005%) | | `out_fee` | `5000000` (0.05%) | | `fee_gamma` | `230000000000000` (0.00023) | | `allowed_extra_profit` | `2000000000000` | | `adjustment_step` | `146000000000000` | | `ma_time` | `601` (seconds) | | `initial_price` | `8075081795329464726918` (~8,075.08 LDO per wstETH) | | Factory | `0x98EE851a00abeE0d95D08cF4CA2BdCE32aeaAF7F` | | Pool implementation | `0x934791f7F391727db92BFF94cd789c4623d14c52` | | Math implementation | `0x1Fd8Af16DC4BEBd950521308D55d0543b6cDF4A1` | | Views implementation | `0x07CdEBF81977E111B08C126DEFA07818d0045b80` | | Factory admin | `0x97aA696e37659Fb4f0B53824246d802Df40E980A` | | Fee receiver | `0xa2Bcd1a4Efbd04B63cd03f5aFf2561106ebCCE00` | ### 2. LDO/wstETH pool EMA deadlock mitigation The pool starts empty, so its EMA price oracle stays fixed at the deployed `initial_price` until trades happen. NEST normally blocks LP deposits if this EMA diverges too far from the Chainlink-based `OracleRouter` rate. That can deadlock an empty pool (no liquidity → no trades → no EMA updates). To break the loop, the divergence check is disabled until TVL reaches `poolBootstrapMinTvlUsd` ( **$250,000** ). TVL is measured in USD at oracle prices, and deposits are bounded by `minDepositValueUsd`/`maxDepositValueUsd`, so the maximum unguarded exposure during bootstrap is the threshold plus one capped deposit. This only matters in LP mode and is inactive at launch. ### 3. Launch mode: treasury-only NEST sells a limited amount of DAO-owned stETH to acquire LDO (via Stonks v2 / CoW Swap) and then either 1. **Treasury mode:** routes 50% of the surplus in acquired LDO to the treasury 2. **LP mode:** split 50% of surplus into LDO and deposit it into the LDO/wstETH Curve v2 pool. It is a rules-based mechanism for surplus conversion and improving liquidity depth. Snapshot approved and launching in LP mode, but development issues surfaced that make it a poor default for day one. We therefore propose launching NEST in **treasury-only mode** while keeping LP mode ready for later enablement. Enabling LP mode later is a single onchain action: point the executor to the LP-mode Stonks instance via `BuybackExecutor.setStonks` (no redeployments). The issues fall into two buckets: 1. **Current Market** Further modeling has weakened the case for LP mode at launch. The workgroup concluded that pool-deepening liquidity occurs only in a specific scenario: a sustained joint uptrend in LDO and wstETH. Also, the pool is small relative to existing LDO trading venues. With the upside this conditional and this thin, the launch-configuration choice is no longer a settled call for LPs. 2. **Security consideration** There is no audit report covering the exact version of Curve TwoCrypto-NG code deployed onchain. Launching in treasury-only mode keeps DAO funds out of the pool until this is resolved, while still allowing the buyback mechanism to run. For scale, all ~1k bytecode-identical pools that live today hold about $5M in combined TVL, less than NEST’s $10M yearly cap. ### 4. Sizing and guard parameters LIP-36 committed to publishing `minSpendPerCallUSD`, the pool guards, and the order and deposit bounds before the onchain vote: | Parameter | Value | | --- | --- | | `minSpendPerCallUSD` | $1,000 | | `minAllowedOrderAmount` / `maxAllowedOrderAmount` | 1 / 20 stETH | | `poolPriceDivergenceToleranceBps` | `200` (2%) | | `poolBootstrapMinTvlUsd` | $250,000 | | `minDepositValueUsd` / `maxDepositValueUsd` | $1,000 / $50,000 | The pool guards and deposit bounds apply only under LP mode and stay dormant at launch. ## Next steps - The final audit report of the NEST contracts will be published in this thread as soon as possible. - List of onchain vote items will be published to this thread as well. - Onchain vote to launch NEST in treasury-only mode, targeted after the Staking Router v3 release. сс: @cp0x @Kuzmich @batuX @Leuts @Lanski @polar Please, let us know if you have any concerns on launching parameters, including Treasury mode. ---
**Author:** ![polar](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/polar/32/4806_2.png) [@polar](https://research.lido.fi/u/polar)\ **Post date:** [July 16, 2026, 5:53am UTC](https://research.lido.fi/t/liquid-buybacks-nest-execution-with-ldo-wsteth-liquidity/10894/110 "2026-07-16T05:53:02Z")
The rationale for the change is sound. I suspect this won’t be the only time the strategy will change, which is no issue so long as we’re keeping updated as above. Good work! ---
**Author:** ![swissarmytowel](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/swissarmytowel/32/5722_2.png) [@swissarmytowel](https://research.lido.fi/u/swissarmytowel)\ **Post date:** [July 28, 2026, 1:30pm UTC](https://research.lido.fi/t/liquid-buybacks-nest-execution-with-ldo-wsteth-liquidity/10894/111 "2026-07-28T13:30:02Z")
Vitaly from the DAO Tech team here. Great news, the NEST contracts have been audited, deployed on mainnet, and verified 🎉 The finalized audit report with verified addresses is available in the [Lido audits repository](https://github.com/lidofinance/audits/blob/main/Ack3%20Lido%20NEST%20Audit%20Report%2007-2026.pdf). The scope also includes the updated `TokenRateNotifier` contract from the [core repository](https://github.com/lidofinance/core/pull/1843), reworked to make on-chain staking revenue fetching easier for NEST. It was audited and its deployment verified alongside the rest of the NEST system. ### Deployed contracts: | Contract | Address | | --- | --- | | `StonksFactory` | [`0x632C0CCDca849eeD780FC685BBa9AbC3c7407Cb2`](https://etherscan.io/address/0x632C0CCDca849eeD780FC685BBa9AbC3c7407Cb2) | | `Order` sample | [`0x2569633AdB492ca9327cb7433277aa7c68D69e28`](https://etherscan.io/address/0x2569633AdB492ca9327cb7433277aa7c68D69e28) | | `StakingRevenueSource` | [`0x6220212a33a87Ed7Cc386B67eB2c393974F28C38`](https://etherscan.io/address/0x6220212a33a87Ed7Cc386B67eB2c393974F28C38) | | `BuybackExecutor` | [`0x6c213ca5A10Cc26548C742229569B4AeD2A9C9B7`](https://etherscan.io/address/0x6c213ca5A10Cc26548C742229569B4AeD2A9C9B7) | | `BuybackAllocator` | [`0xAA568141c051f2D1132b110f8391F18D48E8D889`](https://etherscan.io/address/0xAA568141c051f2D1132b110f8391F18D48E8D889) | | `Stonks` instance, LP mode | [`0x8c595aA4AEc6F42B9e7D77F83179768D37CE3042`](https://etherscan.io/address/0x8c595aA4AEc6F42B9e7D77F83179768D37CE3042) | | `Stonks` instance, Treasury mode | [`0xb368586CB980895E51e1D82102E63b3F69d3F151`](https://etherscan.io/address/0xb368586CB980895E51e1D82102E63b3F69d3F151) | | `TokenRateNotifier` | [`0xbe05d12Fd10919F1881125006523452F6aFF791b`](https://etherscan.io/address/0xbe05d12Fd10919F1881125006523452F6aFF791b) | | `LidoLocator` implementation, new | [`0xF2Ffb952e129a63F0614Ff87126E1d4a494A2313`](https://etherscan.io/address/0xF2Ffb952e129a63F0614Ff87126E1d4a494A2313) | ### Voting Items **To make the system operational we propose adding the following items to the upcoming vote:** - Add the existing `OpStackTokenRatePusher` to the new `TokenRateNotifier` as a `NoArgs` observer, kind `0`. This is needed to restore the previous observer on the updated deployment of the `TokenRateNotifier` - Add `StakingRevenueSource` to the new `TokenRateNotifier` as a `WithArgs` observer, kind `1`, so it receives a callback after each rebase. - Upgrade the `LidoLocator` proxy to the new implementation, repointing `postTokenRebaseReceiver` to the new notifier. - Add `BuybackAllocator` as allowed recipient on the Stonks stETH top-up `AllowedRecipientsRegistry` for funding via the Easy Track. - Set the Treasury Management Committee as manager on `OracleRouter` to maintain the stETH and LDO feeds. - Set the Treasury-mode Stonks on `BuybackExecutor`. The NEST operation mode is derived from `Stonks.RECEIVER()`. - Grant `ALLOCATOR_ROLE` to `BuybackAllocator` on `BuybackExecutor`. Lets the allocator fund the executor and trigger buyback processing. - Grant `MANAGER_ROLE` to the Treasury Management Committee on `BuybackExecutor`. Covers asset recovery to the treasury and LP withdrawal. - Grant `EMERGENCY_ROLE` to the Treasury Management Committee on `BuybackExecutor`. Covers emergency controlls: pausing the executor, halting Stonks creation and order signatures, and cancelling the last order. - Grant `EMERGENCY_ROLE` to the Emergency Brakes Committee on `BuybackExecutor`. Same emergency controls, held independently of the TMC. - Grant `MANAGER_ROLE` to the Treasury Management Committee on `BuybackAllocator`. Covers asset recovery to the treasury. - Call `activate()` on `BuybackAllocator`. Records the revenue baseline, so only revenue earned after activation funds the buyback budget, and starts the allocation process. ---
**Author:** ![nikita.p](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/nikita.p/32/5751_2.png) [@nikita.p](https://research.lido.fi/u/nikita.p)\ **Post date:** [August 5, 2026, 1:17pm UTC](https://research.lido.fi/t/liquid-buybacks-nest-execution-with-ldo-wsteth-liquidity/10894/112 "2026-08-05T13:17:25Z")
The **[on-chain vote #204](https://dao.lido.fi/vote/204)** is now live and includes the proposal to **launch NEST in [treasury-only mode](https://research.lido.fi/t/liquid-buybacks-nest-execution-with-ldo-wsteth-liquidity/10894/109#p-25979-h-3-launch-mode-treasury-only-5), with all purchased LDO sent directly to the DAO Treasury**. The vote will be open for your “For” or “Against” input until the end of the main phase: **Aug 8, 13:00 UTC**. For instructions on how to verify the vote items, please follow [this guide](https://enchanted-direction-844.notion.site/How-to-check-the-Lido-DAO-on-chain-vote-204-NEST-Activation-LOL-stablecoins-ET-Payment-Factories--3acbf633d0c9803fb2b5f385ae2cc42f). ---
**Author:** ![Protocol\_Zero](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/protocol_zero/32/6678_2.png) [@Protocol\_Zero](https://research.lido.fi/u/Protocol_Zero)\ **Post date:** [August 7, 2026, 5:07pm UTC](https://research.lido.fi/t/liquid-buybacks-nest-execution-with-ldo-wsteth-liquidity/10894/113 "2026-08-07T17:07:44Z")
I agree. Holding LP tokens from a wstETH/LDO pool exposes the token to impermanent loss (this would be different in a stablecoin pool, waiting for stLDO 🤞). Still, moving everything into the treasury seems like the best option right now. The treasury has invested $40 million in LDO tokens and has a reasonable buyback plan. If we don’t find a clear use for this token, all of this will be wasted. ---
**Author:** ![nikita.p](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/nikita.p/32/5751_2.png) [@nikita.p](https://research.lido.fi/u/nikita.p)\ **Post date:** [August 10, 2026, 1:28pm UTC](https://research.lido.fi/t/liquid-buybacks-nest-execution-with-ldo-wsteth-liquidity/10894/114 "2026-08-10T13:28:25Z")
The **[on-chain vote #204](https://dao.lido.fi/vote/204)** has been enacted and **full NEST activation will follow the [Dual Governance Proposal #13](https://dao.lido.fi/dg/proposals/13) execution** expected to happen on Friday, August 14. ---
**Author:** ![nikita.p](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/nikita.p/32/5751_2.png) [@nikita.p](https://research.lido.fi/u/nikita.p)\ **Post date:** [August 14, 2026, 1:23pm UTC](https://research.lido.fi/t/liquid-buybacks-nest-execution-with-ldo-wsteth-liquidity/10894/115 "2026-08-14T13:23:01Z")
**[Dual Governance Proposal #13](https://dao.lido.fi/dg/proposals/13)** has been executed - **NEST is now fully activated**. ---
**Author:** ![a8103419](https://avatars.discourse-cdn.com/v4/letter/a/5f9b8f/32.png) [@a8103419](https://research.lido.fi/u/a8103419)\ **Post date:** [September 16, 2026, 3:02am UTC](https://research.lido.fi/t/liquid-buybacks-nest-execution-with-ldo-wsteth-liquidity/10894/116 "2026-09-16T03:02:37Z")
Take a look at posts like this. For years, the community has been calling for LDO value accrual. Countless people have called for it, and their calls have been met with every kind of brush-off. Countless proposals were made, and what finally shipped was NEST — a toothless buyback — which only passed because there was nothing else left on the table. To keep protocol spending down, they assumed the market couldn’t do the math, and used that as a brush-off to placate holders. Years ago, people already proposed good value-capture designs. The main reason they won’t adopt them is that it would cut into their own money. As LDO keeps falling, everyone will go silent, because those willing to shout have already left. This proves only one thing: this is absolutely not a DAO. There is no DAO that doesn’t want its own token to do well, because a DAO is made up of token holders. ---
**Author:** ![JackLido](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/jacklido/32/7117_2.png) [@JackLido](https://research.lido.fi/u/JackLido)\ **Post date:** [September 16, 2026, 8:00am UTC](https://research.lido.fi/t/liquid-buybacks-nest-execution-with-ldo-wsteth-liquidity/10894/117 "2026-09-16T08:00:08Z")
Your takes are all spot on. This will only be solved when there is an ecosystem wide token alignment so that everyone involved is incentivized to hold the token (or penalized for not holding it). ---
**Author:** ![a8103419](https://avatars.discourse-cdn.com/v4/letter/a/5f9b8f/32.png) [@a8103419](https://research.lido.fi/u/a8103419)\ **Post date:** [September 16, 2026, 8:10am UTC](https://research.lido.fi/t/liquid-buybacks-nest-execution-with-ldo-wsteth-liquidity/10894/118 "2026-09-16T08:10:54Z")
The contributor class’s income is decoupled from LDO’s price. Their salaries are mostly denominated in stablecoins, and budgets are drafted with their own participation and approved through a governance process they themselves control. This creates a closed loop: the people who write the budgets, approve the budgets, and receive the budgets are the same group — while the token holders who generate the system’s revenue are not in that loop. The four gates in the NEST they designed are a product of this closed loop. Go back to the design: every gate is there to prevent “too much money from flowing out,” and not one is there to prevent “too little money from flowing out.” If the designers’ goal were to benefit token holders, you would see holder-protecting clauses like “a mandatory minimum buyback when revenue falls below X” — there isn’t a single one. But budget-protecting clauses (daily cap, annual cap) are all present. The design gives away where they stand. [Previous page](https://research.lido.fi/t/liquid-buybacks-nest-execution-with-ldo-wsteth-liquidity/10894.md?page=4)