I am using translation software to communicate in English and perhaps I am not communicating well. I am confused about communicating with you.
Yes, it is natural that there are no precedents for this. That is because there has never been a proposal involving different functionalities of the same dApp (as I see it) before. Therefore, my current proposal does not have any special implications. While it is good to be skeptical, it seems that you might be holding onto assumptions a bit too strongly.
There have been many times in the past when there have been multiple options for voting. For example, the most recent is the vote on ASTR’s Burn. Multiple ballot options can be created as needed.
Most votes are only that way because two choices, Yes and No, are sufficient. Things are not that simple, so it is not crazy to add more choices if necessary.
Thank you @VasaKing for your message and I am happy to read that the quality of our work is appreciated.
As you said very well, developing a new project takes time and requires certain resources. In my case, I develop mainly in my free time and from time to time, to move forward more quickly, I take days off (unpaid because I am freelance) to boost development. This is why I would like to benefit from a grant to have the time necessary to quickly develop the dApp on Astar zkEVM.
Unfortunately, tier 4 of dAppStaking rewards are not sufficient to be able to develop a serious dApp.
I understand your point of view and your arguments are valid.
However, I don’t think that grouping access to several dApps in the same menu is an argument to say that it is the same dApp. For example, we have access to bridges from Astar Portal. However, they are different products/branding. Many projects reference other complementary projects directly from their menu.
Yes, that is true, but I think the perspective is a bit superficial.
Astar Portal is an App Store, so to speak, that aggregates various dApps to begin with. However, Lucky is not, at least not right now: the UI, Ruffle, and Lotto providers are all the same, and it is difficult to think of Lucky as a platform where various dApps are listed.
This is just my opinion, and ultimately it will be up to the community to decide what they think. However, under the current situation, it could lead to “the same dApp can be listed by function”. And if that is the special exception this time, it will lead to the misunderstanding that “Ecosystem Agents are given preferential treatment”, which will be a negative for the community.
Therefore, my current opinion is that UCG is possible if the community agrees, but dApp Staking is not.
From the conversation, I think my concern is resolved since Lucky dApp and Lotto dApp are two different products, I would like to support builders, and I like the feature of cross chain dApp and on zkEVM
Glad you changed your vote.
In this proposal, the community’s opinion is more important than mine. I don’t want to build a dApp to receive a grant. I want to build a dApp that will be used by the community (which I hope) or provide code that can be used by other teams.
To be honest, I would prefer that grants were always given only after delivery, but the dAppStaking feature doesn’t work like that.
I have confirmed that you are registered with dAppStaking. I have also added “Lotto” to the site I am creating, which provides statistical information, so you can easily check the status and rank at a glance.
Thanks!
I have already started working on evm smart contracts deployed on Minato and multichain indexer.
I will publish a report in a month but I hope to have a first version deployed on testnet before.
That sounds like a solid plan! Getting the first version on testnet soon is a great step, and publishing the report will definitely showcase your progress, thank you!
