✳️ dApp Staking Reset Mechanism

1

Proposal for dApp Staking Reset Mechanism

Rather than relying on the current reset system, which has been a failure, I propose a manual reset based on project activity and transparency. With the establishment of the new council, we now have a structured system in place to ensure real accountability and progress.

Proposal Details:

• Projects should be required to provide regular updates on what they are building, including progress reports and new developments.

• Projects should contribute to the ecosystem with live dApps, helping the ecosystem grow and directly benefiting ASTR.

• If a project is inactive or fails to provide updates on the forum for a set period (e.g., 3-6 months), it should be automatically reset or delist it from the dApp staking.

• This ensures that only active, transparent, and contributing projects remain in the ecosystem, while removing those that fail to engage or evolve.

This approach is a more fair and transparent way to ensure dApp staking rewards are allocated to projects that are actually contributing to the growth and sustainability of the ecosystem!

2 Likes
2

Could you elaborate more on this regarding it’s being a failure?

I also see a part of this as a success because this feature was implemented because we saw in v1 and v2 that the majority of the stakers, stake and forgot. We also saw that some projects that did limited but still enough, got the most amount of ASTR.

By having a reset system (as we have now) with a clear timeline when it happens, we wanted to encourage projects to do marketing to get the stakers while giving the bonus rewards. In some amount, it worked but you still will have the stakers that just stake every x months and forget. They don’t care on who, they just want the yield.

With a manual reset we will not be able to do the following:

  • An organized marketing effort by all projects at the same time to get the stakers
  • Bonus period to encourage users to start staking (including new users on Astar)

I do expect our Community Council to be active on this thread to define together with the community to see if this idea would be beneficial.

@Gaius_sama @jay @pitcoin777 @tksarah @Mouthmouth68 @AstarHood

1 Like
3

Maybe he hasn’t been able to find positive success stories after 2 years of funds granted. What would you call it if not failure?

For example, one of the marketplaces that was supposed to manage the traction of the nfts market, asked to be delisted due to lack of projects in this sense, yet reading the proposals it seems to me that I see many that base their function on this. Or maybe not?
Just an example.

So maybe it’s time for this not to be true anymore? Put the stakers in the game, make them participate by guaranteeing only a base yield, but which will be higher on projects that move well. See how they will rush to vote and take an interest. There will just have to be a fair compromise between guaranteed support for dapps for periods defined by milestones, and the rise or fall of this support depending on their movements.

Ask those who suffer the system, take notes and you will understand how to act. Until you do it every so many months there will be a situation like this.

4

We are discussing the reset feature.
It would be great if you could reply to my assessment of this feature and my comments :pray:

6

I would like to stop this harassment of @SFY_Labs and @Zorounashi toward me and Astar Foundation because they are the same team but most of all, the same account. I already silenced Zorounashi, but I will do the same with the SFY_Labs account.

They don’t bring benefit to any discussions with real solutions but only prefer to talk bad and point fingers. To make this forum more encouraging to join. I decided to silence SFY_Labs for one month based on the rules of engagement and suspend Zorounashi as being a duplicated account operated by SFY_Labs: Astar Collective - Rules of Engagement

image
image1013×579 45.9 KB

Edit: let’s move forward with the topic :pray:
Sorry for the messages above @WakeUp, if you prefer them to be deleted (including my latest) let me know.

5 Likes
7

Thank you for the proposal! There are several points we can reflect on to seek the best solution for dApp staking, and it would be great to involve more people so we can collectively find an efficient approach. I really liked your idea, and I would love to hear more about it so we can work together to reach an optimal solution.

I’m going to share a few thoughts.

I remember @Sota envisioning dApp staking as a kind of “app store,” with hundreds of dApps listed, and the community/users would choose the winners (the dApps to which they would delegate their tokens)… If a dApp contributed significantly to the ecosystem, it would, in theory, receive more support from the community. But support is not always tied to development; it can be linked to receiving benefits.

In an ideal world, this could be possible—encouraging the concept of “let the builders build.” However, we need to analyze the perspective of dApps that may simply lure stakers by offering extra rewards to capture the largest share of staking.

The current dApp staking model is designed to mitigate stakers (who are many) that simply stake and collect rewards without caring much about what the dApps are building, as long as they receive their earnings—ultimately, users are more focused on financial returns rather than whether DEX X will have liquidity or whether NFT Marketplace Y will gain traction.

If we analyze the graph provided by the tool created by Takeshi, we see that:

  • 42% of ASTR staked go to the top 5 dApps;
  • 34.5% go to the community pool and Astar core contributors, totaling 76.5% of the rewards…
  • leaving only 23.5% of the ASTR staked among 83 listed dApps.

Screen Shot 2025-01-04 at 20.51.21
Screen Shot 2025-01-04 at 20.51.21675×385 52.8 KB

https://agent.sun-t-sarah.work/

We can conclude that only a few dApps “benefit” from dApp staking, while the majority of listed dApps receive little to no financial incentive to keep developing. This is a point worth discussing and analyzing for solutions.

Scenario 1:

