Thanks for the update, let me know if you need any help with testing<3
Hey everyone,
the suggestion for Astar Governance parameters can be found here. It’s staging documentation update, to be merged once values have been finalized.
(NOTE: after the doc update PR is merged, the link will become invalid)
A brief overview:
- Both
LaunchandVotingperiod would last for 7 days, which means 1 referendum per week - The minimum deposit required to create an on-chain proposal will be 1000 ASTR
- Base governance lock duration will be 9 days, matching the unlocking period for dApp staking (conviction rules apply)
- Treasury requests will require a deposit equaling 5% of the requested amount, but always at least 100 ASTR & not more than 1000 ASTR
- Treasury spend period will be 7 days, meaning funds will be paid out on a weekly basis
- Community council will be able to:
- register a new dApp into dApp staking with 2/3 agreement
- unregister a dApp from dApp staking with 4/5 agreement
- perform lock/unlock/stake/unstake operations with 2/3 agreement
- approve or reject community treasury spending via 2/3 agreement
Please comment on the parameters in the next few days!
We’d like to have feedback ideally by next Monday. 25th of November.
4 Likes
That makes sense. We might need to make some adjustments in the future. Can we modify these parameters through an on-chain proposal?
Only council members can be modified through an on-chain proposal.
Parameters are defined as constants in the runtime, and require a runtime upgrade to modify.
1 Like
Got it. Thanks for responding.
1 Like
Hello @Dino,
Thank you for the suggestion.
I noticed that the required agreement ratio for registering (2/3) and unregistering (4/5) a dApp in dApp Staking is different. Is there any particular reason for this?
Good question!
We’ve had discussions internally, and initial sentiment was that we shouldn’t allow the council to unregister dApps because it might seem too excessive.
The reasoning is that allowing a dApp to enter dApp staking is an action that cannot damage anyone directly. It’s a pretty light operation, done based on promises. You register a dApp - that’s it. If it wants to earn rewards, it needs to attract some amount of stake.
On the other hand, unregistering a dApp is a heavy operation. It can be a big deal for a project that’s potentially already earning, and then they are suddenly kicked out.
But after some more discussions, it was decided to allow it only if large majority (in this case 80%+ of council members) agree.
TL;DR - unregister is a more serious operation compared to register.
3 Likes
Thank you for the clear response.
I anticipated that unregistering would require more agreement votes than registering, indicating its importance. Given that discussions will take place within the council under the new governance v1 for both registration and unregistration, I believe this will lead to high acceptance. As initial parameters, I think this setup is reasonable.
1 Like
Great!
We’ve made a new (pre)release with the proposed changes: Release runtime-1100 · AstarNetwork/Astar · GitHub
If after some time we see that params need changing, we’ll revisit this topic 
1 Like