This post summarizes how signal voting through Wish-For-Change Referenda (WFCs) is used as a legislative tactic in Polkadot OpenGov. We provide suggestions about how to use the method effectively and strategically. In the closing part of the post, we provide a structured overview of all current WFC legislation in OpenGov.
Signal Voting Shapes Governance
The “Wish For Change” track is a non-executing track in OpenGov. It does not do anything on-chain. The only effect it has is to allow token holders to express an opinion about a certain piece of text. The opinion is expressed through the number of AYE and NAY votes the ref receives.
Below you can find a list of all “executed” (more AYE than NAY votes) WFC proposals, sorted by the number of most AYEs:
Let’s look at some examples:
- 747 - Polkadot 2.0 Definition summarized a long-running community discussion about what Polkadot 2.0 is and provided a definition. 69 m AYEs accepted this definition. However, the ref was also somewhat contentious with 21m NAYS (==77% approval rate). To date, it is the WFC with the most votes.
- This proposal is mostly communicative. It does not affect development processes (as it was based on an existing tech agenda). As such, it only shapes how people talk about Polkadot 2.0 and how it is reflected in the broader perception.
- 712 - Implement Optimistic Project Funding tested the willingness of OpenGov to support the development and implementation of a new funding mechanism for projects in OpenGov. It was accepted with a 99.9% approval rate.
- This proposal shows that future tech development can be informed by signal voting. If the vote had been very contentious, proposers would have had to return to the drawing board and rethink their solution. In this case, 99% approval signaled that token holders are supportive of the idea and might continue to support it in the future.
- A currently ongoing example are refs 1137, 1138, and 1139, which test out different options about the future inflation parameters
- This proposal shows that we can test different options and be creative with the usage of signal voting. By combining several signal voting refs, we can test different opinions against each other.
What we can see from these examples is that signal voting has already positively influenced the ability of the DAO to coordinate action through soft consensus.
Consensus is Key
While token holder strength is relevant, it is not the only deciding criterion. In 959 - Direction of marketing strategy, 99% of the AYE votes come from a single voter, indicating that there is no consensus on this strategy, only a token majority on the vote; two very different things.
The paradoxical thing about signal voting is that it contains a simple majority voting mechanism, but this vote is not the most important thing about it. We have to understand the bigger context: Signal voting is a tactic in a consensus-building strategy.
The DAO wants to come to a common understanding of its intended future path. Stakeholders want to understand how other stakeholders think. It is a conversation.
As such, signal voting is most effective when considered in the context of organizing larger-scale discussions in a decentralized setting. Seeking consensus is about having conversations and developing concepts that can achieve widespread acceptance. Typically this involves fleshing out an idea into a proper text and talking about it with the community before putting it to vote.
How to use WFCs effectively
Signal voting can be used long-term to establish standards and norms, set direction, test opinions, and more. As such, it is an ongoing negotiation about the path of the DAO. The crucial point is that it is not about the simple positive or negative outcome of a vote, but rather the number of AYE votes, the approval rate, and the number of people involved. These are essential metrics to understand how much consensus there really is on an idea.
Some ideas:
- define accountability standards for referenda, bounties, collectives
- direct responsibilities over certain executive matters to certain bounties/collectives
- test out strategic direction concepts
- define the broader structure of OpenGov
- announcing a political agenda and testing support
Current Legislation
We believe that over time, the aggregate of all proposals could form our Governance framework. As a closing example, we have summarized all currently accepted proposals, shaping the current legislation.
Roadmap
- Polkadot 2.0 is defined as async backing, agile coretime, and elastic scaling. (747, 69m AYEs, 77% approval)
- JAM ratification, conformance, and performance testing to be done by the Fellowship (682, 31m AYEs)
Spending
- Optimistic Project Funding: Users can vote on the distribution of a constant stream of funds to participating projects (712, 56m AYEs)
- Reducing spending periods of the spend_local extrinsic from 28 to 7 days (705, 56m AYEs)
Collectives
- EVM Collective (704, 53m AYEs)
- Polkadot Tooling Collective (932, 45m AYEs)
- Ambassador Program (487, 32m AYEs)
Polkadot Plaza
- AssetHub should allow EVM-compatible contracts (885, 55m AYEs)
- Plaza should not be referred to as plaza. It should be called Polkadot (966, 52m AYEs, 80% approval)
- Plaza integrations shall fall under the scope of the DeFi bounty (967, 33m AYEs, 67% approval)
Marketing
- Include in Marketing narratives
- Exclude Astar from Marketing narratives (937, 48m AYEs, 57% approval)
- Marketing should focus on creating awareness for end users (959, 29m AYEs, 64% approval)
Business Development
- Pilot MOU for a Collaboration between Polkadot and the Founder Institute (755, 43m AYEs)