Polkadot Governance Framework - v2023.09

Abstract: This post describes a Polkadot Governance Framework, discusses direction setting, strategy & operationalization, and Collectives, and introduces a class of governance participants: Voter Committees

Introduction

Polkadot’s transition to OpenGov means that we need to establish an internal organization that leads to ecosystem success. As Parity is taking steps to disengage from its active leadership role and push the role of ecosystem development more toward other actors (aka decentralization), it is our responsibility to step up and shape Polkadot Governance.

Our biggest challenge in this environment is uncertainty. Governance is uncertainty about the right structures and processes to give itself. Participants are uncertain if their contributions are considered valuable and if they will be (properly) compensated. The source of this uncertainty is the relation between Polkadot Governance’s potential power to its ability to project it. Polkadot Governance has a lot of potential power given our collective aggregate IQ and Treasury reserves. At the same time, we cannot project this power efficiently, because we lack the structure and processes to do so. OpenGov today essentially is a soup of voters fighting a new fight every day.

Our job therefore is to reduce this uncertainty. How can we achieve this? By giving shape to Governance. Just like a little human learns to apply patterns to its perception of the world to construct reality, Polkadot Governance needs to apply differentiation to its internal organization. We need to delegate power into effective and efficient governmental structures.

The main part of this article is split into 3 chapters:

  1. Shapes of Governance - this chapter establishes basic concepts and terminologies to mentally frame governance and lead constructive discussions
  2. Collectives - this chapter briefs you on the current efforts in establishing SubDAOs that are referred to as Collectives in Polkadot lingo
  3. Voter Committees - this chapter introduces a class of governance participants. They are comparable to political parties in TradGov

Governance Framework

This chapter will present a series of assumptions that together form a governance framework. Each concept helps us reduce uncertainty by establishing common ground and terminology and advancing the discussion.

These concepts are not assumed to be absolute but rather presented as useful. If you disagree with them, I invite you to propose better concepts. Agreeing on these concepts will help us establish a shared mental framework and mode of operation.

A priori assumptions

  • Polkadot Governance is the highest governing body of the Polkadot relay chain, system chains, and DOT token. This concept assumes authority over the mentioned entities. If there is something wrong with them, it is ultimately Polkadot Governance that can be called to determine a solution. It also limits the power of Polkadot. It leaves the question undecided on how the remainder of the Polkadot ecosystem is being governed. Parachains have a certain degree of sovereignty that is partially limited by shared security, but this is a delicate question that cannot be trivially solved here.
  • Polkadot Governance is concerned about the positive development of the Polkadot ecosystem. While it cannot ultimately be responsible for the fate of the ecosystem as a whole, it has a lot of power to influence its course. As such, it takes proactive action to ensure the success of the eco.

Strategy

  • Polkadot Governance bases its work on a set of goals. Polkadot’s goals are the aggregate sum of the goals of its participants. While it will never be possible to capture these goals in their entirety, there will be commonly agreed-upon goals that will form the basis under which further work is considered. Goals are also referred to as objectives.
  • Governance develops a strategy to achieve its goals. Governance is limited in resources and follows specific goals. Out of these two facts, it follows that it needs to agree on a strategy: The course of action that has the highest likelihood of leading to success. Since “strategy” is a big word and is not always followed up by the level of sophistication we ascribe to the word, we can also refer to this as direction or scope.
  • Strategy is developed through artifacts like forum posts and discussions like AAG. Strategy is a flexible thing that develops as new facts are learned and the macro and meta develop. It is a continual and ongoing process of discussion and agreement. In its current state, I think it is unlikely that strategy will be agreed upon through hard on-chain voting, as it would require that all stakeholders that vote on on-chain decisions will also vote on off-chain social agreements. Unlikely.
  • Fragmentation is okay. There will never be perfect unity. There will always be disagreement. Don’t assume that just because there is discord and conflict there is not also agreement. Everything that is agreed upon is not discussed. (e.g. do we think that blockchain is good? Yes, that’s why we do it. Discussion closed). We will always disagree on the decisions that have not yet been made. This is why we have political parties in developed democracies.
  • Outcomes are important. Eventually Polkadot needs to be successful in leading the transformation towards Web3. Strategies are there to be realized and collect wins, so overall our efforts need to reach their defined outcomes. Some actions are directly measurable towards the realization of outcomes, others are more abstract and indirect. We need to find the right balance between enforcing short-term measurable KPIs and giving space for long-term research and development to achieve lasting success.

Operations

  • Strategy is implemented through initiatives, projects, and programs. We take specific action to achieve strategic goals. This specific action is best implemented via one of the following:
    • Initiatives: Broad efforts aimed at achieving strategic objectives. Flexible, interdisciplinary. Example: Improve Developer Experience
    • Projects: Well-defined efforts with specific objectives, scope, start, and end date. Defined approach. Tangible and quantifiable outcomes. Example: Nova Spektr Milestone 3
    • Programs: A collection of related projects and initiatives aligned with (multiple) strategic objectives. Long-term or ongoing. Example: Ongoing RPC infrastructure operations
  • Responsibility to implement is given to individual actors or to Collectives. This introduces a separation into two classes of actors
    • Individuals: These are on-chain users proposing or applying for a bounty reward or tip. They are more likely to apply for simple projects and carry responsibility limited only to that project.
    • Collectives: On-chain entities instituted with a defined charter. They are more likely to lead initiatives and programs. They carry broader responsibilities as defined by their charter or as delegated by governance.
  • The Treasury allocates budgets to implement the strategy. A lot can be said here. For a detailed discussion, refer to this post: Towards a Treasury Budget.

