Temp-Check: SLURP 40 | Establishing BUILD Reward Distribution for stake.link

[Asymmetric]

Abstract

This proposal solidifies a framework for distributing Chainlink BUILD rewards among stake.link participants. Today, Chainlink Labs confirmed via X that the first phase of the Chainlink Build claims mechanism is code-complete and expected to launch this year. This mechanism will make Build tokens claimable by Chainlink ecosystem participants, including Stakers. Given that full details on BUILD rewards have not yet been made public by Chainlink Labs, this framework mirrors the existing DAO fee structure to ensure a fair and efficient distribution model.

Rationale

The stake.link ecosystem consists of various ecosystem participants, including stLINK stakers, reSDL holders, node operators, and core contributors. With BUILD rewards expected to be allocated across these groups, aligning distribution with the existing staking fee model simplifies implementation, reduces development overhead, and ensures fairness. With this expansion stake.link will also transition to SDL (Secure, Decentralized, Liquid) from a branding perspective solidifying the possibility of BUILD Rewards next to Rewards of other LSTs. SDL, a basket of LST yield bearing tokens, resembles something such as a MSCI World ETF for blockchain. SDL is the native way to capture this yield. As such the Fee on BUILD Rewards offers a unique opportunity to bootstrap this value proposition.

Specification

The following distribution model will apply to all BUILD rewards received:

This is a modification of the current fee structure that exists in that it increases the delegation fee to SDL stakers from both the Node Operator Pool (currently 15%) and Community Pool (currently 10%) to 20% across the board.

Our rationale is that SDL stakers have shown long-term alignment with the protocol and deserve to be rewarded for that commitment. With the BUILD Program Rewards finally coming to light, SDL stakers are positioned to be rewarded handsomely for that alignment.

Additional Considerations

• Claim window: A claim threshold of 180 days will begin on the first day of eligibility for each BUILD airdrop to LINK Stakers. After 180 days, any remaining airdrops will be claimed by the DAO Treasury.
• Technical Feasibility: If Chainlink’s BUILD reward distribution mechanism requires an alternate structure, this framework may be adjusted accordingly.

Conclusion

This proposal ensures stake.link is prepared to distribute BUILD rewards efficiently while rewarding SDL stakers and adding further utility to the SDL token. Once more details about the BUILD reward distribution mechanism are available, the DAO can refine this framework as needed. Most importantly this enshrines a new era of the protocol by moving from just stake.link to SDL (Secure, Decentralized, Liquid).

[smartcondrums]

I’m down with this but the claim window might be a bit early. We still don’t know how it’s going to work.

I’d also like to ask if we might be able to implement some kind of auto swap election for the SDL stakers. If the user chooses, the protocol could auto swap the build tokens to either SDL or link, perhaps even for a small fee back to the treasury.

[Lyvoo]

I don’t agree with adding an auto convert at this stage.

I think that may divert the teams attention away from developing the core protocol as it’s would require a whole host of additional features and resources not currently implemented into the protocol.

If a user wants to convert then they can always do so on their on own.

Other than that very excited for BUILD rewards to finally come.

[Mawly]

I support this proposal as it thoughtfully positions stake.link to fairly and efficiently distribute upcoming BUILD rewards while strengthening the role of SDL stakers in the ecosystem. Aligning the reward structure with the existing fee model shows practical foresight, and the expanded utility for the SDL token adds long-term value. But I really like the domain stake.link, it’s clean, memorable, and reinforces the project’s clear focus which at the end of the day, and at its core, is staking LINK. Secure, Decentralized, Liquid could be an amazing slogan.

[Asymmetric]

GM Mawly,

Thanks for the thoughtful reply. To clarify: stake.link and the branding will always stay. It is likely though that it will stay LINK centric in the future as the number 1 place to go and stake LINK. The basket of LST thesis and analogy to the MSCI World of staking protocols needs a separate but somehow connected branding as it is much broader. This is why the acronym SDL (Secure, Decentralized, Liquid) makes so much sense as it is our Token Ticker anyway.

[Michael]

Autoconverting BUILD to SDL or stLINK would be amazing.

Claiming BUILD will already be a taxable event. Letting us choose which it is (a rebase or SDL) would be ideal. Especially if youre a wstLINK holder…

Anyone who doesnt want this can just swap their tokens (in our liq pool generating fees) and buy the tokens they want, as its ALREADY a taxable event claiming tokens there is no issues beyond audit costs.

Our automation being the fastest around is also Key in this venture as we will ensure best pricing as well. I like the way you think SCD

[Erazz]

Will we follow the technicals of builds rewards as they are done by chainlink or will we be doing something by ourselves ?
Will the build rewards be proportional to time spent in the Stlink pool ? Will it be a snapshot ?

