Discussion about migration to OpenGov

Centrifuge Governance Governance discussion
,
1

:mega: Attention Centrifuge DAO and governance aficionados!

As a DAO, we have to make an important decision regarding a migration to OpenGov and we would like to invite our governance/OpenGov experts to start the discussions.

Background

Gov1 was the main governance system on both Polkadot and Kusama (including the parachains). OpenGov is the new system that has been live on Kusama since November 2022 and was recently implemented on Polkadot in June 2023.

It is entirely up to the individual projects whether they want to adapt this new system or stay on the old one (Gov1) - each project can also customise the setup so it fits their needs. Some projects have already adapted OpenGov (Moonbeam/Moonriver) and others (Bifrost and Robonomics) are in the process of doing so.

Centrifuge DAO is a decentralised entity and the GCG believes that our governance process should reflect that as well.

:bulb: Some useful background knowledge about OpenGov:

Considerations

A full migration to OpenGov offers advantages like:

  • More decentralisation
    • No entity that holds special power of the network (i.e. the Council)
    • Token holders can vote on all proposals
  • More flexibility in terms of delegation
    • You can delegate your tokens to vote on specific tracks only
  • More flexibility in terms of submission of proposals
    • Multiple referenda can run simultaneously
  • More flexibility in terms of customising the lifecycle of a referendum
    • Criteria for passing and maximum duration of proposals can be customised

However, none of that will matter, if we don’t think carefully about which parameters we want to use for the different tracks and it could pose a big risk to our chain’s security and also our treasury.

Note that a possible migration will not affect our off-chain governance - it will only change the way on-chain submission of proposals are made and their lifecycle.

Before a proposal is made to migrate to OpenGov, we need to discuss some important topics:

  • Do we want to keep our treasury locked behind the council (Council still administers the funds) or do we want to use OpenGov’s model (treasury proposals are voted on by all token holders)?
  • How many members should the Fellowship consist of and who should be in it?
  • What tracks do we want to include in our setup?
  • What parameters do we want to use for each track?
    • Maximum # of referenda to run at the same time (Max Deciding)
    • Duration of Preparation Period
    • Decision Deposit
    • Decision Period
    • Approval and Support Criteria
    • Confirmation Period
    • Enactment Period
  • When we decide to migrate, should this apply to Altair as well?

Next steps

In order to make sure that we approach this decision the best possible way, we need to gather a diverse work group consisting of people who have a broad knowledge about both governance/OpenGov and technical knowledge about how the Centrifuge chain works (e.g. protocol engineers). Tagging some people who could be interesting joining the work group:

@WilliamFreude @mikiquantum @branan @nuno @The_Phunky_One_Lucky @leemo @lucasvo @cassidy @Davidutro @Kate_Bee

Feel free to express your interest in joining the work group in the comments below if you want to contribute.

Once the group has been established, we will schedule a call to discuss the topics thoroughly and it will also be on the agenda for the governance call in August. Once consensus has been reached, there will be a formal proposal, with specific tracks and their parameters, for all CFG token holders to vote on.

Here are some questions to help start the discussions:

  • What are your thoughts about a migration to OpenGov?
  • When would be a good time to start migrating to OpenGov?
  • What are your experiences with OpenGov from Polkadot/Kusama (or other projects)?
  • Are there any other considerations to be made other than the ones mentioned above?

Please share your thoughts below.

7 Likes
2

Not now. IMO we should continue to refine our existing governance processes and token holder activation before getting into the thick of the OpenGov upgrade. In terms of infrastructure, the existing offchain and onchain voting seems to work; but we need to continue educating and onboarding new and existing tokenholders into governance participation. I think diving into this now will just add more confusion and possibly dissuade token holders from being involved in protocol governance.

5 Likes
3

Thanks for tuning in @devin!

I fully agree with what you write here. Do you think it is mutually exclusive to do both what you suggest AND start the preliminary discussions around a migration and consider things like what tracks we would want to include and their parameters? Besides, starting the discussions now doesn’t mean that a migration would take place within the next couple of weeks. There is still a lot of work to be done prior to a migration.

For context; token holders voting in on-chain referenda in OpenGov are not going to experience any significant change in terms of how to participate, compared to Gov1 - it is mainly how proposals are submitted.

