TLDR;
DApp Staking was activated around 2 months ago. And, as many people said here, here, and here, there are a lot of things we need to improve. Based on the feedback, we need to improve the first minimum viable product and ship dApp staking v2.0.
Problem
Currently, we are seeing 2 problems.
Freerider problem: some people say that dApps on our portal are receiving undeserved tokens. (ie projects are receiving tokens without contributing to the ecosystem)
Higher Revenue than it is needed: Since 50% of inflation goes to dApps today and the number of dApps is smaller than it is needed, the reward per each project is dramatically high.
Solution
I would like to propose a hybrid solution.
Creating 2 sections on the dApp store page. One is for live projects and the other is for pre-launch projects. People can stake tokens on all dApps and all dApps receive tokens based on the staking amount, but pre-launch projects can’t withdraw tokens till the projects are live on Shiden.
Increasing the % of staking rewards and incentivizing people to stake more tokens. Currently, 10% of the inflation goes to staker and 40% goes to dApp developers. We can make the ratio 25%:25%. This works because the number of dApps is still small. Once the number is increasing rapidly, we need to adjust the numbers.
The first solution seems great but what if the pre-launch project is not successfully launched on Shiden, let say they quit.
where will the locked reward for dApp Operator go? treasury? or distribute to the stakers? and I hope this solution does not affect stakers’ reward to be locked during pre-launch period.
Yes freerider is one thing, and I totally agree that pre-launch projects cant withdraw their token, till the projects are live
Ratio 25:25 are very much better, and fair enough for me, how about others?
Also I got several inputs regarding minimum how much SDN we need to stake, can It be more lower? like 50 SDN? Lower barrier to stake can attract people who wants to diversified their portfolio. Since high barrier and recent price performance not too good to attract people to stake on us. (sorry for talking price here, but we need more people to support us and growing our ecosystem)
The first solution seems great but what if the pre-launch project is not successfully launched on Shiden, let say they quit.
That’s a good point sir, thx
Can we apply the palette of crowdloan?
Currently, we are aware that forum discussions will determine the listing of dapps. However, I think there will be confusion as the number increases in the future.
-If we adopt crowdloan’s method
*dapps that are likely to contribute to the ecosystem are selected
*Unfortunately, if the dapps is not selected, the SDN will be returned to the holder
If performance degrades after being listed in the dapps store, it will be delisted and the sdn will be returned.
The idea here is to motivate them to work harder to chase the rewards. Therefore if they don’t work hard and fail to launch, I don’t think they should get the rewards. This pending rewards can be considered as “grant”. Just like Astar team, who received Web3 grants but only get paid after delivering the products. In case they fail, then I believe the community has the right to vote how to spend the rewards.
But stakers will always get their rewards regardless the situation.
What will be the determining points for a project to be considered Shiden ready? Is it dependent on performance and if so, what is the rubric/ standards they must meet before it’s decided that a dapp can launch or not?
Just bringing up more things to discuss as a community.
My input: dapp/project creates a list of deliverables with a estimated timeline (not years, too vague) that the community can hold them to. If deliverables aren’t met then they cannot progress to Shiden launch. This allows for transparency and the project to make and present realistic goals. Perhaps community can also vote on if the list of deliverables are sufficient enough.
Regarding Sota’s propositions, I’m agree with option 2 but for option 1, I think before new projects have access to the pre-launch dApps staking, they should have a MVP on Shibuya first.
Moreover, before listing new projects on pre-launch dApps staking, the project should bring significant value to the ecosystem with a reasonable amount of users + on-chain data.
The roadmap, with milestones, has to be shorter (1-3-6 months) and on notion, it would be easier for us to follow their work and advancement.
For existing dApps on dApps staking, we should reevaluate any dapps that has not shown working in shiden network, give them a warning and a period of 1 month to improve and do something before being kick-out.
I agree with Sota suggestion. Currently there isn’t much development from the Dapps , but they are earning SDN. So we need to give incentives to the builders who actually build on the network.
I understand that the developers may need income for building their Dapps too. If I may suggest, we could break their rewards into 2.
A small percentage of the reward will be given to them so that it can sustain them during development .
A part of it will only be given to them once they hit a certain milestone. So they will work towards hitting those milestone. If they do not hit it within a period of time, then they will be disqualify from getting the rewards. And the tokens will be burned.
It’s not a problem to make the staking amount lower. Technically it’s just a parameter.
We went with 100 SDN since we wanted the barrier to be high enough to prevent a lot of small
stakes.
Please keep in mind that number of staking slots per dapp is limited.
Shiden will be increased to 1024 on the next upgrade, but it’s still a finite number.
If we decrease the entry amount now, and decide to increase it later, that would mean we would
have to de-stake stakers who are below the new increased staking amount limit.
Not a problem technically, but it might make some people unhappy later.
Something to keep in mind.
Few suggestion on 1:
Decrease reward over time before going live
Rewards are locked 80 percent and tied to Dapps. In event, if it decide to close. It will be burnt.
Ecosystem can evaluate the use case of Dapps and valuate to purchase it, or resale to other offers.
Proper adjustment for dapps rewarding base on threshold (use case of the dapps) review the existing of 80 percent locked overtime with the increase user popularity and demands.
Improve verification process for dapps developer. Requires Id and name. So can impose penalties for dapps closed base on registered user ID
First of all sry for my english, I agree with Gunit, we should emphasize to the dapp building applicants that they are meant to bring different values to the ecosystem, and I was wondering if it is doable to ask the dapp builders to also include their expected amount of users (or any form of the value they are biringing with their product) within a given time period. In this case, the builders will receive adjusted rewards as penalty for delivering product but not reaching their promised value. Basically, I suggest to lock up the reward even if the dapp goes live, and should be monitored for a certain period of time before we distribute reward and it should be adjusted if necessary. Here we have the chance as community to select our builders, and sry to say that is why we need to be very strict with our selection
and their promises. It is not about merely increasing the amount dapps for stakers. We need to make the builder selection competive because only good builders will attract good builders to join on board.
Increasing the % of staking rewards and incentivizing people to stake more tokens. Currently, 10% of the inflation goes to staker and 40% goes to dApp developers. We can make the ratio 25%:25%. This works because the number of dApps is still small. Once the number is increasing rapidly, we need to adjust the numbers.
Sounds good, as mentioned before I can imagine for point 1, while they are developing they might need a form of income more so then when it is live, so maybe they can withdraw a small percentage like 25%?
I am a Shiden and Astar Crowdloan supporter and just wanted to get a few of my thoughts about DApp staking (which I am a part of from day one) and the problems mentioned above out here as well:
I think one of the problems we face right now is that the incentives for stakers and builders both are not aligned with the well-being and fruition of the protocol. As a non-idealistic staker you would always want to support the project that leads to the highest return. Right now these are the projects with the highest payback rate, no matter how good the underlying project actually is. Looking at the dapps-store these projects are the ones with the highest staked amount as well. For builders on the other side, they can maximize their build2earn rewards by optimizing their payback rate, not necessarily building a good product. I think solutions 1 and 2 don’t really tackle these general incentive issues. Sadly I don’t really have a good solution on how to solve this, but I hope we can discuss about that here.
Another thing that worries me is the way projects can get build2earn rewards. I guess most of you would agree that the way it works right now, were you have to apply to a person/organization is far away from a decentralized and permission-less approach but even when token holders directly or indirectly decide who can be part of the earn2build program, this doesn’t sound permission-less to me at all and certainly not scalable for a dapp-hub. Or was that never the plan and I just misunderstood? Otherwise build to earn to me sounds like nothing more than a treasury as we can find it in other projects as well?
I would really like to discuss those thoughts with you. And if I misunderstood certain dynamics I am happy for your feedback.
Promise in japanese.