[Proposal] OpenGov integration & parameter discussion

[Product]

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

• Yes, I like it a lot.
• No, but I will propose something.
• No, I dislike it.
• I need more info.

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.

[Kathy_Moonbeam_PureS]

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.

Save your spot here

[turrizt]

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!

[0x_thiago]

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?

[Product]

Hi, thanks for your question.

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

Participate in Democracy · Polkadot Wiki

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.

[turrizt]

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

[lina.k.m]

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.moonsonglabs) - 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 (@siccomoonbeam) - 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 (@purestaketdb) - 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.

[turrizt]

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?

[Olivia_purestake]

@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. @lina.k.m - 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!

[turrizt]

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

@Olivia_purestake

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.

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

[linkou]

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

[turrizt]

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?

[linkou]

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.

[blackk_magiik]

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.

[Boony]

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

[simplysimplebrightly]

Congratulations to all the members selected.

[Jim_CertHum]

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.

[siccomoonbeam]

I just wanted to let everyone know that the addition of the 9 Tech Committee members listed above was submitted as referendum 3 on Moonriver and is now live for vote. Since this was listed on the Root Track, it can take up to 14 days to pass.

Creation of the OpenGov Tech Committee

[Product]

Dear members of our community,

We are pleased to inform you that we have successfully deployed and tested OpenGov on Moonriver. As we move forward with the integration on Moonbeam, we would like to share with you the proposed parameters.

Please see below for the track parameters, with amounts in GLMR for Moonbeam:

Note: All parameters are kept identical to Moonriver, except for the Decision deposit, which is expressed in token amount.

Track	Origins	Parameters	Curve
Root	Origin commanded by any Community member	Decision period 14d Confirmation period 1d Minimum Enactment period 1d Capacity 5 Decision deposit 2’00’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 200’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 10’000 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 200’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 400’000 Preparation 1h	Approval: RECIPROCAL 0d → 100% 1d → 96% 14d → 50%   Support: RECIPROCAL 0d → 10% 1d → 1% 14d → 0%

Next steps
After a few days of collecting feedback from the Community and if there are arguments against/or new suggestions, a 7 days voting session will take place. Otherwise this idea will be implemented and proposed to be included in one of the following Runtime Upgrades.

If you have any questions or comments, feel free to reply in the comment section below.

[Jim_CertHum]

With a few proposals going live in Moonriver with OpenGov, it doesn’t seem like there were any issues. Combined with the longer time OpenGov has been working on Kusama, it would seem that moving on to Moonbeam at this time is the right decision.

It all looks good overall based on the state of things today, but in the future, it would be helpful to understand what it would take to change the decision deposit variables. Regardless, I’m in support of the rollout to Moonbeam.