Astar Governance Technical Specification Proposal


Hello, dear Astar community. This is Hoon, the former Chief Technology Officer of Astar Foundation, and now the Chief Technically is still working on the network Officer of Astar Network.

This is the second of three main posts regarding Astar Governance modeling. The first post discussed Astar community culture and how we should view dApp Staking and the community treasury. For casual and long-term community members passionate about the network’s governance, you should read that post, as the topic is still active until we formalize the rules. This post will be more technical, and we’ll dive deeper into the mechanism for Astar Governance and how it should work in detail. For the technical mind and people from the Foundation, this post will be the place for hard-hitting discussions.

Jaski and Neel from the Townhall team collaborated on researching, modeling, and drafting all the technical details with me. We’ve presented it as a proposal to our community, seeing as the model is a suggestion from a community contributor. Our aim with this post is to gather everyone’s feedback and suggestions. This will allow us to collectively refine the model and shape the future of Astar Network as a community before our final post, which will be a formal community treasury proposal and votes to get the project officially started.

Everything we mention here is meant to work with the Townhall UI for Astar Network so that the UI and the protocol functions are not isolated and provide the best unified UX. You can also access this post through the Townhall UI.


We present an in-depth analysis and proposal for the governance model of the Astar network. It discusses the setup and functioning of the voting power, voting process, conviction voting, treasury-related governance, and the roles and responsibilities of the stakeholders involved in Astar governance. The document also covers the simulation of different case scenarios, such as maximum delegation, minimum delegation, and potential collusion among dApps in the voting process, as well as the mechanisms to solve potential attack vectors. It provides recommendations for the initial Treasury setup, including creating sub-treasuries and submitting bounty requests that projects can make to the treasury for further ecosystem development.

The design of the govASTR token has several objectives:

  1. Minimise end-user friction to participate in governance
  2. Transfer governance power to the network’s most aligned stakeholders - dApps, ambassadors, and other contributors
  3. Establish a democratic system with high voter participation

We issue govASTR based on the stake locked in dApp staking to minimize end-user friction. To combat voter apathy often seen in other DAO governance systems, we offer a default delegation option (delegate voting to dApps) to Astar Network stakers. They can delegate their votes to the dApp they support through dApp staking or can choose to be active contributors and community members in the ecosystem. In the following proposal, we deep dive into the various mechanisms and fallback strategies that can be implemented to get the expected behavior from various stakeholders and create the governance system tailored for the Astar network.

Voting Power and Issuance of govASTR

While many decentralized networks use the network’s native token or create a separate governance token with monetary value to represent a user’s vote on protocol matters, we don’t believe this approach aligns with Astar Network’s long-term vision. Instead, we measure user voting power based on their network activity, treating it as a means of influence rather than an asset for speculation. To support this approach, we introduce the govASTR token.

The govASTR minting is coupled with the dApp staking flow and maintains complete autonomy. To minimize friction, users will be offered a default option to delegate their voting power to the same dApp as the one they delegate their ASTR token for dApp staking. Users can also delegate voting power to other dApps, community members, or foundation delegates. At the end of the cooldown period, we calculate the govASTR allocation for each delegate involved using the concept of quadratic voting power.

We share the voting power calculation for each delegate (followed by the actual govASTR tokens allocated to these users). As mentioned, one of the system’s goals is establishing a highly democratic process. The quadratic voting helps us get closer to our goal but increases the share of votes allocated to smaller delegates while penalizing the concentration of stake. Quadratic voting helps us solve the centralization risk to a certain extent, but still, a significant accumulation of voting power can skew the system away from intended goals. Thus, we also suggest a maximum cap per delegate.

Delegated dApps receiving more stake beyond the maximum cap cannot acquire more govASTR. It would be in their and the networks’ best interest to re-delegate that additional voting power to smaller, like-minded dApp developers or community members to maximize the net voting power across multiple users.

A key difference between dApp staking and Astar Governance is that the governance process is open to more dApps, individual community contributors, and foundation members as delegates. This is possible because the govASTR token has no direct monetary value.

govASTR in Circulation

dApps can choose to conserve parts of their govASTR allocation in a particular epoch and use it in upcoming epochs. This mechanism also indirectly allows dApps to express conviction if they utilize their unspent voting power from previous epochs in the future. However, the ability to carry forward govASTR comes with its restrictions. The unspent voting power halves with the upcoming epochs. This also allows us to predict the maximum govASTR in circulation during an epoch and can, at its very limit, reach 2 million tokens. The govASTR in circulation will be lower than 1.7 million tokens in all practicalities.

