Thank you for taking time out of your busy schedule to comment as the launch of zkEVM approaches. I also have nothing but respect for you and your core team leading the development.
Yes, this is absolutely true - it was proposed over a year ago, and no one opposed it at the time, and neither did I.
However, the parameters were not finalized as of a year ago, and the specific parameters did not come out with the report until last August.
We then looked at the parameters at this time and determined that there was no problem.
However, the parameters were changed this month (of course, I don’t think it’s strange that changes are being made).
Or is it at the time of this posting?
I am ashamed to admit that I only noticed this significant parameter change when I checked the documentation in this post. This is just before v3 is completed implementation in Astar.
Tokenomics has changed a lot with this parameter change, and while it is understandable that it was hastily adjusted to coincide with the launch of zkEVM, I think this is too much of an explanation. One wonders how many community members were able to see the changes. The way the change was made, it was felt that it was made even more difficult to recognize, since detailed numbers had been provided in the past.
This change changes Extra Rewards to Bonus Rewards and also changes the mechanism itself. There were no postings where we could read this information, and we had to read the documentation to grasp it.
Tokenomics 2.0 is explained to the public in blogs as well as reports.
https://astar.network/blog/astar-tokenomics-2.0:-driving-long-term-success-and-39068
However, there is no explanation of this change. Therefore, I hastily prepared an explanatory article for the community. (I had been waiting for Astar to make an official announcement because I was aware that the previous parameters were only temporary.)
Change of Allocation
And this has resulted in a significant change in compensation, especially for dApps. I am posting the image again to make it cheaper to compare.
August 2023
Current(Thank you, Dino)
Rewards were reduced across the board, most notably in Tier 4.
- TIer1: -33%
- Tier2: -17%
- Tier3: -33%
- Tier4: -86%
Yes, I think this is correct. And I don’t think it is strange that this would result in a modification to the parameters presented in August. But this was too extreme. And I didn’t feel there was any room for discussion about this change.
If there had been room for discussion, I would have suggested creating a middle ground between Tier 3 and Tier 4 (i.e., increasing the number of tiers).
I agree with this, but I am not sure how much ASTR should be collected to be no longer at the introductory level. And I don’t think there is a right answer to this.
Yes, I believe that is true. However, the more a project needs help from dApp Staking, the more difficult it should be to earn a user base in its initial state. I recognize dApp Staking as a system that gives developers a kind of basic income to make it easier for them to focus on development. However, I am not sure of the value of its existence when disparities like this one occur.
Of course, even in this situation, I think it has a great effect compared to blockchain, which gives a portion of the gas money back to the smart contract deployer. However, I feel this is a bit different from the significance I felt for dApp Staking (maybe it’s just me).
Thank you for your words of praise!
However, I did not understand the meaning of this comment. It may be a matter of your perception due to my lack of explanation.
In my proposed model, the maximum reward for each Tier is determined based on the number of slots allocated. Therefore, an increase in stake in any of the dApps will not affect the other dApps. In other words, there is no competition for market share as in v2. This is one of the key features of the hybrid model.
In order to get the full amount of rewards allocated to each Tier slot, the ASTR must be staked up to the limit.
The other parts I did not specifically comment on are the parts I basically agree with. I salute you.
Thanks in advance for your implementation of the Tier recalculation and the oracle thing. Thanks again.
I also appreciate the ongoing efforts to adjust parameters and logic based on observations.
However, I think it is undeniable that some aspects of this case were caused by a lack of information sharing (not your fault, but the Foundation’s problem as a whole). On that basis, I have proposed this hybrid model, which I believe can be improved in a way that is as close as possible to the intent of this parameter change.
I am not proposing this based on content that came out over a year ago, I am proposing it based on what was implemented this month and the reaction to it.
Nevertheless, of course, if this is adopted, it would be a major change and would be expensive to develop. Therefore, I would be fine with it if it is acceptable to the community (including developers), including a temporary solution.