[Proposal][Status:Idea] OpenGov integration & parameter discussion

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
  • Decision period

    • 14d

  • Confirmation period

    • 1d

  • Minimum Enactment period

    • 1d

  • Capacity

    • 5

  • Decision deposit

    • 100’000

  • Preparation

    • 1d

Approval:

RECIPROCAL

  • 0d → 100%

  • 4d → 80%

  • 14d → 50%

Support:

LINEAR

  • 0d → 25%

  • 14d → 0.5%

Whitelist WhitelistedCaller

Can be elevated to Root Origin if the referendum call has been whitelisted by the Technical Committee
  • Decision period

    • 14d

  • Confirmation period

    • 10m

  • Minimum Enactment period

    • 30m

  • Capacity

    • 100

  • Decision deposit

    • 10’000

  • Preparation

    • 10m

Approval:

RECIPROCAL

  • 0d → 100%

  • 1d → 96%

  • 14d → 50%

Support:

RECIPROCAL

  • 0d → 2%

  • 1h → 1%

  • 14d → 0%

General Admin GeneralAdmin
  • Decision period

    • 14d

  • Confirmation period

    • 1d

  • Minimum Enactment period

    • 1d

  • Capacity

    • 10

  • Decision deposit

    • 500

  • Preparation

    • 1h

Approval:

RECIPROCAL

  • 0d → 100%

  • 4d → 80%

  • 14d → 50%

 

Support:

RECIPROCAL

  • 0d → 50%

  • 7d → 10%

  • 14d → 0%

Emergency Cancellation ReferendumCanceller
  • Decision period

    • 14d

  • Confirmation period

    • 3 hours

  • Minimum Enactment period

    • 10m

  • Capacity

    • 20

  • Decision deposit

    • 10’000

  • Preparation

    • 1h

Approval:

RECIPROCAL

  • 0d → 100%

  • 1d → 96%

  • 14d → 50%

 Support:

RECIPROCAL

  • 0d → 10%

  • 1d → 1%

  • 14d → 0%

 

Emergency Killer ReferendumKiller
  • Decision period

    • 14d

  • Confirmation period

    • 3 hours

  • Minimum Enactment period

    • 10m

  • Capacity

    • 100

  • Decision deposit

    • 20’000

  • Preparation

    • 1h

Approval:

RECIPROCAL

  • 0d → 100%

  • 1d → 96%

  • 14d → 50%

 

Support:

RECIPROCAL

  • 0d → 10%

  • 1d → 1%

  • 14d → 0%

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
  • A high number increases the difficulty of spam attacks
  • A small number makes Community members monitoring and prevention of bad proposal easier
Decision deposit
  • A high number makes attacks expensive when slashed via Emergency Killer
  • A small number favorites the decentralization of proposal submission for Community members
Preparation period
  • A long duration allows Community members to be prepared to act on bad proposals
Confirmation period
  • A long duration increases the difficulty for attacker to “snipe“ or out-bid at the very end a bad proposal
  • A short duration allows for faster execution of proposals
Minimum Enactment period
  • A long duration allows Community members to organize, warn others or take emergency actions before a damaging proposal is dispatched.
  • A short duration allows for faster execution of proposals

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 :grey_question:

  • 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.

3 Likes

Hey everyone,

This Wednesday, December 21st, at 4:30 PM UTC, Yann Isola, Purestake Product Lead, will be hosting the next Community Voice episode, where he will explain and discuss this proposal with the Moonbeam community.

:point_right: Save your spot here

5 Likes

Hey, Yann! thank you so much for this proposal!
it’s truly inspiring to see how dedicated we are to decentralization and empowering the community to make on-chain decisions. now more than ever, it’s crucial to prioritize these values!

1 Like

Hey folks. That’s exciting news! Thank you for putting this proposal together.

I believe I got the overall concept of Opengov, but it would be nice to have a few examples to picture how the process would look like. Also, where can I find more information about the delegation feature?

2 Likes

Hi, thanks for your question.

Here are some readings on the Vote delegation feature for the current governance process for Polkadot :