Modeling Objective 1

Evaluate the value of voting rights and governance power. Analyze how changes in ASTR token price impact the influence of token holders in the governance process.

govASTR holds no economic value, but the voting power decides the allocation of treasury spending. Therefore, it can derive secondary value through potential bribing mechanisms and collusion to skew governance votes.

Simulation assumptions:

  1. The ASTR token price affects the treasury size as most of the treasury is held in ASTR tokens;
  2. The treasury is spent every quarter and is being replenished regularly due to inflation rewards diverted to the treasury (5% of inflation);
  3. At any given point, the number of govASTR tokens in circulation will be between 1 million and 2 million, based on unutilized votes in the previous epoch;
  4. Only a portion of votes will be susceptible to bribing mechanisms, as major dApps and delegates receive voting power and risk reputational damage by accepting such bribes.

Votes at risk of bribing - individual stakers not delegating and smaller dApps (We can assume this to be <20% for all practical purposes after looking at the stake distribution data).

Proposal Queue System

The proposed governance system limits the number of active proposals under consideration at each governance epoch to Five. This limit can be adjusted in the future, depending on the frequency of governance proposals. Doing so ensures that dApps participating in the governance process are not overwhelmed with information. This allows them ample time to review ongoing proposals and make informed decisions.

In times of high network growth, the number of submitted proposals may exceed this capacity. These incoming proposals are added to a queue, and all proposals in the queue can be selected for the next round of voting.

At the same time, we must ensure that no proposal has to wait too long to be selected in the voting process. We define a function that calculates a Q-score for every proposal in the queue and selects the n-highest proposals (n being the number of proposals eliminated from the voting process in the previous epoch).


  • k - Scaling variable to increase the probability of overdue proposals to be selected
  • VRF_number - Random number generated for i-th proposal in queue
  • epochs in the queue - Numbers of epochs a proposal has been waiting for in the queue

The proposed queue system would be as follows: Each proposal receives a Q-score based on the epochs they’ve waited in the queue and a verifiable random number. Each voting period creates vacancies in the voting batch of proposals, and an equivalent number of proposals from the queue are selected based on their Q-scores. The higher the Q-score, the higher the chance the proposal gets selected.

We simulated 15 iterations of 30 epochs of the governance process to calculate the k-parameter suitable for Astar governance’s queue system. With a k-parameter selection of 0.2, we achieved the following results: the average time spent by proposals in the queue and the modal time for a proposal in the queue.

Average time for proposal in queue Modal time for a proposal in the queue
2.121 2
1.333 0
4.155 3
0.925 1
1.283 1
2.017 1
2.222 1
2.039 2
3.421 2
4.345 2
1.738 1
1.396 0
2.260 0
4.500 4
1.170 0

Based on these results and the initially lower expected frequency of proposals in the Astar governance system, we propose the selection of the k-parameter as 0.2.

Spam Prevention

A potential issue in the abovementioned queue is that a team might repeatedly submit the same proposal to increase its chances of being selected for voting in the next governance cycle. A spam proposal is any insincere, irrelevant, or submitted with harmful intent. These proposals can disrupt the flow of legitimate proposals, impeding productive discussions and decision-making.

We need a governance stakeholder to monitor the proposal queue. Given the council’s crucial role in treasury management, assigning spam prevention to a separate group of contributors could enhance system efficiency. This group, called 'Governance Stewards,’ would be responsible for routine tasks such as proposal review, evaluation, and spam prevention. They would work under the council’s overall supervision.

Compensation for this work could be set up as a continuous bounty. This method ensures fair payment for the Treasury Stewards while maintaining a system of accountability and performance assessment.

To discourage the submission of spam proposals, the system requires proposers to post a bond (1000 ASTR - subject to change via governance). If the Governance Stewards identify a proposal as spam, the proposing team’s bond is forfeited. This penalty discourages disruptive behavior. We also suggest using some penalties to fund the Governance Stewards’ operating budget.

Dispute Resolution

However, it’s important to ensure fairness and provide avenues for dispute resolution. If proposers think their flagged proposal was not spam, they can contest it by posting an additional bond. In these cases, the entire council reviews the disputed proposal. This process promotes transparency and provides a system of checks and balances, ensuring fair judgment and decision-making within the Astar Governance system. If the proposer’s challenge is successful, the Steward who initially flagged the proposal as spam will have their operational bounty slashed.

