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!
Hey, Yann! thank you so much for this proposal!
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?
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.
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.
- 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.
- 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.
- 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”.
- a. Your proposal get continuously enough votes in favor for 1 day. You will become a registrar at the 500 MOVR will be refunded
- 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 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 (@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.
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!
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
I am Linkou mentionned above. Happy to answer any questions!
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.
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.
Hi, I’m Boony, happy to join this forum.
I run the MoonWorld Collator. I’m working in IT for over 15 years.
Congratulations to all the members selected.
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.
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.
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.
|Root||Origin commanded by any Community member||
Can be elevated to
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.
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.
To update my previous comment, it looks like OpenGov will be introduced into Polkadot on the next Polkadot RT update:
Can’t wait to see OpenGov live on Moonbeam after the success on Kusama and Moonriver. Totally support this.