Astar Foundation Forward: Tokenomics & dApp Staking discussion

[Juminstock]

@you425

Yes, I agree—what we need are calm, well-reasoned opinions from a broader range of participants.

I’m aligned with this perspective, and for that reason, I once again invite all members of the community to participate in this discussion, as it will directly and indirectly affect other areas of our ecosystem, bearing in mind that dApp Staking has been a central point where many initiatives converge.

@you425

If Plan B is adopted and rewards to dApps are reduced, and performance still does not improve afterward, the discussion will inevitably move on to finding the next target. That target is unlikely to be staker rewards, and there is a high probability that rewards for Agents, AFC, ACC, and similar entities would be reduced instead.

Yes, analyzing the root cause of the current situation is essential, and work is already underway to improve it. As mentioned in my previous point, this also impacts other areas within the Astar Collective, such as contributor rewards. However, it is important to clarify that if all bodies work toward a substantial improvement and the sustainability of the protocol, positive repercussions will eventually follow, and this is precisely what is happening now.

@FFR23

Maybe i’m missing the point, but option B is reducing rewards to dApps that don’t generate any value.

In fact, the Option B proposal suggests the complete removal of dApps, including both those that generate value for the ecosystem and those that do not. For this reason, it is not a particularly viable option if we take into account this important aspect of dApp Staking: the dApps themselves.

@FFR23

Let’s increase threshold for being a part of dApp staking and support high-value dApps with effective staking rewards.

In light of this, the ACC is working on a proposal to improve the situation.

@FFR23

The community can’t be relied upon to monitor dApps that are key to Astar success.

That is why one of the ACC’s main responsibilities is precisely this, and we have carried out a substantial cleanup of the dApp ecosystem since this governance body was established.

@Vangardem

The community council must plan new ways to combat inefficiencies and ensure that both dApp Staking and other subsidies reach a safe harbor; otherwise, we will continue in free fall.

Yes, the ACC will work on this.

cc @Community_Council

[FFR23]

@Juminstock

@FFR23

Maybe i’m missing the point, but option B is reducing rewards to dApps that don’t generate any value.

In fact, the Option B proposal suggests the complete removal of dApps, including both those that generate value for the ecosystem and those that do not. For this reason, it is not a particularly viable option if we take into account this important aspect of dApp Staking: the dApps themselves.

So option B is:

Instead of users wishing to choose their own dApp to stake on, the user now stakes to a centralised single entity.

This single entity then distributes rewards to qualified dApps / projects.

Right?

[Juminstock]

@FFR23 It could be, of course.

The Option B I proposed in my original post is exactly that, just a proposal that can be modified as this discussion requires.

The idea with this thread was precisely that: to hear the community’s opinion regarding dApp Staking, and to avoid opening a blank discussion or creating alternate topics, I proposed these two options.

But again, they are just proposals. Feel free to suggest changes to the options presented or to propose your own options.

[SimonB]

Thank you, @Juminstock — I understand your concern, and I agree with you on an important point:
Plan B is clearly more user-centric and does reduce part of the current focus on builders.

That said, I think the real question we need to ask ourselves is a harder one:
what has the current balance between users and builders in dApp Staking actually produced so far?

After several years of data and real-world execution, I don’t think we can avoid an uncomfortable conclusion:
this model has not generated the value it was supposed to create.

We’ve distributed rewards continuously to a large number of projects that, in many cases, have:

• delivered no meaningful utility to the network,
• created little or no value for the ASTR token,
• and provided limited real benefit to end users.

In practice, dApp Staking has often rewarded existence rather than impact.
And I believe this is exactly why this discussion exists today.

We can certainly try to improve the current system by:

• raising entry barriers,
• simplifying mechanics (as in Plan A),
• tightening rules and criteria.

However, in my view, these are incremental and likely temporary fixes. They may improve the surface, but they don’t fully address the structural problem.

From my perspective, if the goal is to foster high-quality, valuable, well-built dApps, then we may need to rethink the model more radically:

• allocating resources to fewer, carefully selected projects,
• supervising them step by step during development,
• having visibility into team composition and execution capacity,
• and funding builders based on concrete progress and delivered value.

I don’t see this as being “against builders” — quite the opposite.
I see it as a way to seriously invest in builders who are truly capable of growing Astar, instead of spreading rewards thinly across many projects with little accountability.

This is why, while I acknowledge the narrative implications you mentioned, I believe maintaining the current balance simply because it sounds fair is no longer enough.
The data shows us that the system, as designed today, is not working as intended, and that’s something we should be honest about if we want Astar to grow sustainably.

Looking forward to continuing this discussion.

[SimonB]

@you425

It feels like many people are leaning toward Plan B, but I think we need to look more closely at the root of the problem.

Up to now, the reason dApp Staking has been criticized ultimately comes down to poor token performance. In searching for the cause of that, dApp Staking has become the main target. As I’ve written before, since the supply–demand balance directly affects ASTR’s price performance, thinking naturally gravitates toward improving inflation, which is the primary source of supply.

If ASTR’s performance were strong, these kinds of arguments probably wouldn’t be happening at all (or at least they would be much quieter). Of course, in such a scenario, the listed dApps would likely have shown much better activity as well—but that’s another matter.

Thanks for sharing this perspective, You — I think it’s a very fair point to raise, and I agree that token price and supply–demand dynamics inevitably influence how these discussions emerge.