Some third party platforms are currently looking to provide some reputation based off-chain system to make it easier/safer for holders to delegate their votes. With OpenGov, the Vote delegation feature will be be possible down to the track level - which will allow you, for instance, to delegate your vote for the General Admin track but not for the Root track.

Example
Goal : You want to become a registrar for Moonbeam network, meaning that you will be verifying/judging on-chain user information and collect a fee for this service.

  1. You will be proposing that the General Admin Origin registers your address as a valid Registrar for the network. This proposal will fall under the General Admin Track and will have to abide to the track rules.
  2. So, you will have to attach a decision deposit of 500 MOVR to this proposal. The 500 MOVR will be refunded whatever the proposal fails or succeeds, but it can be slashed if the community agrees that it is a malicious proposal.
  3. Community members will start to vote on your proposal and the requirement for it to go though will be following the Approval & Support curves which are high at the beginning and loose after 14 days but always requires a majority of “AYE”.
  4. a. Your proposal get continuously enough votes in favor for 1 day. You will become a registrar at the 500 MOVR will be refunded
  5. b. Your proposal does not get continuously enough votes in favor for 1 day even after the 14 days voting period. You get refunded of 500 MOVR but you are not registered as a new Registrar.

Happy to provide more details if needed.

Check out the latest community voice to get more details :point_right: Moonbeam Community Voice: OpenGov - YouTube

Here are the proposed names of prospective Technical Committee members (see Tracks Proposal table above). These community members were chosen because of their technical knowledge of Moonriver and Moonbeam and their dedication to the Network(s).
Members of the Technical Committee will be approved through a community vote (as part of Runtime 2100). Feedback and questions are welcome and encouraged!

Alan Sapede (@Alan_PureStake) - VP Engineering at PureStake. Over 20 years programming experience. Has deep technical and hands-on knowledge of the Moonbeam protocol. Is an active contributor to the Moonbeam codebase and has a large amount of Substrate and Polkadot expertise.

Gorka Apecechea (@girazoki) - Research Developer. Developer actively working on the Moonbeam protocol with specific expertise in relay chain interaction, XCM, and other Moonbeam subsystems. PhD in Computer Science / Cryptography.

Aaron Evans (@aaron.mbf ) - Director of the Moonbeam Foundation. Engineering Executive background. Has 20 years experience in software engineering and technical leadership roles. Has been working with Moonbeam and ecosystem projects since 2021.

Sicco Naets (@sicco-moonbeam) - Director of the Moonbeam Foundation. Software Engineering Leadership background. Has led teams implementing and designing complex software for over 20 years.

Linkou (@linkou) - Runs the MoonEntropy Collator on Moonriver and Moonbeam. IT & Security background and is engaged in governance votes on the Moonriver and Moonbeam networks. https://moonentropy.com/.

Boony (@Boony) - Runs the MoonWorld Collator on Moonbeam network. IT background and engaged in governance votes on the Moonbeam network.

Jim Farley (@Jim_CertHum) - Runs the Certum Collator on Moonriver and Moonbeam. Setup the independent collator coalition where collators support each other to stay in the active set. Also providing a snapshot service as a public good to the network, so collators can sync new nodes faster with known good images.

Blackk Magiik (@blackk_magiik) - Runs the Paradoxx Collator on the Moonriver/Moonbase networks. Extensive network security engineering and architecture background. Active in discord and governance discussions.

Tim Baldwin (@tdb) - VP Engineering at PureStake. Technical Lead for Dapps and Infrastructure. Familiar with Moonbeam APIs, SDKs, and development applications on Moonbeam. Has been working with Moonbeam since 2020. Over 25 years of experience in software engineering and IT.

7 Likes

Hey, Lina. personally, I support these community members. the only thing I was thinking about is that the Technical Committee in Gov2 will be replaced by a Fellowship, so it turns out that this is a temporary composition that will temporarily and, if necessary, apply important and urgent on-chain decisions?

I’m also wondering when the Technical Committee will be replaced by a Fellowship, will these community members have a higher rank or can you share your thoughts on how it will look like?

