I don’t see value in this comment, moving on.
just tell the truth base on current tokenomics, may be useful for people who didn’t aware about the situition
I understand why LDO holders are concerned about price performance. The trend in this thread seems to be that revshare with LDO holders would be the solution.
In my view there are two separate questions.
1. The case for NEST / liquid buybacks
NEST is a mechanism that should remove LDO from circulation and following the laws of economics, all things being equal, less supply would mean an increase in price.
Thing is… market conditions suck and conditions for NEST to trigger seem far away. So we are left with a mechanism that doesn’t trigger in bear markets. But wait… this is by design:
So there is a logic behind NEST, but in times like now, where the execution seems far away and the action happens very far away from the realm of even considering triggering NEST, we might need to find another mechanism that supports LDO price to address the concerns that holders are losing USD denominated value.
2. The practicality of alternative value-accrual mechanisms
In principle, I understand the appeal of mechanisms that give LDO a more explicit economic utility. I’m simplifying a lot, but let’s say that we still maintain the revenue >40M. We want to maintain this because we want to make sure we can continue operations, and reinvest in the protocol growth. If we spend all revenue by giving away to LDO holders… duh, we eat today but we’re burning the protocol to the ground and we’ll be hungry tomorrow.
So, maintaining this >40M revenue, looking at the report: GOOSE-2025 & EGGs-2025 Final Report that’d give us… 0.5M.
These mechanisms (like LDO staking) are not cheap to design, implement, govern and maintain, so we would probably end up spending way too many resources implementing it for a meagre distribution that would make nobody happy anyway. In summary, the juice is not worth the squeeze.
EVEN if it was free to implement, or we did direct distributions to LDO holders (just airdrop stETH), it would be not a lot of money for individuals and we would be depriving the DAO from treasury that it might need to survive, grow and get better.
It’s normal to feel like everything is going to shit, portfolios are red, we’re down bad… but trying to maxx extract from one of the DAOs that have proven solid, with product and will weather the storm and grow could prove very short-sighted.
4 Likes
You managed to build mechanisms for ETH and USD, but for LDO it suddenly becomes “too hard”? Very convenient logic.
So the simple question is: what is LDO even for?
If the token gets no real value capture, no meaningful support, and no direct benefit from protocol growth, then it’s just a governance wrapper with no substance.
All the talk about “bad timing,” “high implementation cost,” and “protecting the treasury” sounds like an excuse.
The DAO has had no problem extracting value across the ecosystem, but when it comes to LDO holders, there is always no mechanism, no priority, and no will.
If the token is denied any real economic role, people are absolutely justified in seeing it as a slow rug on holders.
1 Like
Actually LDO just token to vote, so it is not asset to invest because there is no yield
so if you are investor, at the time you decide to buy you should know that it like donor to charity. Because when the big holders mean who want get vote power hold enough vote powers, they dont care about fdv or pricing anymore.
So, only retails in the pool, when retrailer become smarter, and realized LDO just vote ticket which is useless because even you buy all the pool, you still dont have enough vote power to rule any decide.
That time no one needed it anymore, the late commers because exit liquid.
1 Like
honestly but when TVL increase, revenue increase, holders get nothing
but when TVL down, protocol hacked or collapsed, holders is the first frontline to be rekt
1 Like
I think we need to be honest, it’s not going to shit it is shit and Ldo is among the worst performers for many years. Instead of short term extraction we have long term destruction.
Market share down from 33% to 22%
LDO down from 4$ to 0.2$
Staked eth down from 9.8 to 9.1 eth
Treasury spend 100+m in last 3years and results of this spend is represented on the metrics.
We should be honest and accept what we have and think how to change all 4 points.
2 Likes
Just as a senior wage cuck, I would assume everyone should be fired for constant underperformance. But fortunately it’s a dao and not a real business
2 Likes
If NEST v1 has been technically ready since December, what exactly is blocking a Snapshot vote today?
The community needs a clear deadline, not another delay pushed into Q2 2026.
4 Likes
Buybacks should be treated as capital allocation, not as a substitute for token alignment.
This misconception is not unique to DAOs. I have seen the same pattern in traditional finance and public companies as well: buybacks are sometimes used to satisfy investors or support the asset price, rather than being evaluated first as an investment decision. For any revenue-generating organization, that is a poor use of capital.
If a DAO believes its token is undervalued relative to its treasury assets, buying it can be rational. But if the goal is mainly to create the appearance of token alignment, then it is a weak solution.
In a DAO, token alignment should come from a strong delegate body that represents tokenholders, recurring public financial transparency, and a governance system where tokenholders have a reason to delegate and participate.
If buybacks are mainly used to compensate for weak governance, weak transparency, and weak tokenholder alignment, then they do not solve the actual problem.
2 Likes
Small clarification on what NEST v1 MVP actually is: it’s base infrastructure — a module that enables the creation of LDO/wstETH pairs via Stonks. It has no logic for when to execute, under what conditions, or with what caps.
The proposal on the table builds the automation layer on top of NEST MVP: eligibility gates, spending caps, surplus model, and permissionless execution. That’s the mechanism. NEST MVP, without it, is a set of contracts that does nothing on its own. Deploying it standalone and calling it live buybacks would be misleading;
Fair point on the capital allocation framing: that’s the right lens, and it’s exactly how the Utilizing Market Opportunities: stETH / LDO trade - #35 by lidoecosystem-ops proposal is structured.
Where I think the framing conflates different things: NEST is not about whether LDO is undervalued right now, and it’s not a substitute for governance quality or financial transparency. It creates a rule-based on-chain link between protocol surplus and LDO, when the protocol earns above its operating baseline, a bounded share converts automatically, under hard caps. That’s a different instrument, not a competitor/substitute to a strong delegate body or recurring reporting.
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.
8 Likes
Hello, this is Greg from Analytics Stream. I would like to elaborate a little bit on the chosen model, approach, and proposed parameter values.
Considered options
Note: This section is only for context; for the cumulative model justification, please proceed to the next section.
The initially proposed approach for buybacks sounds like: “Once daily revenue is higher than daily costs and the ETH price is higher than $3,000, we allocate 50% of the surplus to buybacks.” (Daily costs are calculated as yearly operational costs ($40M) divided by 365.)
In order not to overspend, we also add a daily cap, which does not allow a daily buyback higher than a certain value. Next, we backtested this approach on 2024 and 2025 (daily rewards source) and got the following results:
Table 1. Initial model backtesting results
| 2024 | 2025 | |
|---|---|---|
| Total rewards ($) | 51,699,284 | 42,481,543 |
| Target spend ($) | 5,849,642 | 1,240,771 |
| Actual spend (no daily cap) ($) | 4,972,594 | 2,626,009 |
| Share of target (no daily cap) | 85% | 212% |
| Actual spend (daily cap = 10,000) ($) | 1,992,649 | 1,471,127 |
| Share of target (daily cap = 10,000) | 34% | 119% |
Here arises the main problem with such an approach: no matter which daily cap we used, we underspent in 2024 and overspent in 2025 (no overspend occurs only with a small daily cap of around $5,000–$6,000).
Reason for underspending in 2024: There were many days when, even though daily revenue was higher than daily costs, no buyback was performed because the ETH price was lower than $3,000.
Reason for overspending in 2025: In the first half of 2025, we had many days when daily revenue exceeded daily costs, and these rewards were spent on buybacks. However, in the second half of 2025, there were days when daily revenue was lower than daily costs, which caused not only the absence of buybacks but also a shortfall in funds for operational costs.
To put it in a nutshell, the main problem with such an approach is that on “good” days we spend the surplus, but on “bad” days we accumulate losses, which are not compensated for by future or previous surpluses. That is why the idea of a cumulative model emerged.
Cumulative model
As described above, NEST uses a cumulative surplus model. Each day, staking revenue is compared to the $40M/year operating baseline (~$109k/day). If revenue exceeds it, the surplus increases the 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.
Let’s put it in real numbers for the years 2024 and 2025. Initially, we considered 3 different options:
Perform buybacks once the ETH price > $3,000 USD and unrealised buybacks > 0, with an allocation share = 50% (this rule is the same for every option).
Option 1: Calculate cumulative losses and surplus.
Option 2: Calculate cumulative losses on all days and surplus only on days when the ETH price > $3,000 USD.
Option 3: Do not take into account days when the ETH price is < $3,000 USD for either surplus or losses.
Applying this to historical data, we receive the following result.
“Daily cap (50,000)” shows numbers for the previous methodology with a $50,000 daily cap.
Absolute values
Table 2. Cumulative model backtesting, absolute values
| Year | 2024 | 2025 | 2024+2025 |
|---|---|---|---|
| Rewards | 51,699,284 | 42,481,543 | 94,180,827 |
| Target buyback | 5,849,642 | 1,240,771 | 7,090,413 |
| Daily cap (50,000) | 4,935,753 | 2,557,875 | 7,493,628 |
| Option 1 | 4,972,594 | 2,114,617 | 7,087,211 |
| Option 2 | 4,835,836 | 1,037,854 | 5,873,690 |
| Option 3 | 4,955,919 | 2,624,190 | 7,580,109 |
Relative values
Table 3. Cumulative model backtesting, relative values
| Year | 2024 | 2025 | 2024+2025 |
|---|---|---|---|
| Daily cap (50,000) | 84% | 206% | 106% |
| Option 1 | 85% | 170% | 100% |
| Option 2 | 83% | 84% | 83% |
| Option 3 | 85% | 211% | 107% |
And here we would like to make a small deep dive into how the ETH price threshold and the daily cap work conceptually.
Parameter options: daily cap vs. ETH price threshold
Conceptually, both the daily cap and the ETH price gate can lead to leftover accumulation and allow us to start performing buybacks faster when we switch from “bad periods” to “good periods”, but they do so in different ways:
ETH price threshold: If we set the ETH price threshold to X, then even if on some day the surplus > daily costs but the ETH price < X, we do not perform a buyback. The surplus is still recorded as “unrealised buybacks”.
Daily cap: The daily cap does not allow spending more than its value on buybacks per day, so any revenue on days that exceeds surplus + daily cap will be recorded as “unrealised buybacks”.
Since the 3 considered options differ in how we treat days when the ETH price < X, if we set the ETH price to 0, they will all become the same.
Choosing the final option Let’s consider the following table, which presents 2024 and 2025 not as separate years but takes the overall numbers:
Table 4. Final numbers for all options with relative numbers
| % of target buybacks, daily cap = 50,000, ETH price = 3,000 | % of target buybacks, daily cap = 50,000, ETH price = 0 | % of target buybacks, daily cap = 20,000, ETH price = 0 | ||
|---|---|---|---|---|
| Year | 2024+2025 | |||
| Rewards | 94,180,826 | |||
| Target buyback | 7,090,413 | |||
| Option 1 | 7,042,846 | 100.0% | 99.3% | 96.9% |
| Option 2 | 7,042,846 | 82.8% | 99.3% | 96.9% |
| Option 3 | 7,042,846 | 106.9% | 99.3% | 96.9% |
From these examples, we can see that both the ETH price and DAILY_CAP could function as ways to accumulate unrealised buybacks. Given this, it seems more reasonable to use a less volatile and more predictable parameter (DAILY_CAP) for the buyback process. (Also note the property we mentioned above: once the ETH price is set to 0, all options behave the same.)
The cumulative methodology can work even without additional limiters such as an ETH price gate or a daily cap. However, we still suggest keeping them as safety parameters. The current recommendation is to start with ETH price = 0 and daily cap = $50,000. The proposed approach is:
Perform liquid buybacks equal to daily surplus × surplus share, when surplus > 0 and unrealised buybacks > 0, with a daily cap equal to $50,000.
Parameter values justification
Why do we need ETH price = 0?
Even though both the ETH price and the daily cap serve the same purpose, we decided to keep this parameter in order to have the ability to link buybacks to the ETH price in the future.
Why daily cap = $50,000? Historically, there were very few days when the surplus was > $50,000, but in the case of Oracle corruption, such a daily cap guarantees that we would not spend more than $300,000 (50,000 × 6 governance decision days).
6 Likes
Snapshot vote started
Please get your wallets ready to cast a vote 
, the NEST: Automated LDO Buyback and Liquidity Provisioning Snapshot has started! The Snapshots ends on Mon, 18 May 2026 16:00:00 GMT.
1 Like