I will add another component to the Astar governance.
Please note that this is a draft proposal that I am using for a public discussion, meaning that everything written here is subject to change and should be discussed.
Astar Treasury
On-chain treasury is one of the main factors that drive governance engagement and fuel network contribution. However, because it is the heart of an organization, we must carefully understand how the money should circulate and the core objective for spending the treasury money.
I will use the Polkadot treasury as the base reference for this thesis, but certain components were referenced from other treasury models.
Problem Statement and Vision
System-embedded treasuries like Polkadot have a robust mechanism for accumulating treasury funds. Like Polkadot, Astar will also incorporate mechanisms such as the fee percentage, slashed rewards, and chain inflation to be sent to the treasury.
However, the real issue is with the allocation mechanism (i.e., who can propose and be eligible for the treasury amount). Most on-chain governance use an open proposal system where anyone with the right criteria can open a treasury proposal, and those with voting rights can vote aye or nay on the matter. In the case of Polkadot, the council will act as the guardian for the treasury, though this will change in OpenGov. But in general, this type of model leads to treasury bleeding, lack of transparency,
In Astar Network, we want to create a treasury model that satisfies the following:
- Treasury funds should be allocated only for projects and ideas contributing to the network regarding technology, education, marketing, ecosystem, and anything else that leads to the network’s growth.
- All proposals should have a clear plan, timeline, KPI, motivation, driving person, required resources, and risk factors that could affect the above.
- The treasury should enable innovators, executors, leaders, or people who ship to focus on their work without financial concerns.
- The treasury must have clear regulatory guidelines and support (such as invoices or other documents) so that all participants won’t face any potential legal issues when supporting the network.
- People who are qualified and engaged in the topic should handle the funding assessment, not the council or a few with a lot of voting power.
My Proposed Treasury Mechanism
For Astar Governance treasury, after long discussions and research, I propose that we maximize the bounty system introduced by the Polkadot governance model and create a “sub-treasury” that is funded by the main treasury.
This system will have more bureaucracy but stability, security, and better delegation, allowing the governance participants to stay focused.
Treasury Types
In Astar Governance, there will be two types of treasuries: the federal and the sub-treasury (bounty).
The federal treasury will act as the core source of funds for the network that is directly integrated into the protocol so that the funds can accumulate or be burnt based on our token economics. The council will act as the guardian of the federal treasury, and the funds here will not be distributed directly to an account. Instead, it can only be allocated to sub-treasuries.
The sub-treasury is a purpose-specific pool of funds meant to be distributed directly to users and projects who satisfy the criteria set by the sub-treasury owners (curators). Only the federal treasury can fund the sub-treasury, and they will impose a maximum budget. The curators will act as the guardians for the sub-treasury, and they have the responsibility to provide all information regarding the spending, purpose/objectives, progress, and other information about the operation to the council if they wish to extend their budget. The curators will have a regular payroll, and their contributions will be treated as part of the budget. The council will have the right to cut all budgets if the sub-treasury curators are not transparent or compliant.
This is a system where the network treasury is made to create common-good sub-Governances for specific matters and open up the scope of the contribution to any direction that the governance participants agree to vote on.
Note that the normal voters (governance token holders) will have a saying on all the matters above, so if the majority of voters disagree with the sub-treasury or federal treasury spending, they can always vote to disapprove the spending.
Making a Treasury Proposal and voting
It might look complicated because I listed all the features, but looking at the system in isolation should give us a better idea of how it should function.
Any ASTR token holders can open a proposal to create a new sub-treasury and become a curator by locking their tokens. The proposal should always be in a mid-long term high-level scope (quarterly reports and milestones that last for years), and it must contain the following information:
- Sub-treasury name
- Purpose, vision, value proposition, and any other information that can help the voters understand why having funding for this category adds value to the network.
- List of curators (owners) and their qualifications for driving the sub-treasury.
- The network KPI that the curators will track and report.
- Scope and milestones of the sub-treasury.
- Project (proposal) acceptance criteria.
- Required budget
- The cost breakdown for curator payrolls (if the curator wishes to receive payrolls.
- Existing potential proposals that will benefit from this sub-treasury upon creation.
- And other information that the voters request.
For example, a community member wants to hold a regional small Astar meet-up, but no sub-treasury can finance this. Then they must campaign to gather potential curators and supporters interested in creating a sub-treasury proposal with a payroll. Once a proper curator with a good proposal has been set, they can propose to the federal treasury, where the council and the governance token holders will vote. Once the sub-treasury has been made, any future community projects and initiatives meeting the sub-treasury’s acceptance criteria can easily open a treasury request and receive funds like they would in other governance platforms.
If the sub-treasury needs more funds, it can request a budget extension from the federal treasury with useful information that describes why they need an extension.
Any votes going to the federal treasury must have at least one approval and no disapproval from the council. In case of a disagreement, the proposal will always require the majority council’s approval for it to pass or be vetoed.
A similar model will be applied to the sub-treasury. But instead of the council’s approval, any proposal will need the curator’s approval.
The scope of the sub-treasury can be broad or specific, and it can always evolve. For example, we can start with an education-focused sub-treaty that funds hackathons, documentation, and online courses. But the hackathon scene has become more prominent and needs more funding. In that case, we can create a separate sub-treasury focusing on funding hackathons and remove hackathons from the scope of the original sub-treasury.
Potential Issues and Corner Cases
- Conflict of interest: Someone wants to create a project proposal, but there is no sub-treasury to submit their funding request, so they must create a sub-treasury before anything else. Suppose the original proposer is also a curator (with a payroll) and the beneficiary for the sub-treasury proposal. In that case, a possible conflict of interest will come into question, and the proposer must be able to explain how they can handle this. There will be no systematic check for this, which must be resolved at the human level through discussion and public forums. You can also argue that having a single party go through the process forces them to be transparent with their contributions since all proposals and budgets must be online.
- Voting disagreement: If one or more council votes no, we will check for a simple majority vote among the council members. If the governance token holders overwhelmingly vote no and one of the council votes yes, the council can come together to vote for a veto (requires a majority council approval). But with no veto, the proposal will honor the governance token holders’ vote and not pass the proposal. However, the same will not happen if the council votes no, but the governance token holders vote yes. In this case, the proposal will only pass if the majority council votes yes.
- Bootstrapping: This system was made with scalability in mind in case there were a lot of treasury requests with little to no policing. However, this is not a problem in the early governance stage, and the added bureaucracy may only act as an unnecessary blocker and overhead for operations. So for the initial governance stage, we need a well-organized and engaged team (individuals affiliated with the council team, ambassadors, members from Astar Foundation, Startale Labs, Team STEP, etc.) to get the system working. However, the system is inherently open for anyone to create a new sub-treasury as they see fit, so we expect the community to slowly take away part of the scope for the initial sub-treasuries into its dedicated curators with funding.
- Centralization: Because this system introduces a clear hierarchy of votes (minus the governance token holders), it can become a source of centralization. Astar Network will prioritize functionality over decentralization, but too much centralization will become a risk factor for the network. To address this issue, we allow the governance token holders (i.e., the dApp ecosystem) to always have a saying that can affect the council or the curators. This means the system will only be decentralized if the ecosystem projects are decentralized.
- Funding estimation: Sub-treasuries are not a single project but a mid-to-long-term objective to accelerate the network growth. Meaning that the curators proposing to create a sub-treasury cannot have an accurate budget estimation. Instead, the council and the voters should estimate how much they are willing to fund and support the broader initiative. So it must be a top-down approach and trust in the curators, not the project.