Voting Process

Individual users and dApp stakers receive their govASTR allocation, which they delegate to dApps or community contributors. Based on delegation, govASTR for each participant is calculated. Every governance epoch (10 days) consists of two phases - the Voting and Cooldown periods.

Voting Period (7 days)

During the Voting period, voters are shown a maximum of five active governance proposals selected from the queue. The participants have limited expendable voting power and are expected to vote for the proposals they believe are most important to the ecosystem’s future growth. One govASTR token can only be used to vote for one of the five proposals and is considered spent once the vote is cast. Out of the five proposals, at most, only one proposal can pass in that epoch.

If a proposal fails to meet the minimum voting share, it will be discarded from the batch due to low community interest. A few parameters must be defined system-wide to make this process deterministic and mitigate risk.

Minimum Quorum to Pass Proposal

This is used to filter which proposal is most interesting to the community. In cases where the community is divided, and participation across each proposal is within a few percentage points of each other, we want the majority of the community to prioritize one proposal for voting in the next epoch.

For example, if all five proposals receive 20±2% of total votes, we shouldn’t clear the proposal with the highest vote share as the interest level is approximately the same.

We propose setting this parameter to 32% (of votes cast) initially

Minimum vote share to carry pending proposal forward

As mentioned earlier, to make the governance process fast-paced, we should discard proposals that do not garner any attention (positive or negative) from the voters. We can establish a minimum vote share required to carry pending proposals into the next voting period.

We propose setting this parameter conservatively initially to 4%. Our assumption and belief is that any meaningful proposal should be able to garner 4% of the votes cast in a period. Treasury proposals skipped out from the queue due to inactivity are not subject to a slashing of the bonded amount.

An example of how the voting epochs would facilitate clearing and discarding of proposals is displayed below

Minimum Quorum for Epoch

Both the parameters we’ve defined before are based on the % of cast votes in the voting period. But we need a minimum number of votes to be cast in the first place to abide by the decisions made in earlier steps. For example, Suppose the votes cast are less than 10% of govASTR issued in an epoch. In that case, we shouldn’t clear proposals based on such minimal voting participation as the decision doesn’t reflect the opinions of the entire community.

We suggest implementing a 20% of govASTR minted (i.e., 200,000) in an epoch as a minimum quorum for a successful epoch and abiding by the decisions taken through the process explained above.

Cooldown Period (3 days)

Once the voting period is over, the evaluation and setup processes occur. Proposals from the batch are cleared, dismissed, or carried forward. The q-score is generated for proposals in the queue, and the selected proposals are transferred from the queue to the batch. The snapshot for dApp staking is taken, and users are offered a time slot to make any changes in delegation if they wish to hand over their govASTR to another dApp or community member.

Stewards are also expected to filter spam in the queue during this period. In short, any changes to the Astar Governance process are made during the cooldown period, and the voting period only focuses on the current batch of proposals.

Conviction in Voting

The conviction model must differ from other network governance because govASTR does not have monetary value or a significant opportunity cost outside its intended use. The Astar Governance process doesn’t allow voting dApps to display conviction like Polkadot governance. But the system does allow dApps to display fractional conviction and, to some extent, leverage conviction in the batch of proposals.

  1. Fractional conviction: dApps can use only a portion of their voting govASTR tokens to vote on specific proposals. Thus, voters can express any conviction for a proposal in the range [0,1]. This can happen due to multiple situations
    1. dApp wishes to vote on various proposals this epoch or;
    2. dApp conserves some voting power that can be utilized in the upcoming epoch.
  2. Leveraged conviction: A portion of the votes unused in the previous epoch are carried forward to the next. This allows dApps to combine the unutilized governance power of the prior epoch with the governance power allocated in this epoch to signal >1 conviction for a particular proposal if they wish.

This leverage conviction brings with itself a risk that dApps might try to hoard governance power across epochs to get some malicious proposal passed in a future epoch. To counter this risk, we suggest two mechanisms:

  1. Decaying voting power: Voting power carried from 1 epoch to the next undergoes a halving power. So any dApp trying to hoard voting power will get diluted as the next epochs progress, and in the extreme most case, a dApp can collect 2x the max voting power issued (i.e., 160k govASTR)

  2. Queue Randomisation: Hoarding voting power has low returns as no dApp can deterministically predict when their proposal is moved from the queue to the voting batch.

    For example, suppose the dApp starts hoarding voting power now, and their proposal is accepted into the batch three epochs. This forgone govASTR from the present epoch only provides 1/8th of its original voting power.

