Hello everyone, I’m [Leemo](https://twitter.com/LeemoXD) – contributor to the Robonomics project and frequent governance enjoyooooor, and in this post I’d like to get community feedback regarding the implementation of [OpenGov](https://wiki.polkadot.network/docs/learn-opengov) onto the Robonomics parachain.

*Note: There was a previous referendum to gauge community interest for OpenGov* [here](https://robonomics.polkassembly.io/referendum/65).

# TL:DR
This proposal aims to introduce the community to the OpenGov model, as well as propose its configuration / parameters for the Robonomics parachain. There are a few reasons for implementing OpenGov:

1. Multiple  origins / tracks increases the overall capacity / throughput of governance decision making.
2. Lowering the barrier to entry – anyone can raise a referendum, and the amount of tokens required to initiate a referendum for lower privilege level origins can be quite low (note: the amount of tokens required to initiate the decision period for high privilege tracks, such as root, is significantly high due to security reasons).
3. Improving the quality of decisions taken – hopefully the implementation of OpenGov of the parachain will increase voter turnout, and hopefully the crowd (XRT token holder DAO) can make the best decisions for the future of the network.
4. Experimentation – the OpenGov model is at the forefront of on-chain Governance, and has proven to work quite well on the Kusama relay chain for some months already, and is scheduled to soon (Q2/Q3) be added to Polkadot.

# Motivation / why should we implement OpenGov?
OpenGov is at the forefront of on-chain governance, and has been deployed on Kusama for around 3 months at this point, since [runtime upgrade v9320](https://kusama.subsquare.io/democracy/referendum/244), and has been battle tested quite a lot by the community. 

OpenGov is a truly decentralized form of on-chain governance, and allows users 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, and hopefully increasing voter turnout quite significantly.

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 the Robonomics parachain.
I previously made a video explaining OpenGov here, and for anyone wanting to dive a little deeper, the OpenGov page of the Polkadot wiki is a good place to start.

# Process
Anyone from the Robonomics community can propose a referendum by specifying the Origin of the action that they want to initiate on-chain, as well as including its content.

The referendum will be initiated in the appropriate Track respective to its Origin. The referendum will then follow the below lifecycle, which is based on the Track’s parameters, and will either be executed or rejected. 

Here is a diagram of the basic outline of the OpenGov referendum lifecycle.

![](https://i.imgur.com/mK33mrl.jpg)

You also should be familiar with the process of cancelling / killing a bad / malicious referendum:

![](https://i.imgur.com/1FU6qFY.jpg)

# OpenGov Tracks and Parameters

I previously made a video about the Approval and Support curves [here](https://www.youtube.com/watch?v=wk58C-2CqPI), it will help you to understand the entire decision period.

The Approval and Support curves are critical to OpenGov performance, as they need to ensure that the majority of the crowd decides the direction of the vote, as well as ensuring that there is a high enough amount of participation for each referendum vote.

**The proposed OpenGov parameters for Robonomics are detailed in** [this spreadsheet](https://docs.google.com/spreadsheets/d/1CzUKxl5bEhLQRLC223NB81RTH4X4HgAoS1HPng23mXE/edit?usp=sharing).
It should be noted that these parameters are fairly conservative, and it is possible to modify the parameters via a referendum through the Root or Whitelisted Caller origins.

# Security Considerations

These are some considerations that were taken into account during the creation of the OpenGov parameters in the spreadsheet linked above.

### Track Capacity
1. A higher capacity increases the difficulty of spam attacks clogging up that specific track.
2. A small number can make it easier to keep track of all referendums.

### Decision Deposit
1. A higher value makes it much more expensive to attempt to pass malicious referendums, as your deposit can be slashed via Governance Killer (tracks with higher privilege levels have high decision deposits).
2. Smaller decision deposits promote decentralisation and ease of submitting referendums from the community.

### Preparation Period
1. A longer duration allows the community more time to prepare to act on bad proposals.

### Confirmation Period
1. A longer duration (and less steep support curve) makes it much more difficult for an attacker to try to push through malicious referendums.
2. A shorter duration allows for faster execution of referendum (see Governance Canceller).

### Minimum Enactment Period
1. A longer duration allows the community to organise and take action before a bad referendum is executed.
2. A shorter duration means that referendums will execute faster.


It should be noted that, much like on Kusama, the parameters should start off being quite conservative, and can be lowered/reduced over time.
OpenGov basically comes down to an economic game – if someone posts a bad referendum, they can be slashed and lose their deposits, so it needs to be economically non-viable to try to attack the parachain via malicious referendums.

# What’s next?

I would like to invite all of the Robonomics community to provide feedback regarding the implementation of OpenGov, including the track parameters that have been proposed in this post.



:
1. Introducing the OpenGov model and proposing its configuration / parameters for Robonomics parachain. 
2. Multiple origins/tracks increase the overall capacity/throughput of governance decisions. 
3. Lowering the barrier to entry for proposals - anyone can raise a referendum. 
4. OpenGov has been deployed on Kusama for around 3 months. 
5. Delegation of votes to increase voter turnout. 
6. Proposal of parameters in spreadsheet. 
7. Security considerations and economic game for malicious proposals. 
8. Inviting Community feedback.

#7 OpenGov Integration and Parameters

No Active Proposals