Abstract
This proposal defines a clearer long-term framework for how stake.link should structure and manage DeFi incentives around its LST ecosystem.
It does not seek a new governance vote for every small operational adjustment. Instead, it proposes:
- a clearer budget architecture
- a formal market lifecycle for the Flexible Programme Budget (FPB)
- a practical governance boundary between what should be fixed by vote and what can be adjusted operationally
- a shared reporting standard, so the community can easily follow incentive-related decisions over time
The goal is simple: make better, more disciplined decisions with a limited incentive budget, while keeping the framework flexible enough to adapt as stLINK grows.
This proposal builds on the live incentive structure and the foundation laid by earlier DeFi-related work and discussions, especially SLURP-26, SLURP-59, and SLURP-62-A, while aiming to present a more durable and easier-to-follow policy structure.
Rationale
stake.link now has enough recurring DeFi-related rewards to justify a more formal policy layer.
A yield-bearing LINK token should already be attractive to DeFi protocols on its own merits. That is one of the structural advantages stLINK brings as a primitive. Incentives should therefore be understood as tools to accelerate adoption, improve market formation, or address relevant bottlenecks — not as a permanent substitute for underlying product quality.
The issue is not whether incentives should exist. The issue is how they should be structured, where they should go, and how decisions should be made without forcing a new SLURP for every minor shift.
This proposal therefore tries to do three things:
- show the full DeFi incentive picture, not just one slice of it
- define how new markets should be onboarded and supported
- make it easier to monitor, adjust, and explain the programme over time
This should be read as a framework and an initial recommendation set, not as a rigid smart contract-style rulebook.
Budget Architecture
The framework combines two recurring sources: the protocol-level DeFi-PoL fee and Treasury reSDL rewards. The first maintains core stLINK liquidity and funds the protocol-side FPB. The second maintains an SDL liquidity floor and adds treasury-side support to the FPB.
| Budget line | Source | Default allocation | Current amounts (per 30 days) | Adjustment scope |
|---|---|---|---|---|
| Core stLINK Liquidity | 3% DeFi-PoL fee | 2.5% | ~755 stLINK | Governance |
| Flexible Programme Budget (protocol side) | 3% DeFi-PoL fee | 0.5% | ~151 stLINK | Governance |
| SDL Liquidity Floor | Treasury reSDL rewards | 50% minimum | ~80 stLINK | FPB Stewards may increase, but not reduce below the floor without governance approval |
| Flexible Programme Budget (treasury side) | Treasury reSDL rewards | 50% | ~80 stLINK | Residual after SDL floor |
| Total Flexible Programme Budget | Protocol-side FPB + treasury-side FPB | — | ~231 stLINK | Managed within the framework |
Figures are shown in stLINK-equivalent for readability. In practice, most incentive distributions would flow as wstLINK.
What this proposal does and does not do
This proposal does:
- define the budget structure
- define how the FPB should work
- define how new markets should be onboarded
- define how active markets should be treated once live
- define the reporting and governance expectations around FPB management
This proposal does not:
- require a new governance vote for every small adjustment
- hard-code a permanent winner-takes-all market hierarchy
- require FPB support for every stLINK integration
- imply that every future market should automatically receive incentives
Core Principles
The purpose of this framework is to grow stLINK adoption, utility, and propagation across DeFi. The objective is not to subsidise every market equally, but to direct incentives where they can still meaningfully change behaviour and help expand the usefulness of stLINK.
As markets mature, incentives tend to have diminishing marginal impact. A market that is already healthy and sufficiently saturated will usually respond less to incremental rewards than a market that is still in its launch phase. That is why Launch Markets will often justify a more concentrated share of the Flexible Programme Budget than Mature Markets.
This framework is intended to provide guidance and discipline, not to function as a rigid formula. Every integration is different, and the final shape of any launch should still be assessed in its own context, with incentives directed where the most relevant bottleneck exists and where additional rewards are most likely to produce meaningful marginal impact.
FPB Market Lifecycle
Candidate Market
A market does not enter FPB automatically. To be considered, it should be introduced through a formal onboarding SLURP and should demonstrate:
- strategic relevance for stLINK
- meaningful use of stLINK or wstLINK
- a clear value proposition
- measurable objectives
- a credible path to useful scale and liquidity
The onboarding proposal is where governance decides whether the market should be admitted and how aggressively it should be supported.
Launch Market
Once approved, a market enters a Launch phase. This is the stage where incentives tend to have the highest marginal impact, especially when a market is:
- new
- supply-constrained
- strategically important
- or trying to validate a meaningful new stLINK use case
A Launch Market may receive:
- a minimum viable seed
- a majority share of FPB
- or, if justified by current conditions, up to the full FPB temporarily
This is an available option, not a default expectation. The exact launch allocation should be discussed in the onboarding SLURP for that market.
Mature Market
Once a market is established and no longer in its initial bootstrap phase, it should transition into a Mature Market state.
At that point, it competes for FPB under normal dynamics alongside other approved markets.
Mature Markets remain eligible for support, but generally should not be treated the same way as Launch Markets unless there is a clear reason to do so.
General prioritisation logic inside FPB
The framework should not pre-assign permanent fixed shares of FPB to future markets.
Instead, it should follow these broad principles:
- Launch Markets are usually the first place where FPB should concentrate
- Mature Markets compete comparatively once multiple approved markets are active
- If no FPB-supported market justifies additional deployment, rewards may be redirected toward core stLINK liquidity
- Only if extra incentives are unlikely to have meaningful impact anywhere should FPB pause and accumulate
This matters for one additional reason.
Current core stLINK liquidity incentives include both stLINK and SDL, and some live DeFi markets — including the Morpho LINK market — are also currently supported by both. This proposal does not attempt to rewrite those live allocations immediately.
However, one intended effect of the framework is to improve the protocol’s ability to support priority markets with wstLINK-based incentives over time, so that SDL emissions can be reduced or phased down more responsibly. In practice, FPB-supported markets should increasingly rely on wstLINK incentives by default, while SDL emissions become more exceptional or transitional where viable.
Accordingly, if FPB is not urgently needed in Launch or Mature Markets, rewards may be redirected toward core stLINK liquidity before defaulting to pause-and-accumulate. This would help reduce reliance on SDL emissions where possible, rather than leaving the protocol dependent on dual-token incentive structures longer than necessary.
Current examples & initial recommendations
The framework is intentionally abstract, but current examples help show how it can be applied in practice.
Morpho LINK Market
The Morpho LINK market is currently the clearest Launch Market example.
The logic is straightforward:
- it is already live
- it already shows meaningful demand
- it still appears supply-constrained
- and supporting it grows stLINK utility directly through the looping / LINK borrowing use case
This makes it the strongest current example of where concentrated FPB support can make sense during a market’s launch phase.
Morpho Stablecoin Market
A stablecoin market using wstLINK as collateral could also become a strong Candidate Market under this framework.
Its purpose is different:
- it may help attract users currently borrowing stables against LINK elsewhere
- it expands the utility surface of stLINK as yield-bearing collateral
- and it can create a complementary path to the LINK market
However, this type of market should still enter through a formal onboarding SLURP. That onboarding proposal would determine whether it should remain a Candidate Market, move into a Launch Market phase with a minimum viable seed, or receive a larger temporary allocation if governance believes parallel launch is justified.
This proposal therefore does not try to decide that in advance. It simply provides the framework within which that decision can be made.
Other venues
This framework is not exclusive to one protocol.
A venue such as Folks Finance can also fit into this structure, particularly once markets move into Mature Market dynamics. The key point is that the framework should remain venue-agnostic while still being disciplined about where incentives are likely to have the greatest impact.
Initial recommendation
As an initial recommendation, the cleanest approach today still appears to be:
- treat the Morpho LINK market as the clearest current Launch Market
- let any stablecoin market be evaluated first as a Candidate Market through its own onboarding SLURP
- and preserve enough flexibility for future approved markets to enter the framework as conditions evolve
This does not prejudge the outcome of any future onboarding proposal. It simply reflects the current reality that concentrated support usually makes more sense where demand is already present and where additional incentives can still materially move the market.
FPB support is not a prerequisite
stLINK can be integrated permissionlessly across DeFi protocols.
Being part of the Flexible Programme Budget is not a requirement for an integration to exist, succeed, or be considered strategically valid. Likewise, FPB support should not be interpreted as a prerequisite for adoption, nor as a strict indicator of formal partnership unless explicitly stated.
A community member may also propose FPB support for an integration even if the team behind that venue did not initiate the proposal. FPB support should therefore be understood as a strategic incentive decision within this framework, rather than as a condition for integration itself.
Governance scope and parameter adjustments
This proposal tries to draw a practical line between what should be governance-protected and what should be adjustable within the framework.
Governance-protected baseline
The following should be treated as governance-level decisions:
- the 2.5% / 0.5% protocol-side split
- the existence of the FPB framework itself
- onboarding of new Candidate Markets into FPB
Operational adjustments inside the framework
Once a market has been approved through governance, market-level deployment inside FPB should be handled with lighter operational flexibility.
The current intended FPB Stewards structure is: NAIL + 2 Community Council members. All three must agree on operational changes. If agreement cannot be reached, a snapshot vote can resolve the issue. Anyone should be able to suggest parameter adjustments or raise concerns.
Treasury split safeguard
The treasury split should keep 50% minimum to SDL liquidity. That is the floor.
FPB Stewards may increase the SDL share above 50% if justified by market conditions, but reducing it below 50% should require governance approval.
This gives SDL LPs a credible minimum while still allowing some operational flexibility.
Community visibility
Operational changes should be reported publicly in the governance forum thread before they are enacted, particularly where they are material.
The goal is to balance speed, flexibility, transparency, and community oversight without forcing unnecessary SLURP fatigue.
Reporting and dashboard expectations
A dedicated public dashboard should exist so anyone can quickly understand the state of the framework.
At minimum, it should show:
- current FPB budget
- current treasury reward flow
- current SDL liquidity floor
- active approved markets
- whether a market is Candidate / Launch / Mature
- current allocation of FPB by market
- TVL
- utilisation
- borrow activity
- reward flows
- relevant parameter values
- historical changes and notices
This is important for two reasons:
- it makes the framework easier to follow
- it reduces the need for constant debate over small adjustments by making the relevant information visible to everyone
Extensibility to other stake.link LSTs
Although current examples focus on stLINK, this framework should be able to expand to other stake.link LSTs over time once they reach sufficient scale, market readiness, and available liquidity.
The exact conditions for that expansion do not need to be fully specified here, but the architecture is intentionally designed so that it can support more than one LST once the ecosystem is ready.
Final note
Final note
This framework stands on work already done.
It owes a clear debt to the contributors who helped shape the discussion around DeFi-PoL and market incentives, and especially to the earlier SLURPs and discussions that laid much of the practical groundwork. Special thanks to @Tokenized2027 for the earlier proposals and integration work that helped make this framework possible, and to @EqS, @Erazz, and others who took the time to read, challenge, and refine the ideas in this proposal.
For a relatively tight flexible budget, this may feel somewhat over-engineered. But that is precisely why a coherent framework matters.
Scarce capital benefits most from:
- better structure
- clearer priorities
- more transparent trade-offs
- and a shared process for adapting over time
If this framework helps stake.link make more disciplined and more optimal decisions as it grows stLINK utility across DeFi, then it will have done its job.
We are all building this together.
Copyright and related rights waived via CC0.