Combined, these mechanisms nudge governance participants to spend their govASTR on proposals live in the present batch instead of hoarding govASTR

The Governance Treasury

Every decentralized network governance operates because the community-managed treasury acts as the fuel. The mechanism in which the treasury operates must accommodate the network’s expected use case and vision. Therefore, the Astar Governance will show a slightly different approach to the treasury’s operation. The submitted governance proposals can be of various types, but some of the most important proposals will include funding from the treasury.

We present the following system, which can be implemented specifically to manage treasury funds via governance. It starts by creating smaller sub-treasuries with specified purposes and makes the management of the larger corpus of funds more manageable.

Subtreasury Creation

The Astar Governance system allows for the creation of sub-treasuries. These are smaller, more specific funds within the main treasury. Each sub-treasury is dedicated to a particular aspect of the network, such as development, research, or community initiatives.

The council plays a crucial role in the creation of these sub-treasuries. A council member is required to review & co-author the initial creation and funding proposals for new sub-treasuries. The council also oversees the funding and operation of these sub-treasuries, ensuring they are used effectively and whether they help achieve their intended purpose. One creation of the sub-treasuries, proposers can request funds for contributions pertaining to the goal of the sub-treasury category.

Bounty Spending

Sub-treasuries allow proposals to be made for allocating a portion of the sub-treasury budget to provide necessary products or services that benefit the ecosystem. We refer to these treasury spending proposals as bounties. The bounty process aims to delegate the monitoring and evaluation of spending proposals to experts called Curators. Council members can also act as curators in categories that fall under their experience and expertise, monitoring the performance of bounty collectors.

We recommend adding a mechanism to release bounty funds to ensure gradual ongoing commitment. A council member/curator can lock further fund releases if bounty collectors fail to perform their duties. During this lockdown, the community can vote to cancel the ongoing bounty stream or allow the funding payments to continue. We also suggest requiring the Bounty collector to provide timely progress reports in an open repository accessible to all community members (a Notion template can be shared).

The proposer can submit a bounty proposal for governance approval, with a curator later defined (likely a council member with expertise in determining when the bounty task is complete). The council can select additional curators if the current members lack the required expertise.

Slashing for Treasury Proposals?

If proposals have made it to the voting phase, they have passed the spam filtration process of Astar Governance. One goal is to ensure bounty proposers ask for the necessary funds and do not inflate the required funding. To do so, we use a simple mechanism of bonding up n% of funding that can be subject to slashing if a sizeable majority rejects the proposal.

The bond amount can be posted in ASTR tokens or stablecoins. The slashing conditions for the bond amount can be programmed as follows:

Bounty proposal (Voting ratio) Slashed Amount
Yes > 40% 0
40% > Yes > 25% 10% of the bond amount
25% > Yes > 10% 50% of the bond amount
Yes < 10% Full bond amount

We must keep the bond amount affordable so smaller projects/teams can participate. If we implement a flat bonding rate across all proposals, funding large and ambitious projects will become prohibitive. The Astar Governance setup should support large initiatives. We suggest a tiered bonding program as below:

Treasury Funds Requested (TFR) Bond amount
<US$ 10,000 10%
US$10k < TFR < US$50k 1000$ + 7%*(TFR - 10k)
US$50k < TFR < US$100k 3800$ + 5%(TFR - 50k)
TFR > US$100k $6300

Ensuring Honest Behaviour from Council Members and Curators

Council members/Curators receive part of the operation budget for successful performance. The council member has locked up funds/rewards at any given time. Slashing these funds can penalize them if they act maliciously. However, they will receive their rewards and part of the bounty reward if they successfully get the proposer to complete the work.

For curators who are not council members but are needed for their expertise, existing council members can post/delegate the deposit on their behalf in exchange for a portion of the curator fees collected at the end of a successful bounty.

Curators should generally have a track record of the issues the bounty tries to resolve and be knowledgeable about the topics the bounty touches. These recommendations ensure an effective use of the mechanism. Payouts for bounties should be based on a milestone-based payout structure. Once the objectives are completed, assigning a payout address is delegated to the proposer’s address.