That said, I don’t fully agree that the core issues around dApp Staking are primarily driven by ASTR’s price performance.

In my view, the concerns we’re discussing today existed even during periods when ASTR’s price was significantly higher. The underlying problem — a lack of real, sustained value being produced by many dApps within the system — was already there. The difference is that when price action is positive, these issues tend to be more easily overlooked.

dApp Staking has been live for several years now, which gives us a meaningful amount of data. Looking back, it’s difficult to point to concrete, widely adopted, and successful dApps that have clearly emerged because of dApp Staking as a funding mechanism.

On the contrary, we’ve also seen cases where dApp Staking was used as a revenue source disconnected from real product delivery — sometimes even enabling teams with little accountability to extract rewards without contributing tangible value to the ecosystem, the ASTR token, or end users.

For this reason, I personally see ASTR’s price more as an amplifier of the discussion, rather than its root cause. Weak price performance makes structural inefficiencies impossible to ignore — but it doesn’t create them.

This is just my perspective, of course, but I believe that if dApp Staking had consistently produced strong, valuable, and sustainable dApps over the years, the narrative around it would look very different today, regardless of short-term token performance.

I’m glad this conversation is happening now, because it forces us to look beyond surface-level symptoms and ask whether the system itself is truly aligned with the outcomes we want for Astar in the long term.

[Marroz]

Good morning community,The discussion is moving forward, but so far I see very few comments truly aligned with my perspective. I have the impression that some objective data, already brought to the table multiple times, are being guiltily ignored or downplayed.I agree that, for one reason or another (and in my opinion none of these reasons are strong enough to justify the whole situation), no dApp has managed so far to carve out a leading role on Astar. I also agree that stricter selection mechanisms are needed, focused on quality over quantity. However, I believe this is only a marginal factor compared to the real structural problem.It pains me to repeat myself — I’ve been saying this for a year and a half — but let’s try to be honest with ourselves: every Astar holder already knows the answer to this very simple question.If tomorrow a top-tier protocol (pick whichever you want: Uniswap, Aave, Chainlink, EigenLayer… with billions in TVL) applied to dApp staking on Astar, how many of you would actually use it instead of keeping your tokens staked at a fixed 11% + 5-6% bonus, with zero risk?I believe very few.

The rewards a dApp could realistically offer would need to be at least 3× the 11% to convince most people to move… otherwise everyone comfortably stays in dApp staking.Outcome? That dApp might enter Tier 1 and receive funds from the program, but it would remain practically unused or only marginally utilized.

No serious protocol builds itself with the expectation of not being used. That’s pure fantasy.Let’s stay in reality: out of the 100+ dApps that have passed through dApp staking, how many have you actually used?

How many dApps to which you assigned your ASTR have you genuinely tried?

I’m willing to bet the ratio is embarrassing for pretty much all of us.The biggest enemy of Astar today is its own community (not through its own fault), the first one that doesn’t actually use the network.In my view, the only viable path is to work in parallel on two synchronized tracks:Significantly tighten dApp selection controls (quality > quantity)

Build (or closely support together with the Foundation) 1–2 flagship projects per major category that can become true category benchmarks

And at the same time

3. Reduce dApp staking rewards by at least 50%

→ those who want to stay “safe” can still earn a decent ~6%

→ those looking for higher returns finally have a real economic incentive to move to actual dApps However, it is essential to underline that at the moment the staking rewards MUST NOT be reduced at all without first having a valid alternative destination for one’s ASTR.

This would cause millions of locked ASTR to flee, as they remain in dApp staking precisely because of that safe and reliable percentage, which today remains the only real reason to hold ASTR. Mistakes are paid for, and the longer time goes on, the harder it is to fix them. Therefore, it is fundamental that, before any drastic decision, a concrete exit perspective is given to the average holder: they must not feel the ground collapse under their feet just because the rewards are halved from one day to the next.Only this way can we create a virtuous cycle: quality dApps + real economic incentive to use them = genuine network usage.

[Juminstock]

@SimonB

We’ve distributed rewards continuously to a large number of projects that, in many cases, have:

• delivered no meaningful utility to the network,
• created little or no value for the ASTR token,
• and provided limited real benefit to end users.

In practice, dApp Staking has often rewarded existence rather than impact.
And I believe this is exactly why this discussion exists today.

Yes, this is absolutely true, but it was that way by design and intent. The idea was that every dApp that became part of dApp Staking would do so because it deserved the rewards. Unfortunately, we ended up allowing low-quality or malicious dApps to enter the system.

@SimonB

We can certainly try to improve the current system by:

• raising entry barriers,
• simplifying mechanics (as in Plan A),
• tightening rules and criteria.

This is precisely what both you and the rest of the ACC members and I are working on. cc @Community_Council

@SimonB

From my perspective, if the goal is to foster high-quality, valuable, well-built dApps, then we may need to rethink the model more radically:

• allocating resources to fewer, carefully selected projects,
• supervising them step by step during development,
• having visibility into team composition and execution capacity,
• and funding builders based on concrete progress and delivered value.

We are aligned on this point, exactly as G’ mentioned in one of his previous messages.

@Gaius_sama

Concretely, we could keep the core idea of dApp Staking while removing much of the complexity introduced in V3. Instead of allowing an unlimited number of projects, we could cap participation to 10 or 20 slots, with inclusion decided by the Main Council, ACC, or through governance. Entry requirements would be significantly higher, with only leading projects in the ecosystem eligible to participate and benefit from dApp Staking.

