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

4 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.
8 Likes