Recommendations for Initial Treasury Setup

We take some inspiration from the spending behavior observed in the Polkadot ecosystem and suggest making certain changes to accommodate Astar Network’s unique positioning. According to the revised Astar Network tokenomics, the treasury funds are accumulated as part of the 5% network inflation.

Based on the information we observed in the Polkadot and Kusama ecosystems, we suggest an initial breakdown of treasury spending via the creation of the following sub-treasuries:

  1. Protocol Development: covers any software development that is funded through the treasury (like the Astar Governance model)
  2. Outreach/Marketing: covers all Social activities, media productions, educational activities
  3. Infrastructure: includes recurring software and hardware costs incurred to operate the network and auxiliary services like block explorers
  4. Operations: Incentivising council members and governance stewards for their continuing contribution
  5. Business Development: funds allocated to attract new dApp categories and companies to the Astar Network ecosystem

Considering that the Astar Network is in the earlier stages of its growth as compared to the Polkadot network and the functions of the sub-treasuries defined above, we share an initial distribution of treasury funding with a buffer of 5% preserved for additional spending the network might need to fund:

Protocol Development Outreach/ Marketing Infrastructure Operations Business Development
28% 18% 23% 6% 20%

The numbers shared above look different from those of the Polkadot ecosystem, as these terms are defined differently between the two ecosystems. Couple that with the fact that Astar Network’s business development and outreach efforts must include incentives for attracting new dApps and projects.


This is the entirety of the Astar Governance model. The appendix contains more information and notes, so please check them. Furthermore, everything described in the Astar Governance will be natively implemented with the Astar Governance UI powered by Townhall.

Now, we would like to open the conversation to the community. Please write in the thread with any questions, concerns, or feedback. We want to fine-tune the model and get as much community engagement as possible for this monumental project and the start of the next phase for Astar Network before we open a formal treasury proposal for the community’s vote.


Appendix and Additional Notes

Modeling objective - 2

  • Conduct a comprehensive analysis of the different case scenarios for the governance system. Consider extreme scenarios such as maximum delegation, minimum delegation, and potential collusion among dApps receiving governance power. Assess the potential risks and vulnerabilities of the governance system under these scenarios.

Since we plan on implementing default delegate selection, we can expect the steady state voting power to be distributed like the Astar Network dApp staking distribution.

Ideal state: Maximum Delegation - Quadratic voting planned to be implemented within the govASTR mechanism incentivizes community speakers and participating dApps to move towards a system of maximum delegation. In such a situation, we will have n entities (dApps, foundation members, community contributors) who would all approximately hold an equivalent share of the govASTR tokens, leading to the most democratic decisions and outcomes through the governance process.

Risk vector: Minimum Delegation - We also consider the case of minimum delegation, where the potential stake is concentrated on one dApp or delegate. We can observe how our governance power caps and quadratic voting functions can accommodate these risks

  1. Suppose one dApp A acquires 40% (400000) of the stake delegation. In an extreme scenario where the remaining 60% (600000) voting power is just held by 20 additional dApps equally (vote distribution is likely to be divided further to accommodate 75+ members from the dApp staking and community delegates for govASTR)
    1. govASTR held by A: 632.45
    2. govASTR held by 20 others dApps individually: 173.205

In such a scenario, 4 of the 20 minority dApps can coordinate and overrule a malicious proposal submitted in favor of dApp A. In a linear voting system, we would require the coordination of 15 minority dApps to achieve a similar result. As the reader will notice, the larger the set of delegates, the more robust the system becomes to stake centralization attacks.

Per epoch, the cap is introduced as the 2nd layer of defense against stake centralization. In the previous example, dApp A could still hold 36% of the govASTR allocation for that epoch. We introduce a cap of 8% of govASTR issued per dApp per epoch to incentivize stake distribution further. It would be in the best interest of dApp A to share their delegation with community advocates and partner apps that believe in a similar future to the Astar Network ecosystem

Modeling objective - 3

  • Define the roles and responsibilities of the council and govASTR delegates and establish the general governance framework. Clearly articulate each entity’s functions and decision-making processes to ensure effective governance.


Selection of Council: The initial selection of the council will be based on currently active contributing organizations involved in the Astar Governance forum. Later, for a vacancy in the council, an active governance participant can propose to join, subject to selection by voters.