@Marroz

If tomorrow a top-tier protocol (pick whichever you want: Uniswap, Aave, Chainlink, EigenLayer… with billions in TVL) applied to dApp staking on Astar, how many of you would actually use it instead of keeping your tokens staked at a fixed 11% + 5-6% bonus, with zero risk?I believe very few.

Yes, @Marroz, you are right, as you have pointed out on previous occasions. If dApps do not have a clear and stronger incentive for users to actually use them, we will continue running the “stake on any dApp and forget about it” model.

@Marroz

In my view, the only viable path is to work in parallel on two synchronized tracks:Significantly tighten dApp selection controls (quality > quantity)

Build (or closely support together with the Foundation) 1–2 flagship projects per major category that can become true category benchmarks

An interesting proposal that came up within this discussion was:

1. Significantly increase the selection and entry criteria for dApp Staking (the ACC is working on this).
2. Reduce the maximum number of participants in the program to 20, and introduce a waitlist for any number beyond that.
3. Provide more direct support to the projects that are part of the program.

@Marroz

3. Reduce dApp staking rewards by at least 50%

→ those who want to stay “safe” can still earn a decent ~6%

→ those looking for higher returns finally have a real economic incentive to move to actual dApps However, it is essential to underline that at the moment the staking rewards MUST NOT be reduced at all without first having a valid alternative destination for one’s ASTR.

This is something that could be considered, but it needs to be backed by solid reasoning. What is your rationale behind proposing this?

[Marroz]

@Juminstock

@You425

I explain Astar’s problem in a clear and logical way, starting from the basic premise.1. Astar has always been perceived and structured as a network for builders, not for retail

From the outside and in its very model, Astar is a platform for those who develop dApps: dApp staking finances builders with rewards from inflation, allowing them to build without having to chase external funds or VCs. It is an ecosystem that should reward those who create real value, not those who hold tokens out of inertia. However, the mechanism creates a serious structural conflict: passive rewards are far too dominant and comfortable. ASTR tokens end up locked in dApp staking for that safe yield, with no need to do anything. People “stake and forget”. Direct consequences: The community remains passive: zero real transactions, dApps deserted, very little curiosity, very few new users entering to try real things.

Builders receive funding yes, but they have no real clientele. Their dApps do not grow organically, do not generate network fees, depend only on artificial rewards.

Without an active user base willing to use/test/generate value, no serious builder sees Astar as an ideal place: funded economically, but without the “clientele” that makes the project and the ecosystem take off.

2. The situation is now even worse

With ACS we shifted (or “gave away”) a significant portion of liquidity and TVL to Soneium to grow the Collective/Superchain ecosystem. Many ASTR were bridged there for extra rewards. Good for the long term, but on Astar L1 it left us with less mobile liquidity, less organic activity, and even greater dependence on dominant passive staking. Without an active user base here, it is extremely hard to unlock things.3. Inflation and the role of passive stakeholders

As You425 showed with the table on reward allocations (Current vs Max/Adjust), dApps and their rewards are not the only culprits of persistent inflation. The majority of emissions actually go to passive stakers (base, loyalty bonus, and adjustable variable), not to builders. This confirms that dominant passive rewards fuel useless inflation: new ASTR are “printed” to pay holders who stay put there, without generating real usage or network growth. If unstaking increases (due to lower rewards or other reasons), the risk is sell pressure without compensation from organic activity.4. The way out: addressing the conflict at its root

There are two clear and distinct alternatives: First option (the only realistic one and aligned with Astar’s DNA): stop competing with builders on passive yield, but actively and in parallel help them develop – with close support, direct oversight (milestones, supervision, funding tied to concrete progress and real usage), and risk limitation for the network.

Reducing passive rewards (making them modest but above all not dominant) unlocks tokens: people must move them to seek extra yield, using real dApps (DeFi, gaming, transactions, etc.).

This way you offer builders not only economic help, but also a clientele willing to use them, grow them, generate organic activity, curiosity, and new users.

The network becomes attractive to builders precisely because it has a living ecosystem and active users – not just for the funds from the program.

This must be done in parallel and accelerated: first strengthen selection (few strong projects), support them with direct funds and real usage obligations, rebuild appeal on L1 (Tokenomics 3.0 with lower inflation, Burndrop, usability boost), incentives to bring liquidity back from Soneium. Then gradual reduction of rewards, tied to concrete milestones of activity/organic TVL. I fully agree with Juminstock’s proposal: limit to max 20 dApps in the program (with strict criteria), the rest on a waiting list, more direct support to selected projects. The ACC is already doing an excellent job on severity and entry barriers – it’s the right direction for quality > quantity.

Second option (much more complicated and with results right in front of us): find another way to give real value/utility to the ASTR token and incentivize people to use it actively.

Examples: mechanisms like Polkadot parachains (DOT locked for slots, but parachains struggle to attract real adoption and organic TVL despite funding) or Cosmos Hub (high staking, but DeFi/usage remains limited, passive community and inflation dependence).

We have seen the results: these chains have enormous difficulty creating living ecosystems with daily usage. It is already difficult to have 1-2 serious dApps per category on Astar; thinking of more complex alternative models is risky and likely to fail without solid foundations.