3 Likes
4

I’m with @devin insofar as I believe we should not make the leap to OpenGov on Centrifuge (at least yet). It has been a bumpy rollout and much chaos has ensued on since its debut on Kusama (and now Polkadot…which I also thought was too fast). It might be better to watch the development/evolution of OpenGov on the two primary relay chains before trying to push it out onto individual parachains.

Granted, as @leemo noted during his comments on AAG this past Monday, it really depends on what each parachain team needs to accomplish passing governance motions. As most of you know based on how much I mention this, I believe the current system Centrifuge uses is one of the best in the entire ecosystem. Though it may still be “Gov 1” in some sense, there is a thorough process that is incredibly mindful. We push out RFCs, solicit feedback, have additional discussions in the GCG Slack and Discord server, then finally push votes on-chain.

And even if we keep this as a Gov 1 setup for the foreseeable future, we might be able to streamline support signaling before any referendum goes on-chain by using the new open source Discord bot created in ChaosDAO. I’m a bit biased because I use it every day and love it! We are going to use it in our Lucky Friday server as well so that we can vote as individuals before voting on various OpenGov referenda as an organization.

The link didn’t share the timestamp properly, but if you start at 1:17:20 you will start to catch Leemo’s thoughts on this (moving to OpenGov)

3 Likes
5

Unfortunately I don’t think the question for us about if we migrate but when we migrate. There are two reasons:

  1. It’s not feasible for us to maintain Gov1 on our own without the support of the ecosystem. There are severe downsides (like insufficient delegation abilities) that we’d have to address on our own. I don’t think it’s a wise use of engineering resources to do this.
  2. The same reasons why Polkadot abandoned the council also apply to us. A rather centralized group of people making major governance decisions is not a good idea and I think because of that we will have to find a replacement for the council. Without the council much of Gov1 becomes too slow so we’re back to having to move towards Gov2 anyway.

I think Polkadot’s Gov2 parameters are much more complicated than we need them and it’s likely we can adopt Gov2 in a way that it won’t add too much complexity to what we have now.

6 Likes
6

I could not agree more. We should not rush into OpenGov and focus on simplifying parameters as much as possible while not imposing any risks, of course.

OpenGov introduced a plurality of tracks on Kusama and Polkadot which makes sense for these chains. However, the cardinality of Centrifuge is orders or magnitude lower. Therefore, initial discussions should resolve around how much we can minimize the number of tracks for the initial Centrifuge version of OpenGov. Of course, we should also be aware of the overhead of adding tracks later as they might require migrations or freezing tracks which will be split. For instance, there is no need to have such a fine granularity of treasury proposals from the beginning.

So how about we split up past and foreseeable referenda into categories and then merge some of these to the same tracks, depending on their impact?

3 Likes
7

This is essentially the conclusion GCG arrived at in our report.

This is also what I discovered in my research. Right now, both Polkadot and Kusama each have 15 (identical) tracks - of which 6 are treasury tracks for different ranges of amounts requested. They also have 3 tracks that are relevant only for the Relay chains; namely Auction Admin, Lease Admin and Staking Admin for managing parachain auctions, slot leases and cancelling slashes, respectively.

Realistically, I would personally say we would need the following origins/tracks in our setup, based on previously submitted council motions/referenda on Centrifuge chain:

  • Root
    • for Runtime Upgrades
  • General Admin
    • for general on-chain decisions like XCM fees, setting amount of collators etc.
  • Treasurer 1
    • for treasury proposals
  • Referendum Canceller
    • to cancel wrong referenda (e.g. referenda created wrongly unintentionally)
  • Referendum Killer
    • to cancel bad/malicious proposals (decision deposit will be slashed)

1 we could realistically manage with just one treasury track

In addition to the ones above, we also have to consider the tracks related to the Fellowship, i.e:

  • Fellowship Admin
    • to manage the Fellowship
  • Whitelisted Caller
    • for the Fellowship to be able to “fast-track” referenda
4 Likes
8

I like your proposal of the 5 tracks. I don’t quite know yet how we would institute a fellowship but the ability to fast-track is quite important. Do you have any ideas for this?

9

