Overview
Since Astar launch, privileged actions have been done using a sudo approach controlled by a multisig consisting of Astar team leaders. It has worked relatively fine so far, but it’s still a sudo key. 
To further decentralize the network, we’d like to get rid of it. And, of course, this is done by introducing governance mechanism.
To cut straight to the point, we intend to reuse Polkadot’s v1 governance model since it’s simple & easy to maintain, unlike OpenGov. The core idea is to further decentralize the network, but not re-invent the wheel. And Gov v1 seems like the perfect first step to take.
- official docs: Governance V1 · Polkadot Wiki
( this is the part where I’m counting on the reader to check the actual linked docs & understand it
)
Structure
We will have the Main Council, initially consisting of Astar leaders. Once we see this in action for some time, we will look into expanding the council with members outside the team, e.g. from the ambassadors & the community.
We will have Technical Committee which includes people with deep technical understanding of the Astar network & who have been with the team for some time.
We will also have a Community Council to manage fast tracking of the dApp Staking registration, handling community treasury & UCG staking.
We will utilize conviction voting, locking of tokens, two different tracks, etc. Essentially, the things covered in the official Polkadot network Gov v1 docs will apply to us, with the main difference being in parameters.
What Does This Mean?
Essentially anyone holding ASTR token will be able to do an on-chain proposal, which can be upgraded to a referendum & enacted if passed.
Users no longer need to rely solely on the core team to propose & enact certain actions, it will all be doable on-chain.
While Main Council & Technical Committee are well described in Polkadot’s official documentation, the Community Council will be something unique to our network.
A mixed group of members (ambassadors, community, builders, core team) will be able to fast-track registering dApps into dApp staking, will be able to approve treasury grants from the community treasury, and will be able to decide who to support via UCG program.
All of the actions that are doable by the Community Council will still be doable via public referendum - I’d like to emphasize that even though the Community Council can fast-track dApp registration, this action can be done just the same via a public referendum. It is not possible for the Community Council to block (nor to unregister) dApp from dApp staking.
Relationship With The Hoon’s Governance Proposal
The primary goal of Gov v1 proposal is to further decentralize the network, and lay out the foundation to get rid of the sudo. This model has been tested & is used by the majority of parachains on Polkadot. It’s battle-proven, with known weaknesses & is relatively easy to integrate and to get started with.
Of course, it isn’t perfect, but it’s much better than having a sudo multisig.
That being said, it does not conflict with the proposal made by Hoon (here). That proposal still has a long road ahead of it, from finishing tech design, implementation, testing, Shiden integration & testing, etc.
Once it’s mature enough for Astar, we can phase out Gov v1 & replace it with whatever is decided as the way to go forward.
I’m strongly emphasizing that it’s not an either/or scenario.
Deployment & Integration Plan
The plan is to first deploy this solution on the Shibuya within the next few weeks. We will test it out, see about integrating it with existing frontend solutions (Polkaassembly, Townhall).
After this testing & integration phase has been finished, we will deploy it on Astar. This is expected to happen at the end of the summer.
We will not be deploying this on Shiden. The reasons are described in the linked forum post in the previous chapter.
On-chain Actions
This is more of an on-chain overview of the actions that certain actors can execute.
It’s technical, but should be readable by everyone to get a grasp of how things work.
It is supplementary to the linked Polkadot documentation.
Making & Seconding A Proposal
- Public Proposals
- anyone can make a proposal, but they must reserve some funds in order to do so
- the amount reserved must be greater than defined minimum value, and cannot already be in use by any lock/freeze mechanisms (dApp staking funds aren’t allowed)
- proposal can be seconded by another account, which must match the deposited amount of the proposal
- anyone can make a proposal, but they must reserve some funds in order to do so
- External Proposals
- can be proposed by a custom origin, e.g. by the Main Council
- only one proposal can exist in the external queue, there’s no seconding
- can be proposed with either a simple majority or negative turnout bias (configurable)
- a new proposal can be launched for voting after each voting period expires
- Public & External proposals alternate between the launch periods
Voting For A Proposal
- votes can be either aye or nay
- user can choose how much of their tokens are they willing to use for the voting power
- user can choose to vote directly OR they can delegate their voting power to someone else (cannot do both)
- if the voter’s vote is aligned with the outcome of the referendum, the tokens used to vote will be locked
- once the lock on the funds used to vote expires, users have to manually unlock them (transaction)
- tokens that are in use by dApp staking can be used for governance actions
Delegation
- users can choose to delegate their funds to someone else
- conviction still applies
- the unlocking period begins only AFTER the delegator decides to undelegate the funds
Canceling A Referendum
- referendums can be canceled, in different ways
- same referendum hash cannot be canceled twice, so it’s not possible to censor the same proposal indefinitely
emergency-cancelcan be used by a custom privileged origin (defined in runtime)- root origin can also utilize the cancel call
- referendum can be canceled as part of a blacklist operation, which essentially bans it indefinitely
Canceling & Blacklisting A Proposal
- caries monetary consequences, unlike canceling a referendum - funds used to second the proposal will be slashed
Fast Track
- allows for an externally proposed majority carries proposal to immediately be put up for vote, with a reduced voting period
- this is a privileged action, and is intended to be used in case of emergencies
- another subtype of the fast track is instant track which essentially allows extremely short voting periods (this can be disabled if needed)
- allows to override the standard enactment delay, meaning it can essentially happen instantly
Vetoing External Proposals
- in case e.g. technical committee disagrees with the external proposal, made by e.g. the main council, they can decide to veto the proposal
- this will also blacklist the proposal for some time
- however, there are calls which the external origin can make to bypass the blacklist barrier (configurable)
Treasury Handling
- will be handled similar to as described in the Polkadot gov v1 documentation
- arbitrary user can request funding from the treasury, and the council needs to approve it
- user need to reserve some ASTR in order to make the request - in case of approval, the deposit is returned, but in case of rejection it will be slashed
- users should ensure to make a forum or townhall discussion, check the temperature & sentiment from the community, before making the on-chain request
- there will be two distinct treasuries:
- main on-chain treasury - gets filled with a portion of the inflation, requires Main Council to approve spending
- community on-chain treasury - handled by the community council, can be increased via receiving dApp staking rewards, requires Community Council to approve spending