If we make dApp staking too restrictive, I fear there would be little motivation for dApps to be listed, as almost all established dApps in other ecosystems request grants (I affirm this based on my experience as part of Astar SpaceLabs, a business development team, where it was very difficult to attract projects by offering only dApp staking as a benefit—most asked for a high amount in $). On the other hand, emerging dApps lack sufficient funds to support their operations, including server costs, team salaries, audits, marketing, and building an active community.

Scenario 2:

Another point already defined since the concept of dApp staking is that dApps can spend their rewards however they wish—distributing them to the community, using them for development, or any other purpose, including none at all. It would be necessary to REDESIGN this model to ensure that funds are used only for development (and I believe this would be difficult to control since only on-chain data would not be sufficient proof).

Scenario 3:

Consider a hypothetical case of a DEX with sufficient liquidity that has already delivered its final product and does not plan to implement new features but is still used by users and has stakers supporting it. Should it be delisted? It’s a useful product for users—people are using it—but it won’t deliver any further updates.

Scenario 4:

With a very permissive dApp staking model, most dApps could become obsolete, leaving only a few active and preferred by the community (which I believe is the current situation). Even with a permissive approach, the reward distribution is very unequal, making it impossible for projects to develop from scratch (forcing them to rely on UCG funding).

Another point is defining what community support really means. Does one whale staking a huge bag outweigh 1,000 small stakers? On one hand, we have “skin in the game,” and on the other, we have a “community of users.”

3 Likes
8

In my opinion, as Maarten mentioned, it has achieved a certain level of success (even if it wasn’t perfect for both Stakers and Project sides).

As Sota wrote in another thread, it is essential to uphold the essence of Build2Earn, and I believe that the dApp side needs to provide a minimum amount of information and progress reports to continue receiving rewards. These should consider both quantitative and qualitative impacts on the Astar ecosystem. Especially regarding quantitative metrics, there is room for discussion on what indicators should be used. While it may be beneficial to provide a system that can measure these metrics, it might take time to create an interface that is convenient for the projects, so it may not be available immediately.

I would like to hear some concrete ideas and opinions on this matter.

Considering the scenario of @pitcoin777 , although it is difficult to have a uniform evaluation standard across all dApps, I think it might be beneficial to categorize them into groups such as DeFi, NFT Marketplace, Game, Tools, etc., and establish evaluation points for each category to measure their contribution to the ecosystem.

1 Like
9

Thank you for providing the data. All discussions should be based on the on-chain data, so this is helpful. As Pitcoin mentioned, the projects are long-tail meaning top 7 projects own more than 75%. We should focus on evaluating these top projects first. And the decision should be made based on the onchain data and relevant contributions.

2 Likes
10

We’re all here because we care about Astar’s success and its future. It’s clear that everyone has strong feelings about what’s happened in the past, but dwelling on it won’t help us move forward. Let’s leave the past where it belongs and focus on building a stronger, more collaborative community.

Silencing voices, regardless of the reasons, risks dividing us further when what we really need is unity and open dialogue. Constructive criticism and differing opinions can drive meaningful improvements when handled respectfully. Instead of shutting down discussions, let’s encourage solutions and ideas that align with the betterment of Astar.

I can feel the passion everyone has for Astar, and that energy is better spent working together to overcome challenges and achieve our shared vision. Let’s make this forum a space where every contributor feels valued and heard, fostering innovation and growth for the ecosystem we’re all invested in.

2 Likes
11

As mentioned in previous posts, my POV on V3 is as follows:

V3 is effective in reducing inflation, surpassing its target by over 200%. However, it somewhat fails to adequately support dApps that need it most (native projects) and frustrates stakers who want to use their stakes to help dApps, particularly during market swings. Additionally, it fails to sanction dApps with bad behavior by preventing users to play their guardian role, which should be the primary prevention mechanism for abuse.

I don’t believe the voting system itself is to blame. It helps reduce the “Stake&Forget” behavior from unlimited to 4 months max. I don’t think a manual reset, as proposed by @WakeUp, is necessary until the current system’s flaws are addressed. These include:

The problem arises from the dual nature of V3: a static system for stakers and a dynamic one for dApps. Once the voting period ends, stakers must stay with their chosen dApp to avoid penalties (bonus loss). Meanwhile, dApps face market fluctuations that affect the support they require during the B2E period (the threshold) when stakers are locked in.

The bonus system creates a 4-month lock-in, penalizing stakers who want to remain active and supportive. While this reduces inflation, it discourages staker involvement in the ecosystem since they can’t move their stakes without losing their bonus.

Additionally, dApps are hurt because it becomes harder to raise support during B2E when stakers are locked in. Furthermore, shifts in staker sentiment take up to 4 months to show, making it difficult for dApps to gauge their community’s support. Though some users, like @WakeUp, may voice dissatisfaction, most of the community expresses it through staking support.

The mechanism was designed for stability, to prevent bonus wars between dApps and give weight to dApp choices. However, the first two objectives prevent stakers from fulfilling their control role, while the third promotes a “yield-focused” mentality, as noted by @Maarten, where stakers who care can’t acte.

It makes no sense that users are sanctioned for withdrawing support from a dApp with bad behavior or for temporarily helping a dApp in need during B2E.

