Hello, I am Yann - Product Lead at Purestake and I’d like to get the Community feedback and sentiment on the OpenGov track parameters described in this post.
Abstract
This proposal draft both introduces OpenGov and its configuration to Moonbeam networks. The 2 main objectives are :
- Increasing throughput of governance decision
- Improving the quality of the decision taken
Motivation
OpenGov is the freshly released new form of decentralized governance on Kusama using Substrate and providing users with the opportunity to directly participate in decision-making and voting processes while offering several key benefits, from increased security and transparency, to improved decision-making speed, accuracy and inclusiveness. It also allows users to delegate their votes to those more knowledgeable and experienced for specific decision types, thus reducing the risk of mistakes and malicious actors taking control of the network.
With OpenGov, it is now possible to provide an elegant solution to an on-chain governance process inheriting the following properties:
- Decentralized - A system accessible and transparent to anyone while being governed by the wide Community
- Secure - A system preventing harmful decisions to be executed while respecting the Community rules.
- Flexible - A system maximizing & controlling throughput based on decision impact level while providing enough granularity
All those points combined make OpenGov the ideal solution for a flexible, secure and decentralized decision making process for Moonbeam networks.
Rationale
Before reading this section, it is advised to first read the OpenGov Blog post which provides details required to fully understand the rest of the post.
Process description
Any Community holder can propose a referendum by specifying the Origin of the action they want to execute on-chain along with its content by calling the new extrinsic Referenda.submit(proposalOrigin, proposal, enactmentMoment)
.
Depending on the Origin, this proposal will be mapped to its respective track. The proposal will then follow the below lifecycle to, based on the track parameters, either be executed or rejected.
A picture is worth a thousand words, so here is a picture mapping out the new proposal process in OpenGov.
Tracks Proposal
Tracks list & description
Track | Description | Referendum examples |
---|---|---|
Root | Track with the highest privilege | Runtime upgrades, Technical Committee management |
Whitelisted | Track where proposals should be whitelisted by the Technical committee before getting dispatched | Fast-tracked operations |
General Admin | Track designed for general on-chain decision | XCM fees, Orbiter program, ParachainStaking, Registrar |
Emergency Canceller | Track used for Cancellation of wrong Referendum. Decision Deposit is refunded | Wrong referendum |
Emergency Killer | Trach used for Killing of bad Referendum. Deposit is slashed | Very Bad referendum |
Approval and Support curves
Those curves play a critical role in OpenGov as they both ensure that the majority decides and a high enough participation in each decision taken.
Following Kusama configuration. here are the 2 types of curves we propose to use :
- Reciprocal
- Linear
Here is an example of 2 graphs representing the following configuration :
-
Approval Curve in Green
- 0d → 100%
- 4d → 80% (96h red dot)
- 14d → 50%
-
Support Curve in Blue
- 0d → 50%
- 14d → 0%
Track parameters
For Moonriver
Track | Origins | Parameters | Flow visual | Curve |
---|---|---|---|---|
Root | Origin commanded by any Community member |
|
Approval:
Support:
|
|
Whitelist |
WhitelistedCaller Can be elevated to Root Origin if the referendum call has been whitelisted by the Technical Committee
|
|
Approval:
Support:
|
|
General Admin | GeneralAdmin |
|
Approval:
Support:
|
|
Emergency Cancellation | ReferendumCanceller |
|
Approval:
Support:
|
|
Emergency Killer | ReferendumKiller |
|
Approval:
Support:
|
Security Considerations
The correct definition of parameters for each OpenGov track is critical and should be carefully reviewed by the Community. If well-defined, it can prevent an attacker from performing any damaging attack on the network while ensuring a maximum flexibility and efficiency in the governance process for all Community members.
Track Parameter Considerations
Track Parameter | Impacts to consider |
---|---|
Capacity |
|
Decision deposit |
|
Preparation period |
|
Confirmation period |
|
Minimum Enactment period |
|
Ultimately and once debated, those parameters will need to be audited and battle tested before getting deployed along with OpenGov on Moonriver and Moonbeam networks.
Next steps
We invite all Community members to fill the poll below and provide us with the overall Community sentiment and feedbacks.
Do you agree with this idea
- Yes, I like it a lot.
- No, but I will propose something.
- No, I dislike it.
- I need more info.
0 voters
Ultimately and once debated, the final version of these parameters will be audited and battle tested before getting deployed along with OpenGov on Moonriver and Moonbeam networks.
If you have any questions or comments, feel free to reply in the comment section below.