It’s great that you introduced us to the prospective Technical Committee members, we really appreciate it. but it also seems that it would be nice if the Technical Committee members introduced themselves here a little bit so that the community could get to know them and have some idea about them. what do you think?

@turrizt - Thanks for the comment. This is an important aspect of OpenGov and worth discussing in more detail.

You are right that instead of the Fellowship Moonriver will have a community Technical Committee (“TC”). The TCs power is very similar to the power of the Fellowship. The TC must never have hard power over the network: it cannot change governance tracks and associated parameters. Their only power in governance resides in the ability to “whitelist” a proposal. TC Members may only vote to whitelist a proposal if whitelisting that proposal would protect against a security vulnerability to the network. As such, the OpenGov TC has very limited power over the network. Its purpose is to provide technical review of urgent security issues which are proposed by token holders (TC members cannot propose things themselves).

While still subject to governance, the idea behind the Whitelist track is that it will have different parameters to make it faster for proposals to pass. The Whitelist Track parameters including approval, support and voting are determined by the Moonriver or Moonbeam Stakeholders and cannot be changed by the TC.

Members of the TC can vote on whether to whitelist any proposal. The passing threshold of the TC members of whether to whitelist a proposal is determined by governance.

As Lina indicated, the idea is that TC is composed of community members who have technical knowledge of Moonriver, and Moonbeam. Network stakeholders should expect that the TC Members will make well-informed decisions, of sound technical basis, and in line with the interest of the network and within the power and purpose of the TC (described above) when deciding whether a Proposal should be whitelisted.

The reason for the proposed TC instead of the Fellowship is one of practicality. With anything new and so impactful as new rolling out a new governance system, there are uncertainties. The fellowship seemed to be an additional level of uncertainty that required a large number of highly technical people. Moonbeam is a smaller network than Polkadot so it doesn’t seem practical or sensible (at this time) to follow the exact structure and ranking system as the Fellowship has. As our community grows and as we see and learn how the Fellowship evolves, I imagine the TC will evolve as well, and it may make sense to adopt the same Fellowship structure that Polkadot is implementing.

The idea is that Members of the TC are added or removed from the TC through governance (“Root Track” runtime upgrade proposals) and the TC can be amended through any Root Track governance proposal. So the composition, size and process for being a Member of the TC may evolve as OpenGov matures and the community learns more from experience. (all of the points about the TC in this response are just proposals for discussion now and will need to be voted on and approved by the community before being implemented)

As for the last point, I agree that the TC members can also speak for themselves and take questions if the community has any. @lyn - can you add the forum account for each TC member in your post so people can tag these members if there are specific questions for them.

Hope this is helpful!

4 Likes

Hey, Olivia, thank you so much for such a detailed answer, everything is crystal clear!

very clearly noticed, it makes a lot of sense! I completely agree with your vision

1 Like

Hello all
I am Linkou mentionned above. Happy to answer any questions!

2 Likes

Hey, linkou! glad to see you here, could you introduce yourself a little and tell us about your technical experience and connection with Moonbeam / Moonriver?

Currently working on CyberSecurity in France, I also manage the MoonEntropy collator.
I have been engage in differents blockchain related project during the last couple years and more recently on Moonbeam and Moonriver.

2 Likes

Hi everyone

I am one of the members running the Paradoxx collator. My background is in enterprise network security and data center architecture, also currently my day job. Happy to be nominated for the role. We’ve been in the Moonbeam ecosystem for over 1 year now and looking forward to what the future holds.

2 Likes

Hi, I’m Boony, happy to join this forum.
I run the MoonWorld Collator. I’m working in IT for over 15 years.

2 Likes

Congratulations to all the members selected.

2 Likes

Hi @turrizt – just in response to your request for individual introductions. Above and beyond the intro in Lyn’s post, I have a 22 year career in IT spanning security, network, cloud, and infrastructure technologies (as well as a bit of coding mixed in). From running vulnerability assessments in London to architecting AD migrations in Auckland, I’ve covered a lot of ground, but I’ve never been more excited than to be a part of the Moonbeam community, and grateful to be a proposed member of the Technical Committee.

2 Likes