forked from airalab/robonomics-wiki
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathRobonomics OpenGov Wiki
147 lines (77 loc) · 16.8 KB
/
Robonomics OpenGov Wiki
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
# Robonomics OpenGov
## Introduction
Robonomics has shifted the parachain's governance model to Polkadot's sophisticated OpenGov mechanism that allows the chain to evolve over time, at the ultimate behest of the token holders.
Robonomics' transition to OpenGov ensures that the token holder DAO, which control the majority of the stake, can always command the direction of the Robonomics parachain.
*Note: OpenGov is only applicable to the Robonomics Parachain which is a Substrate based chain connected to the Kusama Relay Chain. OpenGov is not applicable for the Robonomics Ethereum implementation, as Ethereum does not support sophisticated governance systems such as OpenGov*
OpenGov changes how the day-to-day operations and decision making are carried out on the parachain. It provides greater clarity as to the scope of referendums and has the potential to dramatically increase the throughput of decisions that are made on the parachain.
OpenGov has been live on the Kusama relay chain for a few months at the time of writing, and has proven that it dramatically increases the number of decisions (referenda) that the token holder DAO can propose, vote on, and ultimately control the direction of the protocol.
**The following content in this article will go over the core principles of OpenGov on the Robonomics parachain and aims to help you better understand the concepts behind OpenGov.**
*It is important to note that governance is a constantly evolving mechanism in the protocol, especially at the early stages of implementation.*
## About Referenda
Referenda are simple, inclusive, and stake-based voting schemes. Each referendum has a specific proposal associated with it that takes the form of a privileged function call in the chains' runtime. This can also include the most powerful call `set_code`, which has the ability to switch out the entire code of the chains' runtime – this is unique to Substrate based chains, and removes the requirement for a "hard fork" of the chain when updating the chains' business logic (runtime).
Referenda are discrete events which have a fixed voting period (more about the different periods during the lifecycle of a referendum later). Individual token holders can vote in one-of-three ways on referenda – AYE (agree/yes), NAY (disagree/no), or ABSTAIN from voting entirely.
All referenda have an enactment delay associated with them. This is the period between the referendum ending and, assuming the referendum was approved, the changes being enacted on the network.
Referenda are considered "baked" if it is closed and the votes are tallied. Assuming that the referendum was approved, it will be scheduled for enactment (in the chains' scheduler). Referenda are considered "unbaked" if the outcome is pending – such as if the referendum is still currently being voted on.
With the addition of OpenGov, anyone is able to start a referendum at any time, and they can do so as many times as they wish. OpenGov removes the limitation of only 1 referendum being able to be processed at a time (note that, in Gov v1, only 1 referendum can be voted on at at time. The only exception being additional emergency referendum by the Technical Committee which can also be simultaneously voted on by the community).
OpenGov introduces several new features / concepts known as Origins and Tracks, and these are introduced to help aid in the flow and processing of referenda in the protocol.
Each Origin is associated with a single referendum class, and each class is associated with a track. The track outlines the lifecycle for the referendum and is specific for that particular track. Having tracks with their own specific parameters allows the network for dynamically modify the lifecycle of referenda based on their privilege level (you can think of privilege level as being how powerful a referenda can be / what types of changes it can make to the protocol).
*Think of Origins as the power associated with a referendum, and think of Tracks as the parameters associated with a referendum, such as the lengths of it's periods, and the Approval and Support criteria.*
For example, a runtime upgrade does not have the same implications for the protocol as a treasury tip, and therefore different origins are needed in which different turnouts, approvals, deposits, and enactment periods (Tracks) will be predetermined in the chains' pallet.
## Proposing a Referendum & Referendum Lifecycle
### Preparation Period
In OpenGov, when a referendum is initially created, it can be immediately voted on by the token holder community. However, it is not immediately in a state where it can end, or otherwise have its votes counted, be approved and summarily enacted. Instead, referenda must fulfil a number of criteria before they are moved into the Decision Period. Until referenda enter the Decision Period, they will remain undecided – and will eventually time-out after the overall lifecycle period as specified in the individual track.
The criteria for a referendum to enter the Decision Period is as follows:
1. A Preparation Period that outlines the amount of time that must elapse before the Decision Period can begin. This Preparation Period helps to mitigate against the possibility of "decision sniping" whereby an attacker controlling a substantial amount of voting power might seek to use their large stake to have a referendum be passed immediately after proposing, circumventing the possibility for the other members of the token holder DAO to have adequate time to consider the referendum and participate in the vote.
2. There must be room for the decision. Each track has it's own limits for the amount of referenda which can be decided upon simultaneously (max_deciding). Tracks that have more powerful privilege levels will have lower limits. For example, the Root level origin will have a significantly lower amount of referendums that can be decided upon simultaneously in comparison to lower privilege level origins such as the Small Tipper origin.
3. The Decision Deposit must be submitted. Initially creating a referendum is fairly cheap, and the value of the Submission Deposit (reserved when the referendum is initially created) is fairly low, and is mainly made up of the value it costs for the on-chain storage associated with the referendum. Decision Deposits are significantly higher, which is required in order to combat spam, and plays into the economical game which OpenGov brings, which we will go through later.
Once all of these three criteria above have been met, the referendum will move into the Decision Period. The votes on the referendum will then be counted towards the outcome.
### Decision Period
Once a referendum has met all of the criteria as detailed in the section above, it will enter the Decision Period.
The Decision Period revolves around two main concepts, that being the Approval and Support criteria.
Approval is defined as the share of the approval vote weight (AYEs vs NAYs) compared to the total vote weight (all AYE & NAY votes combined). Conviction of each vote counts towards the overall weight of the AYE/NAY votes.
Support is the total number of votes (tokens) that have participated in the referendum (and does not get adjusted for conviction) compared to the total possible votes that could be made in the system (think of this as the total issuance of XRT on the parachain).
**Votes which are in the ABSTAIN direction do NOT contribute to the Approval criteria, but are included / count towards the Support criteria**
A referendum must meet the Support AND Approval criteria during the Decision Period in order to progress to the Confirmation Period.
For details of the individual Support and Approval criteria for each track see this [spreadsheet](https://docs.google.com/spreadsheets/d/1CzUKxl5bEhLQRLC223NB81RTH4X4HgAoS1HPng23mXE/edit?usp=sharing).
### Confirmation Period
Each track has it's own specific duration for it's Confirmation Period. Tracks which have greater privilege levels (such as Root) have significantly longer Confirmation Periods than those with lower privilege levels (such as Small Tipper).
Referenda must continue to meet the Approval and Support criteria for the entire duration of the Confirmation Period, otherwise they will once again go back into the Decision Period (note: the Decision Period is not paused during the Confirmation Period, so it is entirely possible that a Decision Period may expire during the Confirmation Period, meaning that if a referendum is bumped out of the Confirmation Period due to it no longer meeting the Approval and Support criteria, it will then be considered as a failed referendum and not enacted).
It is possible to adjust the Approval and Support criteria for individual tracks through a referendum with Root privileges.
Origins with lower privilege levels have significantly easier approval and support criteria (set by the track) to be met than those with higher privilege levels. Similarly, origins with higher privilege levels have less steep curves than those with less privileges (as defined in the track), in order to ensure that the token holder DAO does indeed approve of the referendum, and avoid referendum sniping for high privilege origin referenda.
In OpenGov, referenda that are not approved after the Decision Period expires are considered rejected by default, and both the submission and decision deposits are refunded to their originators (note: the decision deposit can be posted by someone other than the originator of the referendum).
If a referendum manages to continually meet the Approval and Support criteria for the entire Confirmation Period, then it is considered approved, and will be scheduled to execute from the proposed origin, but only after the minimum enactment period.
### Enactment Period
The Enactment Period is specified by the originator when the referendum is proposed, but it is subject to the Minimum Enactment Period which is specified in each track. More powerful Origins have a much higher minimum enactment period than those with less privileges. This ensures that the network has ample time to prepare for any changes that powerful referendum may impose.
## Voluntary Locking / Conviction
Robonomics uses a concept known as voluntary locking, or conviction voting. This allows token holders to increase their voting power by deciding for how long they are willing to lock up their tokens for a particular referendum. This mechanism only affects the Approval criteria for each referendum, and conviction voting does not affect the Support criteria.
Conviction Voting can be calculated using this formula:
Approval Votes = tokens * conviction_multiplier
This table shows you how each increasing level of lock-up period multiplies your vote for the approval criteria:
**ADD TABLE WITH LOCK PERIODS, VOTE MULTIPLIER, AND LOCK UP DURATION HERE**
The maximum amount of conviction that a token holder can use is 6x conviction. You can only set conviction as per the table above, and you cannot, for example, use 5.5x conviction.
While a token is locked due to voting, they can still be used to vote in other referendums, however, they will not be part of your transferrable balance (you cannot send it to another account).
## Vote Delegation
In OpenGov, an mechanism was added in order to allow tokens holders who don't necessarily have enough time to review each referendum to still have their tokens be used as part of the governance system, this is known as vote delegation.
Token holders can choose to delegate their voting power to another voter in the system (another account). Voters can specify to delegate their voting power in an agile way, allowing them to assign their voting power to a different account for each individual Origin. Voters can also set to assign a different amount of voting power for each Origin (number of tokens and conviction level).
This delegation feature has one goal, to increase voter turnout, and to help to ensure that the required turnouts to meet the Approval and Support criteria are met.
To delegate your voting power, you can use the "Delegate" function which you can find on the Governance -> Referendum section of the [Robonomics Portal](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama.rpc.robonomics.network%2F#/explorer). Alternatively, users can submit the convictionVoting(Delegate) extrinsic using the Developer -> Extrinsics section of the Robonomics Portal, however using the "Delegate" function of the referendum section of the portal is far easier.
## Cancelling / Killing Referendum and the Governance Economic Game
In OpenGov, there are Origins which are delegated to reject ongoing referendums, regardless of it's status. These are known as the Governance Canceller and Governance Killer tracks.
These Origins intervene on a referendum that is already been voted on. These Origins, if the referendum originating from them is approved, will immediately reject an ongoing referendum regardless of it's status.
Cancellation itself is a type of referendum which must be voted on by the token holders in order to be executed. Cancellation comes with its own origin and track which have a lower lead time (Decision Period, etc.), and have Approval and Support curves with a steeper/sharper curve (meaning their criteria are much easier to meet over time) than other Origins. This is due to the fact that cancellation of a referendum usually will come with a sense of urgency.
Governance Canceller aims to instantly reject an already ongoing referendum. When a referendum is cancelled by this origin, both the Submission and Decision Deposit are refunded to their originators. An example of when a referendum might be considered to be cancelled is if the originator has made some human-error in their referendum's contents, and hasn't necessarily tried to do anything malicious.
Governance Killer aims to instantly reject an already ongoing referendum. This is where the governance economic game comes into play. Origins with high privilege levels, such as Root, have a Decision Deposit which requires a high amount of capital (XRT tokens) to be posted in order for the referendum to enter the Decision Period.
If a malicious actor submits a referendum, such as a referendum with Root origins which aims to `set_code` of the chains' runtime to something which will stop the chain producing blocks, then the token holder DAO can raise a counter Governance Killer referendum. If the malicious referendum is rejected via the Governance Killer origin, then both the Submission and Decision deposits are slashed, meaning that the originator will lose those funds.
This means that their is a severe economic consequence for malicious actors to attempt to raise referendum which would have severe negative impacts for the chain, which in theory will stop any malicious actor from attempting to do this.
The Decision Deposit for the Governance Killer track itself is quite high, this is in order to stop equally malicious actors from attempting to slash deposits of otherwise good referendum. An existing Governance Killer referendum can be killed by a subsequent Governance Killer referendum.
## Robonomics Technical Committee & Whitelisted Origin (confirm name with team, maybe robonomics fellowship?
This group is a self-governing expert body which has the primary goal of representing humans who embody and possess the technical knowledge of the Robonomics network protocol.
[**NEED TO TALK WITH TEAM TO DISCUSS WHETHER OR NOT WE WILL ALLOW NON TEAM MEMBERS TO EVENTUALLY JOIN THE TC/FELLOWSHIP**]
This group (and only this group) is able to originate referenda from the Whitelist pallet. This pallet does one thing, it allows one Origin to escalate the privilege level of another Origin for a certain operation.
This group can authorize referendum from a origin known as Whitelisted-Root, and these referendum can be executed with Root-level privileges, but these referendum will only successfully work with certain specified commands that have been authorized by the group. The Whitelist pallet verifies two things:
1. The Origin really is the Whitelisted-Root (i.e. that referendum passed through this Origin's track).
2. The proposal has indeed been whitelisted by the group.
If both conditions are true, then the operation will execute with Root-level privileges.
This system enables the ability to have a new parallel Track (Whitelisted-Root Origin), whose parameters allow for a shorter voting turnaround (Approval and Support criteria are slightly easier to meet than Root). This open and transparent process allows this body of experts for the Robonomics Network Protocol to propose referendums that they have determined are safe, and time-critical.
It should be noted that the Support Criteria for referendum initiated with the Whitelisted-Root origin does not trend towards 0 like a lot of other origins/tracks. This ensures that this group does not have defacto control over the entire Robonomics Network Protocol, and requires a minimum level of Support (voter turnout) from the overall token holder DAO.