Preface
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.
Abstract
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:
- Minimise end-user friction to participate in governance
- Transfer governance power to the network’s most aligned stakeholders - dApps, ambassadors, and other contributors
- 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:
- The ASTR token price affects the treasury size as most of the treasury is held in ASTR tokens;
- The treasury is spent every quarter and is being replenished regularly due to inflation rewards diverted to the treasury (5% of inflation);
- 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;
- 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).
Where,
- 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.
- 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
- dApp wishes to vote on various proposals this epoch or;
- dApp conserves some voting power that can be utilized in the upcoming epoch.
- 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:
-
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)
-
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:
- Protocol Development: covers any software development that is funded through the treasury (like the Astar Governance model)
- Outreach/Marketing: covers all Social activities, media productions, educational activities
- Infrastructure: includes recurring software and hardware costs incurred to operate the network and auxiliary services like block explorers
- Operations: Incentivising council members and governance stewards for their continuing contribution
- 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.
Closing
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.