So the first path is the only viable one: stop competing with builders on passive yield, but actively help them with oversight and risk limitation, unlock the user base, give them real clientele. Otherwise we remain a chain that funds projects but does not make them take off, with a lazy community and low TVL. This shift creates a living ecosystem: more curiosity, new users, real activity, token with value from usage not from inflation. It is the only way to move from “staking network” to “platform used by builders with real clientele”."

[Gaius_sama]

GM

Overall, I am generally aligned with this direction.

From the foundation side, there are a few points we will focus on carefully, while remaining mindful that any parameter change or decision impacts multiple parts of the ecosystem and must be balanced accordingly.

Significantly tighten dApp selection controls (quality > quantity)

Build (or closely support together with the Foundation) 1–2 flagship projects per major category that can become true category benchmarks

3. Reduce dApp staking rewards by at least 50%

---

The biggest enemy of Astar today is its own community (not through its own fault), the first one that doesn’t actually use the network.In my view, the only viable path is to work in parallel on two synchronized tracks:Significantly tighten dApp selection controls (quality > quantity)

Regarding user behavior, I do not expect dormant Astar users or existing stakers to significantly change how they engage with the network simply because new dApps or projects are deployed. This is not unique to Astar. Across the broader industry, we are currently seeing more users leaving due to market conditions and a large number of projects shutting down, rather than a net influx of new users entering crypto.

As a result, if we want to grow sustainably, we need to design products and initiatives that target new users and new markets. These markets may sit outside of traditional crypto, while still leveraging the financial, decentralized, and secure infrastructure that this industry has built. New users do not necessarily need to be onchain users. What matters is that they use Astar technology and, where relevant, the ASTR token, ideally without being exposed to the friction typically associated with blockchain usage. This is an important topic, but it is a separate discussion.

For now, our priority is to address the current issues around dApp Staking and tokenomics. The objective is to stabilize and strengthen these core mechanisms so that Astar can move into its next phase with solid foundations, without having to repeatedly revisit and patch fundamental economic structures.

---

Gaius_sama
Astar Foundation

[Marroz]

@Gaius_sama
I’m very pleased to read these words – I’m relieved that you too have identified the same inconsistencies I’ve been seeing for a long time.You’re absolutely right: the current market environment certainly doesn’t help, but that’s exactly why acting now on tokenomics and dApp staking is an essential step toward true long-term sustainability. When things turn around again, Astar needs to be ready with solid foundations.I fully understand that there’s no magic wand: lowering passive rewards won’t magically make all inactive stakers start using the network. It will be tough, the transition will have friction, and not everyone will change habits overnight.But I firmly believe this is the right direction for two main reasons: Loyalty to Astar’s DNA – we are and must remain a network for builders. Reducing dominant passive rewards means stopping competing with them on safe yield and returning to giving them real space + active clientele.

The community deserves trust – it has already shown with ACS that it knows how to respond when there’s a clear and concrete incentive: bridging, liquidity provision, millions of interactions. If we create valid alternatives and reduce gradually while tying everything to real milestones, many will move.

I fully agree that the priority is stabilizing the foundations (dApp staking revamp, inflation control, strict selection with max 20 slots, direct support for top projects). The ACC and the Foundation are already doing an excellent job on quality > quantity – let’s keep going in this direction, with boldness but balance.On the off-topic of new users / non-crypto markets, I won’t comment for now: I’m looking forward to the dedicated discussion.Thanks for the alignment and for the direct exchange – it’s encouraging. Let’s proceed decisively on the foundations.

[you425]

@SimonB

That said, I don’t fully agree that the core issues around dApp Staking are primarily driven by ASTR’s price performance.

Yes, I think people like you—who understand Astar well—tend to see it that way. What I want is for those who are calling to cut dApp rewards without sufficient understanding to re-examine the fundamental issues that I see.

I believe we can all agree on one point: dApp Staking has not produced the results that were originally expected, and it has failed to establish a truly meaningful reward structure. For that reason, there would be very few people who outright oppose changing how developer rewards (or grants) are distributed.
If someone understands Astar, understands their own motivations, and then expresses an opinion, there is no problem at all. However, I sense a strong bias in the current arguments, which is why I continue to raise these points.

I also agree that reducing dApp Staking yields will lead to some participants leaving. To be absolutely clear and avoid any misunderstanding: I am not proposing to reduce staker rewards themselves. As I mentioned earlier, what concerns me most is the bias in the discussion.

In my proposal, the idea is to change the structure of staker rewards—reducing the base reward and increasing the bonus portion, while shifting the eligibility for bonuses from “accounts that simply voted and stayed during the voting period” to accounts that actually participated in governance. The total amount of rewards does not decrease, but rewards are reduced for those who “stake and forget” and do not actively participate in Astar’s operation.

In any case, staking rewards will inevitably decrease under Tokenomics 3.0 (technically, overall inflation decreases), and as has been pointed out in the Forum before, there is also the view that staking returns being more stable and higher than DeFi yields is itself a problem for the ecosystem as a whole.

No matter what, rewards (inflation) declining over time is unavoidable.
That is precisely why I think we need to take this inevitability into account and think carefully about the path forward.

[Marroz]

What exactly do you mean by modifying the stakers’ reward quota?

From what I understand, you don’t want to lower it overall, but rather reduce the fixed part and make up the gap with a bonus part.

But I’m wondering: how could that bonus be satisfied to get the full rewards like we have now?

