Liquid Buybacks: NEST execution with LDO/wstETH liquidity

Proposals
107

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
Make $LDO great again

5 Likes
108

I’d like to share a small update from NEST workgroup.

tl;dr

Following the approved Snapshot vote 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.

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.
9 Likes
109

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 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.

11 Likes
110

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!

8 Likes
111

Vitaly from the DAO Tech team here. Great news, the NEST contracts have been audited, deployed on mainnet, and verified :tada:
The finalized audit report with verified addresses is available in the Lido audits repository.

The scope also includes the updated TokenRateNotifier contract from the core repository, 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
Order sample 0x2569633AdB492ca9327cb7433277aa7c68D69e28
StakingRevenueSource 0x6220212a33a87Ed7Cc386B67eB2c393974F28C38
BuybackExecutor 0x6c213ca5A10Cc26548C742229569B4AeD2A9C9B7
BuybackAllocator 0xAA568141c051f2D1132b110f8391F18D48E8D889
Stonks instance, LP mode 0x8c595aA4AEc6F42B9e7D77F83179768D37CE3042
Stonks instance, Treasury mode 0xb368586CB980895E51e1D82102E63b3F69d3F151
TokenRateNotifier 0xbe05d12Fd10919F1881125006523452F6aFF791b
LidoLocator implementation, new 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

    OpStackTokenRatePusher  0xd54c1c6413caac3477AC14b2a80D5398E3c32FfE
TokenRateNotifier       0xbe05d12Fd10919F1881125006523452F6aFF791b

  • Add StakingRevenueSource to the new TokenRateNotifier as a WithArgs observer, kind 1, so it receives a callback after each rebase.

    StakingRevenueSource  0x6220212a33a87Ed7Cc386B67eB2c393974F28C38
TokenRateNotifier     0xbe05d12Fd10919F1881125006523452F6aFF791b

  • Upgrade the LidoLocator proxy to the new implementation, repointing postTokenRebaseReceiver to the new notifier.

    LidoLocator proxy   0xC1d0b3DE6792Bf6b4b37EccdcC24e45978Cfd2Eb
new implementation  0xF2Ffb952e129a63F0614Ff87126E1d4a494A2313

  • Add BuybackAllocator as allowed recipient on the Stonks stETH top-up AllowedRecipientsRegistry for funding via the Easy Track.

    BuybackAllocator           0xAA568141c051f2D1132b110f8391F18D48E8D889
AllowedRecipientsRegistry  0x1a7cFA9EFB4D5BfFDE87B0FaEb1fC65d653868C0

  • Set the Treasury Management Committee as manager on OracleRouter to maintain the stETH and LDO feeds.

    manager (TMC)  0xa02FC823cCE0D016bD7e17ac684c9abAb2d6D647
OracleRouter   0x79ef3a538200Fe4981D67E7e886bfb36D4Cb5a31

  • Set the Treasury-mode Stonks on BuybackExecutor. The NEST operation mode is derived from Stonks.RECEIVER().

    Stonks, Treasury mode  0xb368586CB980895E51e1D82102E63b3F69d3F151
BuybackExecutor        0x6c213ca5A10Cc26548C742229569B4AeD2A9C9B7

  • Grant ALLOCATOR_ROLE to BuybackAllocator on BuybackExecutor. Lets the allocator fund the executor and trigger buyback processing.

    role  Buybacks.BuybackExecutor.ALLOCATOR_ROLE
      0x87905334ad07701d0cd9b21ea0599de1a0cab067e0ab49596d423d87159ac7f2
to    BuybackAllocator  0xAA568141c051f2D1132b110f8391F18D48E8D889
on    BuybackExecutor   0x6c213ca5A10Cc26548C742229569B4AeD2A9C9B7

  • Grant MANAGER_ROLE to the Treasury Management Committee on BuybackExecutor. Covers asset recovery to the treasury and LP withdrawal.

    role  Buybacks.MANAGER_ROLE
      0x24bec1f1283f989ed510b4d89bc7ef5002f20db1b60c1b3192336791c868543e
to    Treasury Management Committee  0xa02FC823cCE0D016bD7e17ac684c9abAb2d6D647
on    BuybackExecutor                0x6c213ca5A10Cc26548C742229569B4AeD2A9C9B7

  • 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.

    role  Buybacks.BuybackExecutor.EMERGENCY_ROLE
      0xc748c205190870b4e890036f373e30556929f7fbf3db8644c998a652c1996dbd
to    Treasury Management Committee  0xa02FC823cCE0D016bD7e17ac684c9abAb2d6D647
on    BuybackExecutor                0x6c213ca5A10Cc26548C742229569B4AeD2A9C9B7

  • Grant EMERGENCY_ROLE to the Emergency Brakes Committee on BuybackExecutor. Same emergency controls, held independently of the TMC.

    role  Buybacks.BuybackExecutor.EMERGENCY_ROLE
      0xc748c205190870b4e890036f373e30556929f7fbf3db8644c998a652c1996dbd
to    Emergency Committee  0x73b047fe6337183A454c5217241D780a932777bD
on    BuybackExecutor      0x6c213ca5A10Cc26548C742229569B4AeD2A9C9B7

  • Grant MANAGER_ROLE to the Treasury Management Committee on BuybackAllocator. Covers asset recovery to the treasury.

    role  Buybacks.MANAGER_ROLE
      0x24bec1f1283f989ed510b4d89bc7ef5002f20db1b60c1b3192336791c868543e
to    Treasury Management Committee  0xa02FC823cCE0D016bD7e17ac684c9abAb2d6D647
on    BuybackAllocator               0xAA568141c051f2D1132b110f8391F18D48E8D889

  • Call activate() on BuybackAllocator. Records the revenue baseline, so only revenue earned after activation funds the buyback budget, and starts the allocation process.

    BuybackAllocator  0xAA568141c051f2D1132b110f8391F18D48E8D889
10 Likes
112

The on-chain vote #204 is now live and includes the proposal to launch NEST in treasury-only mode, 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.

6 Likes
113

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 :crossed_fingers:). 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.

3 Likes
114

The on-chain vote #204 has been enacted and full NEST activation will follow the Dual Governance Proposal #13 execution expected to happen on Friday, August 14.

3 Likes
115

Dual Governance Proposal #13 has been executed - NEST is now fully activated.

2 Likes