@lucasvo I’ve seen projects like both Moonbeam/Moonriver and Robonomics include the Whitelisted Caller track without actually having a Fellowship, but a Technical council who have the ability to whitelist referenda in that track. So it is possible to have some sort of a technical collective (that is not a Fellowship, technically speaking) who have the power to “fast-track” whitelisted referenda.

I will look a bit further into this, but some of the details might be too technical for me and outside my scope.

Maybe @leemo has some input on this matter he can share.

2 Likes
10

@Rhano This is the Polkadot Fellowship Manifesto. Maybe this information could help you. https://github.com/polkadot-fellows/manifesto/blob/main/manifesto.pdf

3 Likes
11

Thank you @LuisG! I actually read the manifesto when researching and also linked to it in our report - it focuses on the setup of the Fellowship, ranks, managing members etc.

The setup I mention above appears to be some sort of custom solution to circumvent the Fellowship but still allows a collective entity (i.e. a Technical Committee) to leverage the Whitelisted Caller track. On Moonbeam’s forum, they explain their choice of this setup this way:

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.

1 Like
12

GM those who wish to bring real world assets to our glorious eco!

Discussed a little bit with Rhano on TG to hopefully try help with my extremely limited technical knowledge (hopefully pointing him to the correct part of the Polkadot runtime to change curves and/or the onchain collective that can execute whitelisted origin).

I want to just discuss a point that I brought up during my presentation on your Governance call some weeks ago.

With OpenGov, you can change the approval and support curves so that for example the approval curve does not end at 50% and the support curve does not end at 0%.

This might be of great importance to Centrifuge as currently it seems that you are all fans of the RFC process, whereby proposals can be discussed in detail prior to their on-chain submission.

The “issue” with OpenGov is that the “end result” is the same whether or not you follow the RFC process. You create a referendum that has the same quorum.

This is not the case in Gov1, as if you create a proposal through the public proposal queue, it will have a SuperMajorityApprove quorum, which coupled with adaptive quorum biasing means that the referendum will need 90+% ayes to pass.

In Gov1, you can sort of push people towards the RFC process, as if the process is followed, the Centrifuge Council raises a Council Motion → External Motion → Referendum which will have a SimpleMajorityApprove quorum (50%+1).

If you want to keep directing people down the path of the RFC process, then I would suggest that you make all the curves for every track (other than Whitelisted Caller) trend towards something like: 75% approval, 5% Support (the support would depend on your average sort of voter turn out on the parachain, it’s likely much lower).

This would mean that it is indeed possible for anyone to propose any referendum via OpenGov, but the criteria that it needs to meet are much higher.

Now, the Whitelisted Caller track would be controlled by some on-chain collective. For example the tech comm. Only that group is able to propose referenda via the Whitelisted Caller origin/track. This would mean that the entity in control of it would be able to propose referenda that have gone through the desired root of RFC etc. and that track can have much easier criteria to meet, such as 50% approval and 0% support.

Feel free to refer back to my presentation linked by Rhano in the original post, where I go over this on video if you like.

Edit: just to elaborate further – you don’t NEED to configure the tracks like that if your community is very active. For example, if the status quo is to nay vote those who circumvent the desired RFC route, then the community will protect your chain too, and the tracks won’t need to - or you can do a mix of both - it’s very customizable!

6 Likes
13

Appreciate your thoughts and input @leemo - very helpful as always!

I am currently working on some suggestions to specific parameters for the tracks that we would need to include and will post them here in this thread during September as soon as they are ready so the DAO can comment on them before a formal proposal is made. In general, I personally like the idea of proposal tending towards SimpleMajority at the end of the Deciding period and, if needed, mitigate it by adjusting the support.

Yes, I personally think that the RFC is a very important step in the governance process and believe that it makes sense to keep it. Ideally, I think a good solution for us would be to keep our off-chain governance as is (RFC and OpenSquare snapshots) so a migration to OpenGov only would affect our governance process in terms of how proposals are submitted on-chain and their lifecycle - but we definitely need more discussion about this.

A turnout of 5% is a bit too high for us at this moment (at least if the electorate is the total supply). We have an average of around 1% turnout in our referenda - but I get your point. I know you mentioned that the electorate can be customised to any amount, like Kusama lowered it to account for tokens locked in crowdloans, so this is something we can consider as well.