I understand a patch is in development to allow some unsanctioned movements during B2E. However, I believe stakers should have complete freedom of action, with a bonus loss only if they unstake more than they originally staked. While I hope this patch improves the situation, the slow progress and lack of a release date are concerning, especially given Astar’s focus on Soneium.

Regarding @WakeUp’s proposal, I agree:

dApps should provide regular public updates on their progress. For dApps, this should include:

  • A public GitHub at all times (non-negotiable, as they are funded by the ecosystem).
  • A roadmap update, showing completed, ongoing, and upcoming steps for the past and next two B2E periods.

For community-oriented projects, they should provide:

  • A log of activities/community initiatives.
  • A log of community growth.
  • A roadmap update for the past and next two B2E periods.

Since they don’t have a concrete product (a dApp), community projects should report more frequently—every cycle.

I would give 1-2 months after the due date for the report. A first breach leads to a warning, a second to a reset, and a third to delisting with at least 1 cycle of ineligibility to reapply. Delisted projects should only be able to reapply once. If a project voluntarily delists itself, it keeps the right to reapply.

These are just suggestions and not exhaustive. I invite feedback from projects on the required work proof that dApps and community projects should provide.

5 Likes
12

Those data are not really representative anymore but give a good overview of the unbalance of amount staked on leading project (look at Algem for instance)

It however the consequence of the new mindset set by the V3 which require that a project must build its own community first to attract more staker and then get more financial support (which IMO is equivalent as Putting Plow Before Horses).

Mecanisms which could mitigate that could be :

  • maximizing number of dApp supported instead of having just few blackhorses by :
    – limiting maximum amount staked per user on each dApp
    – giving an APY bonus to stakers for staking on emerging dApp and/or various dApp category and/or selected dApp which align with Ecosystem current need.

It may however increase a bit current inflation since more projects will be able to reach T4 & T3. But IMO it is necessary if we do not want to transform dApp staking in a ghost town just for the sake of low inflation.

Regarding your scenario 2, rewards given by project are very tricky.
Again, V3 aim to increase competition between dApps to attract staker.
They can give perks under various form which mainly depend on the project structur itself (a part of their revenu/dApp rewards, a part of their token, NFTs, reduction of dApp usage fee etc…). It is to note that very few projects created their own token as this require a good liquidity behind that to warranty a somewhat stable value. However, the golden age of ICO is revolute and it is therefore very difficult for new project to raise enough money for this puprose without a very disruptive project or wealthy backer. In addition, not creating new token favors usage of ASTR token.
I would thus not forbide but instead set clear rules and limites over such practice in order to not destroy one of the means to attract stakers.

Regarding your scenario 3, we also need to consider dApps which provide usefull tools for the Eco with the mindset of being a “free to use” dApp. dApp staking should serve to purpose too to minimaly cover infrastructure expense if completed and not further update is planned and financial support if tools are still in improvment process.

3 Likes
13

I’m glad you’re on the council.
I couldn’t agree with you more.
Everyone who is willing to discuss in the forum is important.

14

Thank you for your thoughtful message, Wakeup. I appreciated your commitment to Astar’s success and fostering a collaborative environment.

While managing discussions and ensuring alignment with our rules of engagement is vital, we also recognize the importance of open dialogue and constructive criticism in driving progress. Silencing voices is never a decision we take lightly, and it’s done with the intention of maintaining a respectful and productive forum for all contributors.

That said, your point about focusing on unity and fostering solutions resonates strongly. Let’s channel our shared passion into building a space where every voice is heard, valued, and contributes to Astar’s growth.

2 Likes
15

I can agree with you on many things.

Regarding progress reports, I think this should be done in the Portal, not in the Forum. If there are many active projects, discussions that should be in the Forum may drift away and become uncontrollable. Therefore, I propose that a section be added to each project page in the Portal to provide activity reports. This will also make it easier to see which projects to support from Portal.
Reporting should be done in the first week of each month and the dApps owner will leave a transaction with the report. If no reporting is done, the following penalties will be applied (automatically).

  • 1st stage: 33% cut in rewards
  • 2nd stage: 66% cut in rewards
  • 3rd stage: Delist

Even when a penalty has been incurred, a report can be made to restore the status to one of the previous stages.
It would be even better if the status of reporting and penalties could be easily understood by icons in the dApps list.

However, the drawback is that this would require a certain amount of development cost.

I disagree with you on this. Depending on the limit on the maximum number, it could be a burden on operations, as exchanges like Binance, for example, use dApp Staking. Also, the number of dApps that can be staked is limited to 16, which could also be a problem.

Interesting proposal, but may be difficult to justify; it might be interesting to do something like Curve’s Gauge ballot with a boost to the incentive in the form of a Subsquare voting.

T3 and T4 (especially T4) will only be a small part of the inflation and will not have a significant impact. I suggest adjusting the slots and increasing the amount of reward for T4. I’m posting the adjustments I proposed earlier here (they are still the same numbers as before, so please use them as a reference only).

I agree with you on this. It makes sense to support projects that are a public good with dApp Staking.

3 Likes