The only way I can think of to determine if a user is actually participating is by voting in governance… great suggestion, I’d use it too.

Still, it feels a bit excessive to allocate so much to the bonus: let’s say, for example, you get half the rewards as base, and the other half only if you participate in governance.

To me it still seems too unbalanced, and above all, it wouldn’t really reduce that inflation factor.

In the end, though, the problem remains: too many ASTR would still be distributed to people doing absolutely nothing. Is voting once in a while really such a big effort? And the dApps would still be left without a real pool of users ready to actually use them.

I still don’t fully get what you’re trying to

say.

[you425]

@Marroz

From what I understand, you don’t want to lower it overall, but rather reduce the fixed part and make up the gap with a bonus part.

Yes, that’s correct. Previously, votes cast during the voting period received bonuses, but we proposed allocating these to governance. For details, please refer to the previous post (4-B).

Astar Foundation Forward: Tokenomics & dApp Staking discussion

@Juminstock Thank you! Now, this is long, but I’ll repost what I wrote in another thread. It’s mostly unchanged, but I’ve combined two posts and edited them slightly. This proposal points in a slightly different direction than the one @Juminstock made. 1. Fundamental question: the sustainability of dApp Staking (developer rewards) This is the most fundamental point, but we have to ask: “Do we even need dApp Staking?” Originally, one of Astar’s differentiators was that it natively supported…

Also, please read the next post regarding adjustments to the inflation rate.

Astar Foundation Forward: Tokenomics & dApp Staking discussion

Although this thread is primarily about dApp Staking and Tokenomics, Tokenomics itself has hardly been discussed so far, so I’d like to make a proposal on that as well. Under Tokenomics 3.0, a maximum supply is planned, and the amount of ASTR issued per block is expected to decrease over time. What if we add one additional “coefficient” on top of this? At a fundamental level, the price of an asset fluctuates based on the balance between supply and demand. In simple terms, the reason ASTR’s pr…

[Amil_Gaoul]

Dear Astar Community, Foundation, and fellow Builders,

