RFC: Changes to our CP Framework and Governance Process

Centrifuge Governance Proposals
, , ,
1

Proposal type: CP4
Authors: Governance and Coordination Group (@ImdioR @Rhano)
Contributors: @Davidutro
Technical/non-technical proposal: non-technical proposal
Date proposed: 2023-05-22

Short Summary

Improving/simplifying our current Governance Process.

High-level objective

Making our Governance Process more clear for anyone who wants to submit a CP and remove ambiguity from the process.

Background

Back in October, the GCG proposed the first version of our Governance Process that we are using today. Since then, many CPs have been submitted and we have learned a lot about what is working and what can be improved.

Detailed description of proposal

The GCG wants to propose the following changes to our Governance Process.

You can see the full proposal with a more detailed description of the changes and their implications here.

Off-chain governance + templates

:person_raising_hand: Minimum time for RFC

Keep the minimum time for 7 days but add that we strongly encourage 14 days or more.

:person_raising_hand: Cooling-off period for a proposal

Keep the time as 15 days but count from when the OpenSquare snapshots ends and apply a cooling-off period for on-chain proposals as well.

:person_raising_hand: Forum posts for CPs

One CP = one Forum post. The first post generally created is the RFC and it should be updated whenever the proposal passes through the stages (i.e. when it moves forward to off-chain voting, on-chain voting and the outcome of these etc.). We also propose to utilise tags in the titles to indicate what phase a proposal is in.

:person_raising_hand: Redefine when OpenSquare snapshots are needed

OpenSquare snapshots are optional if a proposal is followed by an on-chain vote straight after.

:person_raising_hand: Batch proposals on OpenSquare

All proposals that are ready to proceed get batched on OpenSquare the 1st and 3rd Mondays of the month. However, if there are time sensitive/urgent proposals, we have the option to start the off-chain vote anytime.

:person_raising_hand: Quorum for OpenSquare snapshots

Re-introduce a quorum for OpenSquare snapshots of 4M CFG (currently ~1% of total supply).

:person_raising_hand: Add “Abstain” as an option in OpenSquare snapshots

Add the option “Abstain” to the OpenSquare Snapshots, in addition to “Yes” and “No”. Votes for “Abstain” count towards the quorum.

:person_raising_hand: Two simultaneous, mutually exclusive proposals (off-chain)

Add to the governance process that in case there are two mutually exclusive proposals running simultaneously in an OpenSquare snapshot, it will be the one with most “Yes” votes (in terms of CFG), that will be the one that moves forward/passes.

:person_raising_hand: Possibility of correcting typos/minor errors in CPs on GitHub

Allow fixing typos and information that is obviously wrong after a proposal has passed. The procedure would be to just go ahead and correct the mistakes, and then announce the change(s) in the forum post for that proposal so people can object to it if they think the change(s) will alter the original proposal. The GCG is responsible for maintaining the Proposal Repository on GitHub so any changes would need to go through GCG.

:person_raising_hand: Specify changes more clearly

Add to the templates of RFCs which other CPs they modify/impact.

Mandates and Groups

:person_raising_hand: Definition of a mandate (CP1)

We have expanded on the definition of what a mandate is and when it is required.

:person_raising_hand: Selecting/changing a facilitator of a mandated group (CP1.1)

Create a default process for how a facilitator is selected or changed and redefine CP1.1 to be used for this process.

CPs in general

:person_raising_hand: Rename proposal types to “Components”

Rename the proposal types (CP1, CP2, CP3, CP4 etc.) to Components and allow CPs to implement/use multiple components in the same proposal. Remove the abbreviation of the proposal types/components in the title of a CP (e.g. GI, MR, RU etc.) as it will look messy if more are included in the same CP.

:person_raising_hand: Modify CP5 (POP)

Add to the documentation that the POP only applies to pools launching on Centrifuge Chain (not Tinlake) and replace OpenSquare Snapshot with on-chain voting(also change the visual for the flow of the onboarding process so it reflects this) in Stage 3.

:person_raising_hand: Add a visualisation of the flow of CPs

Add the flowchart below to our documentation.

image
image1478Ă—1708 123 KB

The changes proposed above will modify the following CPs:

Change or improvement

This proposal, if passed, will improve many aspects of our governance.

  • Better Flow of our Governance

    • Batching proposals on OpenSquare makes it more clear when proposals will be up for an off-chain vote and this could also help us avoid voting fatigue

  • Better Quality of Proposals

    • Making the requirements more clear for when a proposal is needed and what information to include will lead to higher quality proposals

  • Better Structure of our Forum

    • By reducing the forum posts to 1 for each CP, and modifying the structure, the forum will be less clogged, more intuitive to navigate in and proposals will be easier to find and their progress easier to track

Responsible

Governance and Coordination Group (@ImdioR & @Rhano)

Alignment to the mission of Centrifuge DAO

Having a robust, clear and decentralised governance process is crucial in our path towards our mission! It is one of the key pillars and improving it is an on-going process.

Next steps

After this RFC has been open for input and discussion for minimum 7 days, it will be submitted to the Centrifuge Proposal Repository on GitHub and an OpenSquare snapshot vote will be created (only off-chain voting, no on-chain voting is required for this proposal).

If the proposal passes on OpenSquare, the changes will applied, effective immediately, and the relevant documentation will be updated.

6 Likes
2

Pretty much agree with all of these things! Only one thing I didn’t quite understand:

:person_raising_hand: Two simultaneous, mutually exclusive proposals (off-chain)

