@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.
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 @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.
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 toRootOrigin 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.
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.
I’m voting in favor. I agree with the following group of members as a technical committee because their technical knowledge and skills indicate their capability to make highly accurate decisions regarding important matters
Hey Sik,
There is no difference - the Technical Committee in OpenGov is OpenGov Tech Committee; the title was chosen to make it clear.
I am not sure I understand the last part of your question though.
Both in Moonriver and Moonbeam the members are the same. Can you clarify and provide links if there are any?