2 Likes
14

As we spoke about here’s a link to my PolkaDefiance presentation about OpenGov. Might help some people who are not so familiar with Polkadot eco governance hopefully!
Some of the topics:

  1. Polkadot Governance benefits
  2. Benefits of OpenGov vs Gov1
  3. Some of the pain points of OpenGov

Towards the middle it does have a lot of info about how Nova Wallet tries to fix some of the pain points - but the first half is quite relevant I think.

4 Likes
15

This is extremely helpful @leemo - thank you for taking the time to understand our RFC process, and how that is working - I would say we do want to somehow integrate that into OpenGov rather than having to start anew

I think we can take on your advice in making curves for every track trend towards the higher end of the spectrum in terms of approval and support.

Higher criteria seem important to ensure quality and prevent spammy proposals when using something as widely open as OpenGov :smiley:

Cheers :cyclone:

2 Likes
16

Thank you everyone for your comments so far. There are now some suggestions to specific tracks and their parameters that we would like to get the DAOs input on, before a formal proposal is submitted.

Tracks

Below is an overview of the 6 suggested tracks and their descriptions.

Track Description Referendum examples
Root Track with the highest privilege Runtime upgrades, Technical Committee management
Whitelisted Caller Track used for referenda that have been whitelisted by the Technical Committee and can execute with Root privileges Fast-tracked operations
Pool Admin Custom track for pool management Launching a pool on Centrifuge
Treasurer Track used for asking for funding from the treasury Treasury proposal
Referendum Canceller Track used for cancellation of incorrectly submitted referenda, Decision Deposit is refunded Wrong referendum
Referendum Killer Track used for killing malicious referenda, Decision Deposit is slashed Malicious/harmful referendum

All tracks follow this flow, but with different parameters:

1393Ă—530 42.4 KB

Parameters

Below are the parameters for each track, specification of Approval and Support and their curves. Click on the :arrow_forward: to the left to expand.

:one: Root

Max Deciding Decision Deposit Prepare Period Decision Period Confirmation Period Enactment Period
Root 2 300,000 CFG 6 hours 14 days 12 hours 1 day

Approval (linear): 100% → 50%
Support (reciprocal): 50% → 0.88%

Click here for specification of Approval and Support over time
Hours Approval (linear) Support (reciprocal) Support in CFG
0 100.00 % 50.00 % 200,000,000
1 99.85 % 42.86 % 171,428,571
2 99.70 % 37.50 % 150,000,000
3 99.55 % 33.33 % 133,333,333
24 96.43 % 10.00 % 40,000,000
312 53.57 % 0.94 % 3,773,585
324 51.79 % 0.91 % 3,636,364
336 (14 days) 50.00 % 0.88 % 3,508,772

Support in CFG has been calculated with an Electorate of 400M CFG.

Click here to see the Approval and Support curves

1600Ă—718 67.8 KB

:two: Whitelisted Caller

Max Deciding Decision Deposit Prepare Period Decision Period Confirmation Period Enactment Period
Whitelisted Caller 20 1,000 CFG 10 minutes 7 days 10 minutes 10 minutes

Approval (linear): 100% → 50%
Support (reciprocal): 50% → 0.01%

Click here for specification of Approval and Support over time
Hours Approval (linear) Support (reciprocal) Support in CFG
0 100.00 % 50.00 % 200,000,000
1 99.70 % 1.92 % 7,692,308
2 99.40 % 0.98 % 3,921,569
3 99.11 % 0.66 % 2,631,579
24 92.86 % 0.08 % 332,779
72 78.57 % 0.03 % 111,049
120 64.29 % 0.02 % 66,644
168 (7 days) 50.00 % 0.01 % 47,608

Support in CFG has been calculated with an Electorate of 400M CFG.

Click here to see the Approval and Support curves

1600Ă—734 66.3 KB

:three: Pool Admin

Max Deciding Decision Deposit Prepare Period Decision Period Confirmation Period Enactment Period
Pool Admin 5 1,000 CFG 1 hour 7 days 1 hour 1 hour

