# Astar Governance v1 **URL:** \ **Category:** Offchain Discussions\ **Created:** [June 17, 2024, 11:11am UTC](https://forum.astar.network/t/astar-governance-v1/6999 "2024-06-17T11:11:37Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Dino](https://avatars.discourse-cdn.com/v4/letter/d/e95f7d/32.png) [@Dino](https://forum.astar.network/u/Dino)\ **Post date:** [June 17, 2024, 11:11am UTC](https://forum.astar.network/t/astar-governance-v1/6999/1 "2024-06-17T11:11:37Z")
# 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: [Polkadot OpenGov - Polkadot Wiki](https://wiki.polkadot.network/docs/learn/learn-governance) ( 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](https://forum.astar.network/t/astar-governance-technical-specification-proposal/6692)). 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 # Updates - [UI support solution & date](https://forum.astar.network/t/astar-governance-v1/6999/15) ---
**Author:** ![defiguy](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.astar.network/defiguy/32/1358_2.png) [@defiguy](https://forum.astar.network/u/defiguy)\ **Post date:** [June 17, 2024, 12:34pm UTC](https://forum.astar.network/t/astar-governance-v1/6999/2 "2024-06-17T12:34:47Z")
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. ---
**Author:** ![you425](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.astar.network/you425/32/3313_2.png) [@you425](https://forum.astar.network/u/you425)\ **Post date:** [June 18, 2024, 6:02am UTC](https://forum.astar.network/t/astar-governance-v1/6999/3 "2024-06-18T06:02:01Z")
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. ---
**Author:** ![souleater](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.astar.network/souleater/32/210_2.png) [@souleater](https://forum.astar.network/u/souleater)\ **Post date:** [June 18, 2024, 6:04am UTC](https://forum.astar.network/t/astar-governance-v1/6999/4 "2024-06-18T06:04:03Z")
> [@Dino](#): > > 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. 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. ---
**Author:** ![souleater](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.astar.network/souleater/32/210_2.png) [@souleater](https://forum.astar.network/u/souleater)\ **Post date:** [June 18, 2024, 6:05am UTC](https://forum.astar.network/t/astar-governance-v1/6999/5 "2024-06-18T06:05:58Z")
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. ---
**Author:** ![GuiGou](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.astar.network/guigou/32/1366_2.png) [@GuiGou](https://forum.astar.network/u/GuiGou)\ **Post date:** [June 18, 2024, 8:21am UTC](https://forum.astar.network/t/astar-governance-v1/6999/6 "2024-06-18T08:21:34Z")
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. ---
**Author:** ![ERC20s](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.astar.network/erc20s/32/34_2.png) [@ERC20s](https://forum.astar.network/u/ERC20s)\ **Post date:** [June 18, 2024, 10:45am UTC](https://forum.astar.network/t/astar-governance-v1/6999/7 "2024-06-18T10:45:48Z")
I believe we need more autonomy than just ASTR holders before further decentralizing the network. I suggested here before: > [@On-chain voting](https://forum.astar.network/t/on-chain-voting/3646/9): > > I kinda like the idea of an percentage based on-chain points based system… Example: 1 ASTR = 70% of voting power Lockdrop 1 = 10% of voting power Lockdrop 2 = 10% of voting power Own a degen NFT = 1% of voting power Deployed a smart contract = 1% of voting power Joined the forum = 1% of voting power In the discord = 1% of voting power Telegram = 1% of voting power Verified on-chain identity = 5% of voting power ETC A [snapshot](https://snapshot.org/#/) style voting system is the most popular currently… I pro… ---
**Author:** ![you425](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.astar.network/you425/32/3313_2.png) [@you425](https://forum.astar.network/u/you425)\ **Post date:** [June 19, 2024, 6:12am UTC](https://forum.astar.network/t/astar-governance-v1/6999/8 "2024-06-19T06:12:24Z")
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. ---
**Author:** ![ERC20s](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.astar.network/erc20s/32/34_2.png) [@ERC20s](https://forum.astar.network/u/ERC20s)\ **Post date:** [June 19, 2024, 11:11pm UTC](https://forum.astar.network/t/astar-governance-v1/6999/9 "2024-06-19T23:11:35Z")
I think the biggest point of failure is having Binance out voting us on proposals. Like they did with STEEM. ---
**Author:** ![bao](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.astar.network/bao/32/1809_2.png) [@bao](https://forum.astar.network/u/bao)\ **Post date:** [June 21, 2024, 1:41am UTC](https://forum.astar.network/t/astar-governance-v1/6999/10 "2024-06-21T01:41:32Z")
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. ---
**Author:** ![souleater](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.astar.network/souleater/32/210_2.png) [@souleater](https://forum.astar.network/u/souleater)\ **Post date:** [June 21, 2024, 3:00am UTC](https://forum.astar.network/t/astar-governance-v1/6999/11 "2024-06-21T03:00:52Z")
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. ---
**Author:** ![bao](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.astar.network/bao/32/1809_2.png) [@bao](https://forum.astar.network/u/bao)\ **Post date:** [June 21, 2024, 3:33am UTC](https://forum.astar.network/t/astar-governance-v1/6999/12 "2024-06-21T03:33:21Z")
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 😅 ---
**Author:** ![Leo](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.astar.network/leo/32/1885_2.png) [@Leo](https://forum.astar.network/u/Leo)\ **Post date:** [June 24, 2024, 12:38am UTC](https://forum.astar.network/t/astar-governance-v1/6999/13 "2024-06-24T00:38:54Z")
Thanks for update. It will be my Topic of this week article. 🖤 ---
**Author:** ![Vangardem](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.astar.network/vangardem/32/2184_2.png) [@Vangardem](https://forum.astar.network/u/Vangardem)\ **Post date:** [June 26, 2024, 8:22pm UTC](https://forum.astar.network/t/astar-governance-v1/6999/14 "2024-06-26T20:22:42Z")
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. ---
**Author:** ![Dino](https://avatars.discourse-cdn.com/v4/letter/d/e95f7d/32.png) [@Dino](https://forum.astar.network/u/Dino)\ **Post date:** [August 5, 2024, 3:32pm UTC](https://forum.astar.network/t/astar-governance-v1/6999/15 "2024-08-05T15:32:17Z")
## Update The logic has been deployed on Shibuya some time ago. We still haven’t started any community driven testing actions since the UI is missing. We could do it via `polkadot-js app` but that would be messy. 🙂 Regardless, we’ll also share a guide how to do this, in case someone ever needs it. For the question of UI - everyone has been using the `Townhall` platform recently. The feedback has been positive, so we’ve asked the team behind it to upgrade it to support `Astar Gov V1`. This should make it easy for existing users who already participate in voting to simply start utilizing the new system as well. Expect a post from `Townhall` team within the next days with more information. The latest date at which the entire feature should be available is **1st of October 2024**. ---
**Author:** ![pitcoin777](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.astar.network/pitcoin777/32/1912_2.png) [@pitcoin777](https://forum.astar.network/u/pitcoin777)\ **Post date:** [August 5, 2024, 4:17pm UTC](https://forum.astar.network/t/astar-governance-v1/6999/16 "2024-08-05T16:17:08Z")
Thanks for the updates @Dino ---
**Author:** ![tksarah](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.astar.network/tksarah/32/1947_2.png) [@tksarah](https://forum.astar.network/u/tksarah)\ **Post date:** [August 5, 2024, 10:08pm UTC](https://forum.astar.network/t/astar-governance-v1/6999/17 "2024-08-05T22:08:11Z")
Thank you for your update @Dino. I’m looking forward to it as well. ---
**Author:** ![VasaKing](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.astar.network/vasaking/32/1568_2.png) [@VasaKing](https://forum.astar.network/u/VasaKing)\ **Post date:** [August 6, 2024, 8:50am UTC](https://forum.astar.network/t/astar-governance-v1/6999/18 "2024-08-06T08:50:43Z")
Nice , thx for the updates 🤝 ---
**Author:** ![bao](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.astar.network/bao/32/1809_2.png) [@bao](https://forum.astar.network/u/bao)\ **Post date:** [August 12, 2024, 2:49am UTC](https://forum.astar.network/t/astar-governance-v1/6999/19 "2024-08-12T02:49:00Z")
Looks great. Thank you for the update. ---
**Author:** ![Juminstock](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.astar.network/juminstock/32/5942_2.png) [@Juminstock](https://forum.astar.network/u/Juminstock)\ **Post date:** [August 12, 2024, 12:08pm UTC](https://forum.astar.network/t/astar-governance-v1/6999/20 "2024-08-12T12:08:43Z")
Currently there is an active proposal regarding this topic, we are talking about the first development by Townhall with the AstarGov. Check out here 👇 > [@Astar Governance Product Development by Townhall](https://forum.astar.network/t/astar-governance-product-development-by-townhall/7171): > > TL;DR The discussion outlines the scope of a strategic collaboration between Townhall (Polka Labs Pte. Ltd.) and Astar Network Treasury to research and develop the governance infrastructure and supporting products for the Astar Network ecosystem. The document highlights the details of work done and makes a retroactive funding request to the Astar community as the first decentralized treasury proposal in Astar ecosystem. Discussion The discussion aims to highlight the work done to create a r… [Next page](https://forum.astar.network/t/astar-governance-v1/6999.md?page=2)