Collectives

A collective is a group of people that work on a common agenda and get paid for it by the chain. They can have different responsibilities that are differentiated either by vertical (development, operations, media, data, security…) or horizontal (inter-disciplinary teams focused on achieving certain goals) domains.

A bit more formal: Collectives are on-chain entities that have a charter, membership system with ranks, and optional payroll. They have been first described in the Polkadot context by @joepetrowski in Collective-based, multi-asset Treasuries. RFC 12 is currently open in the fellowship Github and describes the process of instituting a collective.

Some existing and potential future Collectives:

The basic concept is also referred to as subDAOs by dYdX and Core Units in MakerDAO. Some relevant reading if you want to learn from other protocols is the dYdX DAO Playbook, and MakerDAO Core Units (MIP38, MIP39, MIP40, MIP41, Expenses)

Collectives will be approved via the OpenGov Root track and will get a custom implementation of their membership logic and payment on the Collectives system chain. From what I see in the codebase, they will have a maximum budget per cycle and support individual claims per member.

Voter Committees

I am introducing this name as the class of governance participants since we already see this shaping up in Polkadot. We borrow the definition from MakerDAO MIP101:

Voter Committees are groups of MKR holders that publicly coordinate to analyze the best voting behavior based on a particular strategy, and publicly coordinate political positioning with other Voter Committees and voting blocs to reach compromises and middle grounds that minimize bad decisions. The base form of Voter Committees are the Permissionless Voter Committees which is a very simple designation for any kind of organized voting group.

Aligned Voter Committees are a special type of voter committees that work in public and are subject to certain rules, in exchange for receiving resources and support. To see it in action, see this page of MakerDAO AVCs.

ChaosDAO is the first publicly outed voter committee in Polkadot. They receive delegations to an automated account that votes according to a Discord internal vote where one person has one vote and the bot votes aligned with the internal result. The bot was funded by the Kusama Treasury in Referentum 243 and is available as open-source on Github.

I am aware of other groups that intend to form voting blocs and it is commonly acknowledged that there are non-public voter committees that coordinate to vote.

Consensus is best achieved by having such committees discuss in the open. We should strive to find ways to encourage open dialogue and move from voter committees to aligned voter committees.

Conclusion

This article presented a governance framework that can be used as a shared mental model. I invite discussions that seek to improve the model. Going forward, I will base my assumption on this model and will refer to it when needed. I invite you to do the same. Collectives and Voter Committees are two classes of governance participants that we should refer to in discussions. We should facilitate the formation of Collectives to drive governance forward. And we should start pointing out voter committees when we spot them and invite them to an open dialogue.

Some ideas for future work include:

  • Move forward discussions on what shared goals of Polkadot Governance are
  • Analyze past initiatives, programs, and projects and understand where Treasury priorities have been in the past.
  • Formulate Initiatives and Programs based on a shared understanding of goals
  • Propose budgets based on initiatives and programs
  • Support Collective formation

Share this post on Twitter: https://twitter.com/alice_und_bob/status/1703833748121215296

7 Likes

No. This post is not about Polkadot. It is about Polkadot Governance and gives a clear (enough) definition of its scope in the apriori definitions. Whenever I say “Polkadot” or “we” in a not-clearly-specified way, it is intended to give you a warm fuzzy feeling in your belly. This feeling does not need a definition.

This discussion needs to get more specific, not more abstract. We will not derail it with meta-discussions. It’s time to get to work.

1 Like

i disagree, there are stages missing here which will result in wasted time, but as you wish.

1 Like

I completely agree with your points and observations as they are right on point. I would like to add that we can find valuable inspiration in way the Web3 Foundation (W3F) grant team operates and interacts with the grant applications. It can be a good example of how a defined and approved strategy can be implemented.

  1. Strategy: Polkadot Gov identifies the strategic goals where one of the goals is i.e. to improve developer experience,

  2. Request for Proposals (RFPs) : Based on the identified goals, Collective takes over responsibility and issues Request for Proposals (RFPs). These RFPs should clearly define the objectives, expected outcomes, and any specific requirements for each strategic goal. For instance, if the goal is to improve developer experience, the RFP might seek proposals for tools, documentation, or educational content. RFPs come with the certain limits, like budget, time, number of approved projects,…

  3. Project Submissions : Community members can submit their project proposals in response to the RFPs. These proposals should detail their approach, timelines, and budgets required to achieve the specified goal. Proposals should be well-defined in order to be properly evaluated.

  4. Project Approval : Once the Collective and Voting Committee completes its evaluation, selected proposals are approved. These approved projects are then incorporated into the strategic roadmap.

  5. Resources Allocation : Allocate resources to fund the approved projects. This ensures that the projects have the necessary financial support to succeed and removes uncertainty if the contracted work will be compensated.

  6. Completion and Evaluation : Upon project completion, evaluate the outcomes against the initial goals and criteria set in the RFPs. This evaluation helps in understanding the impact and effectiveness of the executed projects.

To use a metaphor, the Treasury is currently like a shopper in a huge supermarket, throwing whatever catches their eye into the cart. But by creating a clear shopping list (Strategy - RFPs), the Treasury can make sure that the cart is filled with exactly what is needed for a great meal, instead of random stuff from the store.

3 Likes