Approval (linear): 100% → 70%
Support (reciprocal): 50% → 0.59%

Click here for specification of Approval and Support over time
Hours Approval (linear) Support (reciprocal) Support in CFG
0 100.00 % 50.00 % 200,000,000
1 99.82 % 33.33 % 133,333,333
2 99.64 % 25.00 % 100,000,000
3 99.46 % 20.00 % 80,000,000
24 95.71 % 3.85 % 15,384,615
72 87.14 % 1.35 % 5,405,405
120 78.57 % 0.82 % 3,278,689
168 (7 days) 70.00 % 0.59 % 2,352,941

Support in CFG has been calculated with an Electorate of 400M CFG.

Click here to see the Approval and Support curves

1600Ă—730 67.5 KB

:four: Treasurer

Max Deciding Decision Deposit Prepare Period Decision Period Confirmation Period Enactment Period
Treasurer 2 10,000 CFG 6 hours 14 days 12 hours 12 hours

Approval (linear): 100% → 70%
Support (linear): 50% → 1%

Click here for specification of Approval and Support over time
Hours Approval (linear) Support (reciprocal) Support in CFG
0 100.00 % 50.00 % 200,000,000
1 99.91 % 49.84 % 199,346,667
2 99.82 % 49.67 % 198,693,333
3 99.73 % 49.51 % 198,040,000
24 97.86 % 46.08 % 184,320,000
312 73.21 % 1.00 % 4,000,000
324 71.07 % 1.00 % 4,000,000
336 (14 days) 70.00 % 1.00 % 4,000,000

Support in CFG has been calculated with an Electorate of 400M CFG.

Click here to see the Approval and Support curves

1600Ă—730 72.3 KB

:five: Referendum Canceller

Max Deciding Decision Deposit Prepare Period Decision Period Confirmation Period Enactment Period
Referendum Canceller 20 50,000 CFG 1 hour 7 days 1 hour 10 minutes

Approval (linear): 100% → 70%
Support (reciprocal): 50% → 0.59%

Click here for specification of Approval and Support over time
Hours Approval (linear) Support (reciprocal) Support in CFG
0 100.00 % 50.00 % 200,000,000
1 99.82 % 33.33 % 133,333,333
2 99.64 % 25.00 % 100,000,000
3 99.46 % 20.00 % 80,000,000
24 95.71 % 3.85 % 15,384,615
72 87.14 % 1.35 % 5,405,405
120 78.57 % 0.82 % 3,278,689
168 (7 days) 70.00 % 0.59 % 2,352,941

Support in CFG has been calculated with an Electorate of 400M CFG.

Click here to see the Approval and Support curves

image
image2190Ă—972 139 KB

:six: Referendum Killer

Max Deciding Decision Deposit Prepare Period Decision Period Confirmation Period Enactment Period
Referendum Killer 20 75,000 CFG 1 hour 14 days 1 hour 10 minutes

Approval (linear): 100% → 70%
Support (reciprocal): 50% → 0.59%

Click here for specification of Approval and Support over time
Hours Approval (linear) Support (reciprocal) Support in CFG
0 100.00 % 50.00 % 200,000,000
1 99.91 % 40,00 % 160,000,000
2 99.82 % 33,33 % 133,333,333
3 99.73 % 28,57 % 114,285,714
24 97.86 % 7,14 % 28,571,429
312 73.21 % 0,66 % 2,631,579
324 71.07 % 0,61 % 2,439,024
336 (14 days) 70,00 % 0,59 % 2,352,941

Support in CFG has been calculated with an Electorate of 400M CFG.

Click here to see the Approval and Support curves

1600Ă—732 61.7 KB

Appendix

Prepare Period
  • The minimum time the referendum needs to wait before it can progress to the Decision Period - basically a waiting room for referenda. Voting is enabled, but the votes do not count toward the outcome of the referendum yet.
Max Deciding
  • The maximum number of referenda that can be in the Decision Period of a track at any given time.
Decision Deposit
  • This deposit is required for a referendum to progress to the Decision Period after the end of the Prepare Period. It doesn’t have to be the proposer who pays this, anyone can pay the deposit. If a decision deposit is not paid within a predetermined time range (e.g. 14 days), the proposal will get rejected by default. This will be returned to the proposer regardless of whether the referendum passes or fails. The only way a deposit can be slashed is if a Referendum Killer is submitted (to kill a malicious referendum) and passes.