Add to the governance process that in case there are two mutually exclusive proposals running simultaneously in an OpenSquare snapshot, it will be the one with most “Yes” votes (in terms of CFG), that will be the one that moves forward/passes.

What does mutually exclusive mean in this instance? Is it if there’s two proposals that are on different sides of the same topic? Is this a situation where one proposal seeks to do X thing, another proposal seeks to not do X thing, and the proposal with most Yes votes passes and decides?

3 Likes
3

Thanks for your input @devin.

Firstly, these are edge cases and I am not personally anticipating a lot of these scenarios but in case they occur, it is important to have some guidelines on how to address them.

An example of mutually exclusive proposals could be if two entities are asking for a mandate to enact the exact same work stream and the respective off-chain votes end at exactly the same time, then they cannot both obtain the mandate (even though both proposals pass). So the proposal that gets the most “Yes” votes, is the one passing.

Does that make sense?

This is also an example of mutually exclusive proposals - e.g. one proposal to mint 1M CFG for rewards and another one for not minting 1M CFG (e.g. for Tinlake rewards) - but I personally see a very simple solution to this. If someone is against minting 1M CFG for example, there is no need to create a proposal to not to do it - they can just vote no in the off-chain/on-chain vote for minting it.

1 Like
4

Hello! Thank you for sharing. Your work is amazing. Just one doubt about the process. If I understood correctly, the proposal is submitted to the Centrifuge Proposals Repository on Github at the same time the RFC is posted in the Forum, and in this point changes can be done in the repository during the RFC phase. After RFC period ends and during OpenSquare Snapshot voting the proposal in the repository can not be changed, but now with the update after the OpenSquare Snapshot phase if the proposal passed is possible to fix typos and information that is obviously wrong and It can be done only through GCG.

2 Likes
5

Hi @LuisG, thank you for your interest in this proposal!

Exactly, yes - so to clarify:

The proposal doesn’t have to be submitted to GitHub at the same time as the RFC - it just need to be submitted there before it moves on to an OpenSquare snapshot (off-chain vote). It is during the RFC phase that any changes can be made to a proposal before making it final and submitting to GitHub.

What we are proposing here is that if a proposal is submitted to GitHub and there are some obvious mistakes in the GitHub submission, the GCG can make these changes - but these changes will be announced in the post for the proposal so everyone can see it and object if they think that a correction is inappropriate (i.e. is altering the proposal).

Hope that makes sense.

If there is anything else that doesn’t make sense or you have other suggestions to what can be improved, feel free to post again.

2 Likes
6

Hi @Rhano Thank you very much for your reply! Every thing is clear now.

1 Like
7

Hello
I would like to suggest adding a wind-down process:

  1. In case if RFC proposal is stacked for more than 30-40 days or the author of this proposal decided to not move forward. In case if author will decide to move forward after 40 days he should restart the process.
  2. In case the proposal passed off-chain voting, but after not moved to on-chain for more than 60 days. This could be applied only in case if nothing prevents starting on-chain voting immediately. For example, Minting, increasing of trx fee, burning mechanism and etc and should not be applied for proposals that require developing.

What do you think?

2 Likes
8

I agree to the changes especially with the result to get a better structure in the forum. I recommend to close the proposal in the forum once it moved to a on-chain vote and finally after the voting period closed. No more comments and replies should be possible in the forum to make a cut

2 Likes
9

Agreed but here also the GCG can intervene and close the RFC if there is no more activity…

2 Likes
10

Hello, everyone :wave:

I cannot believe it has been a week since this was posted and I had yet to chime in. Having read through the RFC (I had glanced at the flowchart to glean a quick understanding in the CGC), I completely concur with the suggested changes. As I’ve shared a number of times previously, I believe the Centrifuge team is one of the very best in the entire Polkadot ecosystem when it comes to thoughtful deliberation and execution of governance topics/issues. This RFC is a testament to that fact, as it is clear both @Rhano and @ImdioR are always seeking ways to further streamline an already highly functional governance process.

Bring on the vote! :ballot_box:

Gratefully,

Ryan / Phunky

2 Likes
11

Is there a way to add a “Delegate” option for voting?

I understand the value of “Abstain” as a way to meet quorum. But, imo, we should try and avoid it as much as possible.

12

Hi ItsJake
The delegation already exists and you can find information about the delegation in Centrifuge Documentation.

1 Like
13

Thanks for tuning in @ItsJake. Can you elaborate a bit more what your concerns are with the “abstain” option?

I personally see it as way to get a more nuanced sentiment around a proposal.

14

I have no problem with it!!

I just thought if people would go to the trouble of selecting abstain they might as well just delegate their votes to someone else.

It looks like we get both options. Sounds ideal!!

1 Like
15

The GCG would like to suggest an additional change regarding the role of OpenSquare Snapshots.

Snapshots play an important role in our governance but for proposals that are followed by an on-chain vote immediately after the snapshot, the OpenSquare snapshot should be optional for two reasons:

  1. It is not realistic to predict the outcome of an on-chain vote based on its off-chain vote as people can use conviction in the on-chain vote and hence increase their voting power, relative to the snapshot
  2. There is nothing preventing a proposer to submit an on-chain proposal even if a snapshot fails to pass. So for proposals that are followed by an on-chain vote right after, the snapshot does not necessarily indicate the correct sentiment and we avoid “spamming” our community with voting.

See screenshot below to see how we have defined the role of OpenSquare snapshots in our current governance process:

image
image1550Ă—458 64.6 KB

And see the screenshot below to see exactly what we propose it to be like:

image
image899Ă—1022 39.4 KB

2 Likes