Change in Council members

  1. Forced Exit: A proposal can be floated by community members to discuss the removal of an existing council member
  2. Resignation from Council: Existing council members can choose to resign from the role of council member by informing the broader community and launching the proposal for the election of a new member.

Role of the council

  1. Selection of governance stewards and monitoring of their performance
  2. Help in the creation of sub-treasury categories and provide direction to the treasury management plans of the Astar network
  3. Act as curators for major bounty proposals or help elect relevant curators for bounty spends
  4. Dispute resolvers in case of spam filtering disputes between governance stewards and proposal creators


Having a set of Governance stewards reduces the risk of shutting down such crucial proposals if spam prevention power was also handed out to council members

Modeling objective - 4

  • Simulate the impact of different locking periods for govASTR on governance votes. Evaluate the effects of locking periods such as one-third, one-half, and the full burning period on the voting power and decision-making capacity of govASTR holders.

While discussing the process of joining the Astar Network dApp staking to the govASTR issuance, we realized that locking up governance power is not feasible unless we enforce a similar locking period for dApp staking, which seems infeasible and would require significant changes to the current dApp staking module.

The initial idea was to add locking periods to the govASTR process by incorporating conviction voting. Conviction voting is included in the broader Polkadot ecosystem. We propose an alternative method for conviction in the entire range [0,1] and leveraged conviction by spending on previously unspent voting power. We present an analysis of the governance proposals in the Polkadot/Kusama ecosystems and the usage of conviction in proposals to support our suggestion of eliminating higher conviction voting from Astar Governance.

Modeling objective - 5

  • Explore and simulate various scenarios to determine the ideal slashing and bonding rates for proposals related to the treasury. Analyze the potential trade-offs and benefits of different strategies to establish a participative governance setup and avoid an overflow of proposals monitoring.

Slashing in the current govASTR proposal can happen at 2 points in time:

  1. If the proposal is deemed to be spam, the proposal
  2. If a treasury/ project funding proposal fails with a sizable majority

For spam prevention, the council elects governance stewards whose role will be to observe proposals in the queue and discard proposals aimed towards spamming the queue or repetitive proposals to increase the probability of getting picked up in the next voting epoch. The suggestions for parameter selection have been shared previously in the bounty spending and Queue - spam prevention sections.

Modeling objective - 6

  • Identify and propose potential mechanisms and options dApps can leverage to increase their stake and voting power. Explore strategies such as partnerships, collaborations, or initiatives that enable dApps to enhance their influence within the governance ecosystem.

The govASTR system presented has been suggested to maximize the distribution of voting power across multiple network stakeholders. The system actively disincentivizes large dApps, which receive the lion’s share of dApp staking delegation, to accumulate govASTR voting power. It is best to delegate additional voting power to like-minded individual delegates or smaller dApps.

Modelling objective - 7

  • Develop a comprehensive model for treasury spend and budgeting specific to sub-treasury. Design an effective framework that outlines allocating funds and resources to sub-treasury based on their respective needs, priorities, and contributions to the overall governance ecosystem.

We shared a version of this in the treasury section covered above.

Simulations and Additional Materials

Most models simulated here used Excel and a Python script to keep things simple. You can find them here for you to play around:

For any more simulations or details, please let us know.


Thank you for your detailed post as before. Frankly, I think there are many aspects of governance that we will not know until we try it, but it seems to me that there are no particular problems with the content at this point.

One point I have wondered about is with regard to the redelegation. I understand that there is a cap on delegations so that voting power is not overly skewed, and that any excess delegations can be re-delegated.
By recommissioning to another own account or to a fellow member, it seems to me that this would effectively be the same as having no limit. If so, it seems to me that it would be better not to be able to delegate more than the limit.


Thanks for all the specifications and details! It’s exciting to see this laid out like this. It’s very throughly constructed and aspects of governance I hadn’t even thought of were considered. Specifically the “Proposal Queue System”. Im just nitpicking here but I do openly wonder if 5 is a number that should be flexible or relative to the size of the treasury. The assumption I have is that if a treasury is bigger, it may attract more teams/users and therefore higher rate of proposals, and vice versa.

Also, has consideration been taken on the roll out of these specifications? As in breaking these builds into phases and in that way educate the users as its grows/integrates new aspects of governance. The whole system may be consider complex due to the number of moving parts so building it out (or activating) different aspects slowly. I’d imagine it would have to be grouped into parts that aren’t dependent of one another. I understand that the queue may not be dependent on the govASTR token for example.

