Perhaps there is a misunderstanding. My and Maartin’s current perceptions of dApp Staking are in agreement. I perceived it as “developer support” in v2 and the current v3 as “incentive to developers”. I believe that the current amount of money is not enough to support developers, so it stands only as an additional incentive.
Going forward, I will comment according to what you think the concept (developer support) is, not according to the current definition of dApp Staking.
For Issue(1)
This requires thinking with Tokenomics as a whole, not just the dApp Staking system. If dApp Staking were to be changed as you propose, the way it would be funded would be to provide the current developer fee allocation as seed funding (13% of inflation).
In this case, approximately 75M ASTR per year ($4M at current prices) would be available for budgeting.
However, there is no budget for this at the beginning of the system change, so it would need to accumulate for some time.
Alternatively, you can decide to accumulate all the money in the treasury and contribute as needed. In this case, funds can be provided immediately after a system change.
For Issue(2)
I don’t know if issue (1) can be solved. Because there are plenty of blockchains that have more funding and can attract more (Monad, MegaETH, etc.). If the only incentive is to get initial development funding, they may not do sustained development.
For Issue(3)&(4)
Yes, I think it is important to formulate a strategy aligned to Soneium in the current situation. That is why Astar Surge and ACS. Also, just yesterday it was announced that ASTR will be used to protect Soneium. Soneium has only just launched and I am sure that many campaigns will be launched in the future.
This is close to the dApp Staking so far, but we recognize that if we adapt to what you want to do from what you have described so far, we will have the following differences from the current system.
- Concentrate rewards on specific dApps by time period rather than passing rewards to multiple dApps
- Rewards are passed on collectively, rather than per ERA
At this time, problems arise on various fronts.
- What if there are no new projects seeking funding? (Staker staking location)
- If you receive a lump sum of funding, it may disappear without being developed. In many cases, grants are milestone-based or have contractual restrictions on their use.
- If there are few participants, the vote may be skewed by malicious projects or interested parties, making it easier to obtain funding.
- How do you register and list eligible projects?
As such, I feel that this is not compatible with a system like dApp Staking that runs automatically.
Of course, I understand what you want to do, but I still think that if you are going to give some large sum of money to a project, it should be given carefully under on-chain governance. Treasury is a good source of funding for this, and also UCG using dApp Staking.
If you want to strengthen dApp Staking’s role as a developer support, it would be better to change the parameters of the system, as I have previously written in the Forum.
If you want to increase the frequency of seed funding, you could also change the inflation allocation to match the above parameter changes and reduce the current developer and staker fees and increase the treasury’s share.