I think so far the text only describe a protocol perspective and not a user perspective.

I know it is kind of stated in “Technical feasibility” but i think before applying fees to users we should think about the fairness of distributing BUILD rewards to our users.

[Lyvoo]

On this, I think a blanket approach should be applied.

Hold 1% of stLink - Get 1% of the airdrop.

We shouldn’t take a time based approach as it disincentives people to stake with us.

[Michael]

this is pretty much impossible to know and speculating at best that people will be rewarded from CLL based on time staked. we need more info from CLL before anything can be set in stone with us as a dao (in my opinion)

[Ari]

I support the intent behind SLURP-40 and believe it is a valuable step toward establishing a sustainable and incentive-aligned distribution model for BUILD rewards. That said, I strongly recommend that we hold off on finalizing any fee structures or reward routing mechanisms until the mechanics of BUILD distributions are more clearly defined by Chainlink and participating projects.

To help inform this discussion, I’ve conducted an analysis comparing the net BUILD rewards earned by a stLINK holder (who benefits from stake.link’s split between the Operator and Community Pools) versus a user staking the equivalent amount of LINK directly in the Chainlink Community Pool.

The results show that the relative performance of stLINK compared to direct Community Pool staking is highly sensitive to how BUILD rewards are allocated between the two pools.

Key insight: Under the SLURP-40 fee model, the break-even point occurs when approximately 25.5% of a project’s BUILD rewards are allocated to the Operator Pool.

• If the Operator Pool receives less than 25.5%, direct Community Pool staking results in higher net rewards.
• If the Operator Pool receives more than 25.5%, stLINK holders outperform — and that outperformance grows significantly as the allocation to the Operator Pool increases.

This is due to stake.link’s concentrated position in the underfilled Operator Pool, which captures a disproportionately large share of rewards, more than offsetting the higher fee rate applied there.

Here is a graph that visualizes the relationship between reward allocation and relative performance of stLINK holders:

Importantly, this analysis reinforces a guiding design principle I fully support:
stLINK holders should receive rewards that are at least equivalent to, and ideally greater than, what they would earn by staking in the Chainlink Community Pool directly.

I believe this is vital for preserving user trust, maintaining a competitive staking product, and ensuring sustainable TVL growth for stake.link.

As such, I am in favor of SLURP-40 as a framework for exploration, but I strongly recommend:

• Holding off on finalizing fee percentages or distribution weights until BUILD mechanics are confirmed

• Continuing to model reward impact under different scenarios as more data becomes available

• Codifying parity with Community Pool staking as a baseline goal for stLINK rewards, even after applying protocol fees

Looking forward to refining this collaboratively as BUILD becomes more concrete.

[Asymmetric]

GM @Ari,

Really appreciate this. Very thorough and thougtful analysis and agre on most things. Would love to see more community members to put in the time to go into the depth of these SLURP and bolster our governance.

In terms of execution speed and prepardness I would rather ratfiy a fee scheme such as the one proposed in the SLURP and then adjust if the result is suboptimal and once more details are released. That way we can proceed immediately if an announcement happens and the result is optimal per your analysis. Otherwise, we are in a react situation and take time to ratify anything.

Best,
Asymmetric / Joe

[SethVdL]

Agree with Asymmetric. For the same reasons of wanting to have something ratified/preparedness, I put this out there a while back with Slurp 17. Per Jonny’s comment on that SLURP, it’s unknown if the fee structure can even be changed in a feasible manner anyway. I am not sure if that is still the case.

[EqS]

Great to have some more thinking on this topic following SLURP-17. Just a few points:

• Agree with providing additional utility to the token by increasing the BUILD reward rates above the delegation fee rates.

• There is a fairness factor in that those who have staked reSDL for a shorter period will be equally rewarded as those who have staked for longer durations (as I understand the proposal). It will be interesting to see if Chainlink Labs factors staking duration in their rewards to those in the Community Pool. We may wish to align with their approach and this could be achieved by using reSDL NFT mint dates.

• I am strongly opposed to a feature being built to allow automation conversion of BUILD rewards. There would be a real reputational risk in enabling this and particularly as CLL is an ecosystem participant.

• The claim window could be expanded. I have noticed some users missing out on airdrops due to lack of awareness.

• Any unclaimed rewards could be distributed to SDL stakers rather than to the DAO.

[Asymmetric]

GM @SethVdL and @EqS, thanks for you comments. I remembered SLURP-17 too late otherwise I would have probably continued the discussion under that index.

@EqS what would be your proposal to expand the window? I think 180 days is pretty reasonable for an active community. Why would you go the roude via SDL stakers? They probably would have claimed the Airdrop already so would need to reclaim dust after the window closed.