Decision Period
  • The maximum amount of time a decision may take to be approved (or rejected). If the proposal is not approved by the end of the Decision Period (i.e. meets both Approve and Support criteria and stays there for the Confirmation Period), it gets rejected by default.
Confirmation Period
  • The total time the referenda must meet both the min Approval and Support criteria during the Decision Period in order to pass and enter the Enactment Period.
Enactment Period
  • Minimum time that an approved proposal must be in the dispatch queue after approval. The proposer has the option to add an additional delay before the referendum is enacted.
Approval
  • The share of Aye votes, compared to all votes cast in the referendum (Aye + Nay) including conviction. I.e. Aye/(Aye + Nay).
Support
  • The total number of votes, without conviction, compared to the total possible number of votes that could be made in the system (electorate). Support also takes into account Abstain votes. I.e. (Aye + Nay + Abstain) / Electorate.
Electorate
  • The total number of tokens that can be used to vote in governance. This is typically the total supply. However, it is possible to modify this number on OpenGov.

@leemo @The_Phunky_One_Lucky @LuisG @lucasvo @WilliamFreude @Kate_Bee @ImdioR @cassidy @devin

5 Likes
17

Your porposal for Referendum Killer is to have a 14 day decision period. Doesn’t that mean that you can never kill a referendum because the Root track also has only a 14 day decision period and a 1 day enactment?

I think we should increase the enactment period of Root track to be at least 1.5 times the length of the Whitelisted Caller period and that of the Referendum Killer.

18

Thanks for the input @lucasvo!

Referendum Killer is mainly intended to kill malicious proposals made through the Root and Treasurer track (both with a 14 day Decision Period and 1 day and 12 hours Enactment Period, respectively) and will slash the submitter’s Decision Deposit so it has a higher impact than the Referendum Canceller.

The Support requirement for Referendum Killer is less than that for the Root track (and Treasurer) and the rationale behind the suggestions is that people who will vote Aye on a Referendum Killer, will most likely also vote Nay on the malicious proposal it is trying to kill and thus making it harder for the malicious proposal to reach Approval.

But it really depends on how fast we react and launch the Referendum Killer and how many people will vote.

The Enactment Period of the Root track is 1 day and the Enactment Period for both the Whitelisted Caller and the Referendum Killer track is 10 minutes so already way more than 1.5X. The Whitelisted Caller track is the “safe” track, used only by the Technical Committe so I don’t expect us to launch a Referendum Killer to kill a proposal made with the Whitelisted Caller track.

Note that for cancelling a referendum (e.g. if it has been submitted with incorrect pre-image/parameters etc.), we can simply use the Referendum Canceller with shorter Decision Period.

If we still want to make the Referendum Killer more efficient, we have a couple of options here:

  1. Decrease the Decision Period of the Referendum Killer to 7 days (or 10 days).
  2. Increase the Enactment Period of both the Root and Treasurer track to 2-3 days.

Or a combination of them.

1 Like
19

I’m not sure I fully understand this. What is the worst case scenario:

  1. Hacker puts up deposit and uploads a preimage late at night right before the weekend to give themselves root privileges.
  2. GCG misses this proposal and it takes 56hrs before anyone notices this.
  3. GCG takes another 24hrs to source the 75’000 CFG required to put forward the referendum

In that case, with the current proposal the referendum killer track is not going to help at all, right? I guess in this case the Referendum Killer total execution period must be at least 56+24hrs less than the Root track, right? How do other parachains set this parameter?

20

The Hacker or Bad Actors will need to deposit 300,000 CFG + for fast approval they will need +50M CFG tokens (in this case the decision period will req. only 24 hours) + they need to wait for Confirmation period of 12 hours + Enactment 1 Day (24 hours)

image
image739Ă—457 11.7 KB

In total 24+24+12= 60 hours.
If they vote with more than 50M CFG tokens so in this case the decision period will be much shorter.

Probably increasing the enactment period for Root tracks will help to not face this situation.

Other projects:

image

1 Like