So it can be seens as upgrades to the townhall to make it more robust over time, allowing for careful utilization from the community and also adjusting for next phase as team receives feedback from usage (proposals, voting, queue, sub treasuries, etc.).

I agree with You, we won’t know until we try it. Can certain aspects/phases be built on Shiden first and tested with the Ecosystem Agents on a small scale?


Based on the interactions on this post, I think it should be better to showcase this governance model to the Astar community.

Instead of just proposing, you should test it on Shiden and show to Astar community how it works. You can apply to the Shiden treasury for building out the PoC.


Thanks for elaborating this post! I agree with @Maarten.
Maybe a video explanation could get more community engagement and participation.

Thank you for the excellent suggestion.
I tried using TownHall right away. The UI/UX was good and easy to use. In particular, I think the “Ai Summary” is a tool that many users have been seeking.

I support this proposal. If this governance model is tested in Shiden, I will actively participate, deepen my understanding, and work as an Agent to permeate it throughout the community.

Yes this is a risk we considered and think it can be mitigated in a few ways.

  1. A majority of governance power delegation will end up being delegated to the top 15-20 dApps in the governance process - all of whom are teams with sizable stake in success of the network. Expecting a limited probability of such a malicious action from them

  2. Our initial idea was that each organization/dApp gets one position in the governance process.
    But if individual community members apply to become delegates we need to ensure they aren’t tied up strongly to an existing delegate. And if it is someone who is a proxy for a existing dApp, then other dApps should vote against their selection. This would require delegate selection to happen via governance too after the initially onboarded set of delegates - dApp staking dApps + existing ambassadors.

  3. Also based on the community feedback of testing the proposal out on Shiden - we can explore limiting the delegating power beyond the cap as suggested by @you425

This variable of queue size can be upgraded beyond 5 subject a governance vote

Based on the comments from the ambassadors it seems like there is an interest in testing this framework out on Shiden. I’ll let @hoonkim comment about how we can go about building and testing this out on Shiden network


Thank you for the detailed posts Hoon, I’d expect nothing less from you :slightly_smiling_face:.

I went through the post(s), so please let me share a few observations & opinions.

Correct me if I’m wrong, but this is still the amount of ASTR tokens you have locked/staked. It has nothing to do with actual network activity. Alice stakes 1000 ASTR on 10 different dApps since she’s an engaged user/degen, and Bob stakes 10000000 ASTR on a single dApp, meaning Bob is “more active user”. He’s just a bigger token holder. :person_shrugging:

So I find this statement very misleading.

If I can keep the votes to myself, it essentially means I can distribute ASTR to various accounts, and bypass the calculation process which takes the quadratic root. For integers larger than minimum lock/stake amount, sqrt(n) < sqrt(n/2) + sqrt(n/2), n being the staked amount, and this becomes more true the more we split the staked amount between different accounts.

Maybe I’m misunderstanding something, so please correct me if I’m wrong.

Since ASTR is inflationary, this claim isn’t correct, right?

So each ~10 days, snapshot is taken and new governance tokens are distributed?

It’s strange, since the whole dApp staking system encourages keeping your stake throughout the entire dApp staking period. There’s already a strong economic force pushing towards status quo, at least within the same period.

Parallel with dApp Staking v3

You use terms like epochs, periods, voting periods here, which is fine in itself, but you also draw a lot from dApp staking which makes it confusing and unclear.

Epoch length is not aligned with dApp staking v3’s period lengths, or anything per say. Essentially, there’s no mention of cycles, periods, eras at all here. And given how the two systems are interconnected in your proposal, this gives me the impression that it’s not designed with understanding of how dApp staking systems works.

General Opinion

I do strongly agree that we need a proper governance system on Astar.

I do not believe that we need to completely reinvent the wheel.
There are systems that are battle tested, and with a few modifications can be made to work well in Astar. Developing a system from scratch, testing it, running simulations, educating users, etc. is incredibly costly, and requires tremendous effort from the involved parties.

We do not currently have high user engagement, and your proposal makes assumptions that in a sense we do. Polkadot has a big following, it’s unrealistic to compare Astar & Polkadot. Adjusting few numbers still doesn’t make comparison valid (this is of course, my opinion).

My vote is currently against this proposal due to the outlined issues in the approach (but feel free to correct me where I’m wrong), and my opinion from the few paragraphs above.

