Discussion about migration to OpenGov

: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.


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:


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.


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.


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.


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)


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.


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?


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

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?

@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.


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


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

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!


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.

1 Like

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.


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:

1 Like