Best,
Asymmetric / Joe

[EqS]

Perhaps 365 days? The claim period could also just be aligned with the approach that CLL takes with the Community Pool. I do think that their approach (including allocations reflecting staking duration) should be taken into consideration. So maybe just a case of wait and see.

Good point about the unclaimed rewards likely being dust. Probably best then for the DAO to take anything unclaimed.

[tsoudi]

Temp Check SLURP-40: Establishing BUILD Reward Distribution for Stake.link

Core Objective

• Outline how Chainlink BUILD tokens will be distributed among stake.link participants (stLINK, SDL stakers, node operators, and the DAO) once Chainlink’s BUILD program is live.
• Keep the system simple by adapting the existing fee model (used for other protocol rewards), while slightly increasing SDL stakers’ share.

Proposed Structure

• Mirror the Existing Fee Distribution: BUILD tokens would be allocated following the same splits as current staking rewards.
• Boost SDL Stakers’ Cut to 20%: The portion going to SDL stakers (reSDL holders) is increased from earlier levels to 20% of all BUILD rewards.
• Claim Window: 180-day timeframe for users to claim their BUILD rewards; any unclaimed tokens go to the DAO treasury.

Reasoning & Benefits

• Consistency: Re-using a proven distribution model reduces complexity and development overhead.
• Stronger Incentives: Increasing SDL stakers’ share rewards their long-term alignment, boosting the SDL token’s utility.
• stLINK Competitiveness: Keeping stLINK holders on par or better off than directly staking in Chainlink’s own pool remains a key commitment.

Stakeholder Impact

• stLINK Holders: Continue earning the majority of BUILD, with upside if the Operator Pool gets a higher allocation.
• SDL Stakers: Significantly rewarded (20% share), encouraging deeper commitment.
• Node Operators: Keep their share intact but pay a slightly higher SDL fee; seen as a worthwhile trade-off for a robust, well-funded ecosystem.
• DAO Treasury: Retains a portion as per the fee split and any unclaimed BUILD after 180 days.

Community Feedback

• Generally positive, focusing on small refinements and practical implementation details.
• Discussion points include possibly adjusting the claim window, monitoring how Chainlink will distribute BUILD, and being open to revisiting the split if needed.
• Automatic token conversion (e.g., BUILD to SDL or LINK) was debated but is currently seen as low-priority relative to core protocol needs.

Key Takeaways

• SLURP-40 is a forward-looking plan ensuring stake.link is ready to handle BUILD without overcomplicating the reward flow.
• By prioritizing fairness and SDL staker incentives, the proposal aligns with the network’s broader vision and positions stLINK holders advantageously.
• The community is supportive, provided adjustments remain possible once Chainlink finalizes the BUILD details.

[Ari]

I think this SLURP is a good starting point. Based on the modeling I’ve done, the proposed fee structure seems reasonable in many likely scenarios. That said, there are still too many of unknowns, including how BUILD rewards will be allocated between pools and whether they’ll come with any time-based conditions or other restrictions.

Given that, I support moving forward so the DAO is prepared when BUILD rewards go live. At the same time, I think it is important we signal our willingness as a DAO to revisit and adjust the structure if needed. Ideally, we should aim to keep the BUILD reward ratio between stLINK holders and Community Pool stakers as close to 1:1 as possible. If that balance shifts significantly due to how rewards are distributed we should be ready to reassess.

One additional thought: I think it would be helpful if proposals like this included more context around how specific numbers were determined. Understanding the reasoning or assumptions behind the figures makes it easier for the community to evaluate, give feedback, and build on the proposal constructively. If anyone working on future SLURPs wants help with modeling or framing, I am happy to help.

[Mawly]

Hey guys

Just adding my 2 cents on this:
“I am strongly opposed to a feature being built to allow automation conversion of BUILD rewards. There would be a real reputational risk in enabling this and particularly as CLL is an ecosystem participant.”

Automated dumping of BUILD projects for more SDL/LINK, in my opinion, should never be made as a streamlined option by stake.link developers, as it would damage optics and/or create friction between stake.link and the rest of the community.

F.ex “CLL made all these build rewards available for me but stake.link automation dumped the prices to near zero diluting rewards on an individual basis”

The pros of making this function for auto-conversion would exclusively affect end users, while the cons would exclusively affect the protocol.

I think we should prioritize the protocol over individuals, and act near-neutral on these build rewards. This to ensure stake.link’s optics is skewed towards being a productive ecosystem participant, as opposed to being a desctructive ecosystem participant.

[Sinbua]

I completely agree with everything Mawly mentioned, point by point. The protocol’s neutrality in this kind of decision should prevail over any potential advantages such an implementation might bring to end users. The potential for reputational damage is way too big.