I want to start by acknowledging the high-value updates from @Juminstock Carlos reply (#43) and @Gaius_sama reply (#51). It is refreshing to see the Foundation and Core Team inviting deeper builder participation with a clear focus: stabilizing core mechanisms.

I fully align with the sentiment that we need to stop reinventing the wheel every few months. As Gaius mentioned, user behavior (stake-and-forget) is difficult to change; therefore, the protocol must be robust enough to handle that reality while still driving growth.

Here is my perspective as a builder who interacts with these mechanics daily, and my proposal to bridge the gap between Plan A (Revamp) and the need for rigorous quality control.

1. The Verdict: Plan B is a Dead End; Evolve Plan A
   I stand firmly with Carlos and the builders’ consensus: We must reject Plan B.

Eliminating dApp Staking to replace it with simple staking and grants would be a strategic error. It strips Astar of its primary Unique Value Proposition (Build2Earn). Grants are finite and political; algorithmic yield is continuous and permissionless. If we kill Build2Earn, we kill the primary incentive for independent devs to deploy on Astar over an L2 giant.

However, the current implementation (v3) is too complex and prone to gaming. We need Plan A evolved: Radical Simplicity + Aggressive Curation.

2. The Solution: Hybrid Incentives & The “Monitoring Category”
   Gaius suggested a cap of 15-20 dApps to concentrate rewards. While I agree we must cut freeriders (zombie dApps sucking rewards with zero updates), a rigid hard cap creates an oligopoly that blocks future innovation.

Instead, I propose a Data-Driven Tiered System that removes the need for constant manual voting wars:

A. Hybrid Reward Calculation (The “Performance Multiplier”)
We stop relying solely on “User Staking” (which creates popularity contests). The formula should be:

• Base Reward: Derived from Staked Amount (User signaling).
• Performance Multiplier: Automatic on-chain boosts based on TVL, UAW (Unique Active Wallets), and Gas consumption.
  Why? A dApp might have huge stake but zero users. The multiplier forces them to actually be used to unlock full rewards.

B. The Innovation: A “Monitoring Category” (Instead of a Hard Cap)
We cannot close the door on new builders. Inspired by the “Innovation Zones” of major CEXs, we should introduce a Monitoring Category for new entrants:

• Strict Entry: Requires working MVP, Audit/Security check, and a clear Roadmap. No “whitepaper only” projects.
• Probationary Period: 3 to 6 months.
• Reduced Rewards: Entrants receive 50-70% of standard rewards. This is enough to fund dev costs but too low to attract scammers/freeriders.
• Graduation: If the dApp hits specific on-chain metrics (Growth, Retention, Volume) during the monitoring period, they “graduate” to the full dApp Staking tier. If they fail to deliver, they are delisted automatically.

This solves the freerider problem without killing the ecosystem’s ability to welcome the next big thing.

3. Builder Perspective: The SoneVibe Approach
   At SoneVibe, we don’t just ask for rewards; we build infrastructure that utilizes the chain.

• We recognized a gap in user experience, so we integrated Astar Degens listings directly into our UI for seamless access.
• We saw friction in bridging, so we built native Wrap/Unwrap functions for ASTR to reduce reliance on external bridges and lower fees.
• We are driving DeFi utility (Swap, Lending/Borrowing markets) to capture TVL for the network.

This is the type of behavior dApp Staking should incentivize: Integration, Utility, and Retention. A purely grant-based system (Plan B) would not sustain this level of continuous operational development.

4. Next Steps
   The ACC cleanup mentioned by Carlos is the right immediate step. However, for the long-term code changes, we need to ensure the metrics are right.

I invite the Foundation and the ACC to form a focused Working Group with active builders to refine the parameters of this “Monitoring Category” and the Hybrid Metrics. We have the data, we have the passion, and we are ready to help build a sustainable foundation that rewards genuine impact.

Let’s stabilize, simplify, and build.

Amil Gaoul
Founder, SoneVibe
Building the future of DeFi on Astar & Soneium

[you425]

@Amil_Gaoul

Performance Multiplier: Automatic on-chain boosts based on TVL, UAW (Unique Active Wallets), and Gas consumption.
Why? A dApp might have huge stake but zero users. The multiplier forces them to actually be used to unlock full rewards.

On this point, discussions have actually been happening for quite some time. However, it is inherently difficult to evaluate projects fairly based solely on on-chain metrics. The reason is that projects come in many different forms, and certain categories may not be able to receive meaningful on-chain evaluation at all.
For example, among the projects currently listed, infrastructure-focused projects would, across the board, be very hard to evaluate using such metrics. Because of this issue, this idea has come up repeatedly in the past but has never ultimately been implemented.

If this type of evaluation method were to be introduced, we would either need to adjust the calculation logic by project category, or both developers and stakers would need to accept the trade-offs. Either choice makes it difficult to guarantee fairness. In that sense, a model that evaluates projects purely based on staking volume can be considered more fair.
That said, if Astar were to clearly shift its policy toward “prioritizing projects that lead to on-chain activity,” then adopting such an evaluation method would not necessarily be wrong.

In that case, however, it wouldn’t be enough to simply change the v2-style evaluation method. We would also need to think carefully about the formulas and parameters themselves—such as setting distribution caps or adjusting simple share-based distribution mechanisms.

While I agree that tightening the listing criteria for dApp Staking makes sense, it would likely narrow the pool of participating projects. Under a v2-style system, this would result in an extremely large amount of ASTR being distributed to a smaller set of projects. As a result, changing only the evaluation method could lead to a very skewed reward distribution.

@Amil_Gaoul

B. The Innovation: A “Monitoring Category” (Instead of a Hard Cap)
We cannot close the door on new builders. Inspired by the “Innovation Zones” of major CEXs, we should introduce a Monitoring Category for new entrants:

This would effectively correspond to what is currently UCG.

@Amil_Gaoul

Grants are finite and political; algorithmic yield is continuous and permissionless. If we kill Build2Earn, we kill the primary incentive for independent devs to deploy on Astar over an L2 giant.

I think there may be some misunderstanding here.
Even under Plan B, the allocation that originally went to developer rewards still exists, and it can be used as a funding source for grants. In that sense, sustainability does not fundamentally change.

Also, if grants under Plan B are labeled as “political,” then the current dApp Staking listings and UCG led by ACC would also have to be considered “political.” I don’t think the essence of the situation is very different.
If one wants to avoid that entirely, the only option would be to make dApp Staking a fully permissionless system—but in reality, that’s not something anyone actually wants.

[Amil_Gaoul]

@you425 Thank you for the detailed and high quality breakdown. You have defined the exact friction points involved in transitioning from a “User Sentiment” model to a “Performance” model.

I would like to address your three core concerns: Metric Fairness (Infrastructure Paradox), Reward Skew/Distribution, and the Grants vs. Yield distinction with a technical perspective on how we can solve them without abandoning the Build2Earn UVP (unique value proposition).

1. The “Fairness” Paradox: On-Chain Metrics vs. Infrastructure

“Infrastructure-focused projects would, across the board, be very hard to evaluate using such metrics [TVL/UAW].”

You are absolutely correct: One formula cannot rule them all. Measuring an RPC provider or an Explorer by “TVL” is impossible. However, letting the difficulty of measuring Infrastructure hold back the incentives for DeFi and Gaming (which drive gas and burn) is a net negative for the ecosystem.

The Solution: Category Specific Weighting
We do not need a single “Multiplier.” We need Category/Based Logic encoded in the dApp Staking pallet.

If Astar’s strategic goal is to increase on-chain activity (as you mentioned), then the protocol must offer higher potential APY to protocols that generate that activity, while offering stable base rewards to critical infrastructure. We can architect this trade off transparency.

2. Solving the Skewed Distribution (The “Oligopoly” Risk)

“Changing only the evaluation method could lead to a very skewed reward distribution [if we narrow the pool].”

This is a critical observation. If we reduce the pool to 20 dApps but keep the block emission fixed, the remaining dApps receive massive over payment, leading to immediate sell pressure.
The Solution: Dynamic Saturation Curves (Soft Caps)
We should not use a linear distribution. We should implement a Logistic Saturation Curve (similar to Polkadot’s NPoS validator rewards logic but applied to dApps).

• The Cap: Each dApp slot should have a “Dynamic Soft Cap.” Once a dApp captures, say, 10% of the total network stake, their marginal reward multiplier decreases.
• The Result: This forces stakers to decentralized their stake to other performing dApps to maintain yield, naturally preventing the “Winner Takes All” scenario you described.
• Unclaimed Rewards: If the active dApps don’t hit the metrics to unlock the full pool, the remainder shouldn’t be distributed to them, it should be burned or sent to the Treasury. This aligns tokenomics with actual network value creation.

3. “Monitoring Category” vs. UCG & The Psychology of Building

“This would effectively correspond to what is currently UCG… Even under Plan B… sustainability does not fundamentally change.”

I must respectfully disagree on the “builder psychology” aspect here. Structurally, they are different:

• UCG (Grants): Discrete, lump-sum, milestone based. It feels like “Contract Work.” It creates friction and requires constant re application.
• Monitoring Tier (Staking): Continuous, streaming, operational flow. It feels like a “Business.”
  For a builder, Cash Flow > Lump Sum.
  The “Monitoring Category” provides a predictable (albeit reduced) operational baseline (OpEx) that allows a team to focus on shipping code rather than writing grant proposals every 3 months. It bridges the gap between “Hello World” and “Top Tier dApp” automatically.

4. The “Political” Spectrum: Market vs. Committee

“If grants under Plan B are labeled as ‘political,’ then the current dApp Staking listings… would also have to be considered ‘political.’… The only option would be… fully permissionless.”

You touch on a deep governance truth here. Yes, the entry (Whitelisting/ACC) is political in both systems. But the execution is where they diverge:

• Plan B (Grants): Political at Entry + Political at Distribution (Committee decides how much you get).
• Plan A (Staking): Political at Entry + Market Driven at Distribution.
  Once a dApp is whitelisted in dApp Staking, the Community and the Code decide if I earn $100 or $10,000 based on my performance and their stake.
  In a Grant system, a committee decides my value.
  I prefer the Market deciding my value. That is the essence of Web3.
  Conclusion: Let’s Engineer, Not Abandon
  You are right that we cannot simply “tweak v2” and hope for the best. The math requires:
• Category based logic (protecting Infra while boosting DeFi).
• Saturation Curves (preventing reward concentration).
• Burn mechanics for unearned rewards (preventing inflation dump).
  We have the opportunity to build the most sophisticated builder incentive model in crypto. Let’s not revert to a standard Grant model just because the math is hard. We can solve the math. Best,
  Amil Gaoul
  Founder, SoneVibe

Astar & Soneium.

Dapp: VIBE Finance | The Future of Lending

X : https://x.com/Sonevibe

Telegram: Telegram: View @SoneVibe

[you425]

@Amil_Gaoul

1. The “Fairness” Paradox: On-Chain Metrics vs. Infrastructure

Yes, I agree. By introducing coefficients like this, it’s possible to make a certain level of adjustment. The remaining issue then becomes how to evaluate the legitimacy of those coefficients. There will probably never be a coefficient that everyone can fully agree on.

@Amil_Gaoul

UCG (Grants): Discrete, lump-sum, milestone based. It feels like “Contract Work.” It creates friction and requires constant re application.

I think there may be some misunderstanding about UCG. UCG is developer support delivered through dApp Staking, so it is not a matter of simply handing out grants directly (direct grants are a separate program from UCG).
The major difference from your “Monitoring Category” proposal is that ACC supports UCG recipients by staking a certain amount of ASTR on their behalf, effectively providing developer rewards as a substitute for grants.

With dApp Staking, projects cannot receive rewards unless they attract stake. However, projects that would fall into a “Monitoring Category” would likely struggle to attract attention. If the purpose of placing them in that category is support, then it may make sense for it to operate in a way similar to UCG.
Of course, it would be better not to target all projects in the monitoring category, but rather to ensure that projects designated for UCG also fall under the monitoring category.

Under Plan B, since the staking destination would be fixed, UCG could no longer be applied in its current form and would have to shift to direct grants. However, if the ability to choose staking destinations is preserved, UCG can continue to exist (though it could also be discontinued if desired).

@Amil_Gaoul

In a Grant system, a committee decides my value.
I prefer the Market deciding my value. That is the essence of Web3.

Yes, I agree—that is the ideal in principle.
The problem, however, lies in whether stakers are actually making serious, thoughtful decisions when choosing which projects to stake on. This has been pointed out repeatedly in the past, and it remains a fundamental structural issue. It is primarily a problem on the staker side, but it ultimately becomes a problem for developers as well.

At the moment, there is no clear solution to this. The move to v3 was originally intended to address it by introducing periodic staking resets, forcing stakers to reconsider their choices. But it’s unclear whether this is really achieving the intended effect.
On the other hand, reverting to a v2-style model would not solve the “first-mover advantage” problem either.

Unless the system enforces behavior mechanically, users need to consciously recognize that they are “participating in governance,” but fostering that mindset has proven extremely difficult. As a result, some people feel that v3 has simply become “more complex and more cumbersome” rather than more effective.

[Juminstock]

Thank you to everyone for participation in this conversation!

After two weeks of active discussion, I want to share a summary of the key insights gathered from this thread. Your participation has been invaluable in shaping how we think about dApp Staking’s future.

Where We Seem to Agree

The community has expressed a clear concern: the current system rewards existence rather than impact. We’ve distributed rewards to projects that, in many cases, haven’t delivered meaningful utility to the network. This shared understanding is precisely why this discussion matters.

There’s also broad recognition that v3’s complexity (tiers, bonus rewards, voting periods, stake resets) hasn’t solved the freerider problem or meaningfully changed user behavior. Most stakers still operate in “stake and forget” mode regardless of the mechanisms in place.

Proposals Discussed

Throughout this thread, several ideas have emerged:

Separation of Concerns Model: Some community members proposed decoupling user staking from developer funding entirely, with developers competing for reward pools based on demonstrable metrics rather than stake attraction.

Category-Based Evaluation: A framework for evaluating different project types with category-specific metrics (infrastructure vs. DeFi vs. consumer apps) and dynamic saturation curves to prevent reward concentration.

Quality Over Quantity: Strong support for drastically reducing the participant pool, raising entry barriers, and providing more direct support to fewer, carefully selected projects.

What We Should Consider

As we continue shaping this direction, I think we need to have in mind a few key factors:

Implementation Complexity: Some of the more disruptive changes discussed would require significant engineering resources. We should weigh the value of each proposal against what’s realistically achievable.

Simplification vs. New Mechanisms: Rather than adding evaluation layers, should we focus on removing friction points that haven’t achieved their intended behavioral changes?

Participation Cap: Limiting dApp Staking to approximately 15-20 slots has been mentioned repeatedly. This could address quality-over-quantity concerns while strengthening the value of each slot.

Reward Predictability: Developers need to plan around expected income. How do we balance flexibility with the stability builders need?

Open Questions for the Collective

I’d like to hear more from you on these points:

1. If we move toward fewer slots with higher standards, what criteria should define eligibility?
2. How do we handle the transition for projects currently in the program?
3. Should we prioritize simplification (removing complexity) or restructuring (new evaluation models)?

Nothing is decided yet. Your input here directly shapes the direction we take. I’ll continue gathering feedback and working with the ACC and leadership to refine a proposal that reflects what this community truly needs.

Keep the ideas coming.

[you425]

Thank you for the summary.

It might be useful to first run a vote to decide the broader direction. Even if it is not meant to make a final decision, it could still serve as a temperature check for the community.

1. Maintain staking per project (continue / improve dApp Staking)
2. Fix the staking destination to a single place (pivot to direct grants, effectively ending dApp Staking)

I believe the topics we need to discuss will differ significantly depending on whether we choose direction 1 or 2.
This is not about deciding which option is “correct,” but about clarifying what Astar should prioritize.

---

Direction 1

→ Maintain Astar’s original policy

Main discussion points:

• Choosing between v2 or v3
• Common to both: redefining listing / eligibility criteria
• v3: parameter tuning such as tiers and slots, and whether to keep the period-based system or pursue simplicity
• v2: managing reward curves through category-based functions and caps

Considering engineering constraints, it may make sense to first adjust parameters within the v3 framework and then discuss a potential move to v2. There is no need to change everything at once. Parameter adjustments in v3 should be relatively easy from an engineering perspective.

Choosing v2 would make the system simpler for stakers. Alternatively, even without reverting to v2, we could simplify v3 by removing periods and bonuses (though allocation design would still require careful discussion).

---

Direction 2

→ Pivot Astar’s policy toward direct grants

Main discussion points:

• Direct grants are not currently the primary mechanism, so they would need to be redefined and clearly documented
• In this case, v3 periods would be completely unnecessary and should likely be removed
• Whether to introduce governance-based incentive mechanisms

In this scenario, Plan B would become the core approach, and from an engineering perspective it should be relatively straightforward—similar in complexity to v3 parameter adjustments under Direction 1. However, since periods would no longer be needed, that part would require modification.

Ideas like my governance reward proposal would represent a much larger change and are an extension of Plan B. Even if such proposals were approved, it would make sense to proceed with Plan B first.

---

That said, I would also like to share my thoughts on Carlos’s questions.

@Juminstock

If we move toward fewer slots with higher standards, what criteria should define eligibility?

This is probably the most difficult issue. One possible approach is to define clear, category-specific KPIs, score them, and require projects to exceed a certain threshold.

In addition, very few projects currently submit reports in practice, so this process should be made more rigorous. As I previously suggested, reports could be submitted via the Portal, combined with on-chain verification. If reports are not submitted for a certain period, penalties could be applied to rewards, and eventually projects could be automatically delisted. This would raise engineering challenges, but it may be worth considering.

Stricter measures such as mandatory KYB/KYC or audit report submissions are also possible, but each has its own drawbacks, so personally I am not very enthusiastic about going that far.

@Juminstock

How do we handle the transition for projects currently in the program?

One option would be to delist all projects once and ask them to reapply.
Alternatively, projects with clearly active usage could be exempted, but if listing criteria are redefined, they should still be evaluated against the new standards.

@Juminstock

Should we prioritize simplification (removing complexity) or restructuring (new evaluation models)?

In my view, as mentioned above, the priority depends on which direction we choose. The appropriate approach changes depending on the objective.

Simplification and restructuring are not goals in themselves—they are tools. We should first decide the objective (the direction), and then choose the appropriate means.

[Matt]

Good breakdown from @you425 framing the fork in the road between keeping per-project staking vs pivoting to grants. The missing piece for me is how either path aligns with what Astar ultimately wants to incentivize: usage, TVL, dev activity, retention, or ecosystem breadth. Without a clear objective function, parameter debates (v2/v3, tiers, periods, slots, delist criteria) risk becoming technical exercises.

Might be worth asking: what is the primary metric the tokenomics should optimize for going forward, and is that better served by a market-driven mechanism (staking) or a governance-driven one (grants)?