Astar Governance v1

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. :man_shrugging:

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 :slightly_smiling_face: )

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
  • 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-cancel can 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
10 Likes

I think it’s a good move to further decentralize the network. The Sudo key was always a possible FUD for actors that don’t like Astar, and getting rid of this centralized point will greatly benefit confidence because Astar has already reached enough maturity to sustain simple on-chain governance.

I remember the governance plan by @hoonkim, which included a system of subDAOs. It will be possible to create DAOs with their budget for each of the world regions, like Europe, LATAM, NA, and APAC. This way, the ambassadors for each region can manage events, webinars, and business development functions to onboard applications to the Astar ecosystem.

2 Likes

I am looking forward to the transition to on-chain governance.
As for the Sudo key, it has been talked about from time to time and I am glad we have reached the stage where it can be discarded.

I think it makes sense to use Polkadot’s v1 governance at first since this is a phased transition.

2 Likes

Correct, Gov v1 still the best for now. To be honest I dislike OpenGov, worried there will be bad actors.
Removing Sudo is one milestone towards decentralization.

1 Like

I also several times participating on other parachains governance such as Hydra or Interlay. My opinion it doesn’t give common users a headache. Although it would be great if we had a custom UI fitted for Astar complete with tutorial.

2 Likes

Sudo via multisig is necessary when the project is young, to be able to develop quickly. Now Astar is mature enough to remove this facility and if we want an increasingly decentralized ecosystem, this is a necessary and important step.
I trust the Astar team to achieve this goal, technically speaking.
I hope that ASTR holders will play the game and be active in governance.

1 Like

I believe we need more autonomy than just ASTR holders before further decentralizing the network.
I suggested here before:

1 Like

To be complete as on-chain governance, it has to be as simple as possible to collect all information on-chain.
Your proposal might work if we use Oracle or other tools, but I don’t think it is reasonable because it would create a lot of hurdles and points of failure.

1 Like

I think the biggest point of failure is having Binance out voting us on proposals.
Like they did with STEEM.

Regarding whale problem, I believe the “govASTR” proposed by Hoon previously would be effective.

By creating a token specifically for governance, we might be able to build a system where power is less likely to concentrate in the whales.

As governance transitions, I’d like to advance this discussion as well.

Yes Bao, agree with you.

But what Dino suggest is a temporary solution for our decentralization while we are waiting for Hoon’s solution. This is for removing Sudo key I believe. And this is the best practice, as we entering mature phases.

1 Like

Thank you for your comment! Of course, I agree with this proposal as well.
Since govASTR is a future matter, it seems better to discuss it in a another thread :sweat_smile:

1 Like

Thanks for update. It will be my Topic of this week article.

:black_heart:

I am in favor of this proposal. Allowing other stakeholders to join in the decision making of the network is an important step. Decentralization has always been the north of Astar since its origins and that today we can expand it is a great pride, indeed Astar is a mature network and this step in governance is essential to continue reaching future milestones.

2 Likes