First, this is good work, and thank you for modeling the mechanism end-to-end rather than just reacting to the counter. The timing is right: raising this now, before the 2027 budget request is drafted, is exactly when a change like linking the threshold to the budget can make it into the request rather than waiting a full cycle. Some of what you propose I think is right, and I’ll flag it to the team. On the rest, I either see it differently or want you to tighten the argument. Going through it in order.
Step 1
Tying the threshold to the approved budget. I agree, and I think it belongs in the Grant request vote itself. I’ll raise it with the team; the 2027 request is the natural place to settle this, ideally in the same vote, exactly as you suggest.
The size of the cut (~30% / ~$30M). The logic is clear, and I follow it. But a number like that has to come out of actual bottoms-up planning, not the model alone, which is exactly what the budget request is for. So specific figure TBD.
A separate Easy Track top-up program for NEST. At first glance, this reads as a no-brainer, but the shared limit was a deliberate resource-optimization decision, not an oversight. We don’t see the $10M limit as binding within the existing TMC Easy Track. It is a limitation in the sense that it is a shared ET with TMC and any selling of stETH or swaps. Therefore scaling is capped but should be sufficient for $10M. If you think NEST needs its own program, it would help to explain why the current limit is a real constraint.
Not using NEST-bought LDO for contributors’ grants. I want to make sure I understand the concern because I don’t think the silent-distribution path you’re worried about exists. If the DAO approves contributor grants in LDO, that appears in a grant request or separate proposal. The current contributor program (TRP, 22M LDO allocated from treasury) ends October 31. Any further treasury LDOs for contributors will be visible in a grant request. There’s no mechanism to quietly pull LDO from the treasury; it’s always a public move.
Step 2
Connecting additional DAO income NEST doesn’t capture. This was always part of the plan. The mechanism was built to be modular, so new sources can be added as it grows. It makes sense to wire them in once revenue from newer lines is material enough to be worth it. Right now most of it is still ramping, relatively immaterial compared with revenue (~$1.3m for H1).
One caveat: treasury operations aren’t Included because those include substantial exchange losses on stETH, which make total treasury income negative. Even with all contributions made.
Separately, and this is my own flag, not part of your proposal, we should look at whether the cumulative counter resets at the year boundary. There are arguments on both sides, and I want to bring it up for consideration on the research forum.
On your questions, here’s what I can answer now:
-
Why NEST counts only staking revenue. Staking is by far the largest source. The others are still ramping or effectively zero. As above, the mechanism was built to be modular so sources can be added as they grow. This is a start-with-what-matters choice, not an oversight.
-
Whether CSM rebates are in reported net staking revenue / referral payouts in H1. CSM rebates are included in financial reporting, but they are not counted by NEST; they reach the Treasury as separate monthly transfers rather than through the on-chain staking fee NEST reads (recently ~30–34 stETH/month; 161.54 stETH in H1 2026, ~294 stETH YTD through September).
-
How NEST is topped up and why it shares an Easy Track limit. It is on one of the existing Easy Track (TMC one) and has already been topped up once, so fully ready for the first buyback. As above, the shared limit was a deliberate optimization, and we don’t see it as insufficient for at least this year. If you have a specific concern, I’d like to understand it.
-
What’s planned for the purchased LDO, and will liquidity mode be used? No specific plans for the purchased LDO. On liquidity mode, there are a few blockers. One is a depth check: at current levels, liquidity mode doesn’t grow LDO liquidity on the market, which was the point of building it. It may be proposed to the DAO later, but it won’t be used without an explicit DAO decision.
-
Was the four-day deficit expected at launch? Yes it follows from the technical limitations of the launch. And given how long ETH sat at low prices before NEST went live this year, it’s more or less fair.
-
Which vote and role would change the threshold? The threshold parameter is gated behind DEFAULT_ADMIN_ROLE, which is held by the Voting contract. Changing it requires an on-chain vote.
Again, useful and well-argued. I’d rather settle the budget–threshold link in this year’s request than leave it for the next cycle.