We need to get governance on Astar ASAP, and having a slightly modified/adjusted version of Polkadot Gov v1 & v2 would most likely do more than a good enough job to get started. Then, with such governance model, we can opt to transition to something like you propose here - after it gets approved on-chain to fund development, that is.


Thanks for your comments.

  1. Yes, that may be true, but then there is not much point in limiting voting power. And I think it is hard to imagine that a system that expects people to be good is going to work in the long run.

  2. This is a difficult point. I agree that if we are going to narrow down the choices of who to delegate to, we need to elect. I would have assumed that we could delegate to any account.

  3. Yes, I would like you to consider this. I believe it should be restricted by the system.

1 Like

I’ll let @hoonkim reply on some of the questions you have shared, but in the meantime, as one of the co-authors of the proposal, I’ll share my take on some of the questions posed.

Yes, in the initial implementation proposed, the network activity is purely measured based on dApp staking activity, i.e., how much a user has staked across dApps. However, this need not be the case throughout the governance program’s development.

If we can verifiably measure and use data points such as the number of transactions, transaction volumes, # of active days on-chain, then the scoring mechanism can be tweaked accordingly.

This idea is probably not being conveyed in the proposal accurately but the Idea with the new governance system comes from the understanding that participation from individual community members is not a suitable way to govern the ecosystem. Across the board - # of token holders the participation rate is 1-2%

So this model is very strongly inclined to drive stakers to delegate their voting power to dApps on the network (dApps staking dApps + other dApps meeting minimum activity thresholds + Ambassadors in the community + core team).

There is still the option to self-delegate, and the sybil attack you described is possible, but fundamentally taking the monetary power out from the token, i.e., using govASTR for governance, ensures that it’s not economically very beneficial to do so (As the user would need to split his wallets participating in the dApps staking process as well). Happy to share some more details/simulations on how we can expect voting power distribution to happen given the mechanisms shared in the proposal

The claim is correct. Every Epoch 1mn govASTR is freshly minted and for any unspent voting power from the previous epochs decays by factor of 2.

So the Max govASRT in circulation would be in the case of an epoch #infinity where no one has spent any voting power from epoch #1

The supply would be = 1mn (1 + 1/2 + 1/4 + …) = 2mn govASTR in this scenario

The governance process needs to happen over a fast-tracked timeline compared to the dApps staking “period” of one month. But at the same time, we want the delegates to be able to read through the proposal queue and make informed decisions. Thus, we think the 10-day period (the same as the voting period in dApps staking V3) functions well. I’m happy to hear any recommendations that you have for modifying it.

Fair criticism of the usage of the terminology. We went through the dApps staking V3 before crafting this proposal and can use different terminology to convey time in the governance process. I fundamentally think the 2 systems have a lot of differences to follow a common convention across the entire board.

The proposal aims to submit this system that can serve the unique set of goals outlined in the previous post and tackle some issues that Hoon and Polkassembly team have noticed in Astar and other Polkadot parachain ecosystems.


Thanks for your response.

Yes, introducing to the Shiden network isn’t hard from our side since it’s technically the same. We were thinking of maybe using Shiden as a sandboxed text environment for the governance functions (implemented off-chain using Townhall).

One concern I have is the lack of participation in Shiden at the moment. We can work on the integration, but without at least a handful of dedicated members who wish to be in the “council,” I don’t think this will be effective. We’ll integrate the governance and make an announcement in the ShidenDAO server.

1 Like

I’m sure you will find the team to be part of the council. Maybe try to reach out to DAO community to test and learn on Shiden about the governance that has been created. Using Shiden just as sandbox text with off-chain implementation is not really testing the full technical integration.

Let’s make Shiden a real ShidenDAO!

1 Like

I agree with the ShidenDAO idea, it will be interesting to try this new governance system and see a more active participation by discord members (including mine).
Do We have any estimated date for these implementations ? @hoonkim @daft

ShidenDAO for the win! Still belive this should be pursued in near future!

1 Like

I’ve always been a fan of Astar transitioning to a DAO model eventually. However, for the present, a simpler solution that facilitates quicker decision-making is necessary. While the Polkadot Open Gov system has its shortcomings, it could be a good starting point in my opinion.

Projects staking their tokens on Astar dApps already represent a form of community voting. Users have faith in the project and delegate their decision-making power. Perhaps incorporating this existing voting system along with input from a technical committee (like Fellowship) could be a viable mid-term solution