CP108: Centrifuge Migration to OpenGov

Uses component: CP4
Authors: @Rhano @ImdioR
Contributors: @WilliamFreude @lucasvo @cassidy @Kate_Bee
Technical/non-technical proposal: Technical
Impacts/modifies: CP0, CP1, CP2, CP3, CP4, CP5, CP58
Date proposed: 2024-01-04

Short Summary

Transition of our onchain governance from Gov1 to OpenGov and improve governance process.


High-level objective

To make a soft transition to OpenGov - while keeping the Gov1 pallets (including the council) for a transition period of 3 months - using the tracks and parameters proposed below, based on the discussion here.

Also to improve our governance process by making the steps and templates more clear and consistent.


Background

The onchain governance mechanism, Gov1, served as the established standard for both Kusama and Polkadot (and the parachains) until the introduction of OpenGov in November 2022 and June 2023, respectively. Subsequently, a number of parachains have also undergone migration. Sustaining Gov1 independently, without the support of the ecosystem, would necessitate a substantial allocation of engineering resources. Moreover, relying on a centralized collective, exemplified by the council, is not ideal either. So we would have to address these challenges at some stage.


Description of Activity

The GCG proposes the following tracks and parameters for our OpenGov setup. The Whitelisted Caller track will be managed by a Technical Committee that will consist of people with knowledge and insight in the technical aspect of Centrifuge Chain. They will be a mandated group and a separate proposal will be made for their mandate request.

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:

Electorate

We propose to exclude the Treasury wallet (currently ~15.2M CFG) from the electorate. Given the only current inflation comes from block rewards (~3% annually) - where the majority goes into the treasury - the only increase in the electorate should come from the amount that is paid out to collators from the block rewards.

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)
0 100.00 % 50.00 %
1 99.85 % 42.86 %
2 99.70 % 37.50 %
3 99.55 % 33.33 %
24 96.43 % 10.00 %
312 53.57 % 0.94 %
324 51.79 % 0.91 %
336 (14 days) 50.00 % 0.88 %
Click here to see the Approval and Support curves

: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)
0 100.00 % 50.00 %
1 99.70 % 1.92 %
2 99.40 % 0.98 %
3 99.11 % 0.66 %
24 92.86 % 0.08 %
72 78.57 % 0.03 %
120 64.29 % 0.02 %
168 (7 days) 50.00 % 0.01 %
Click here to see the Approval and Support curves

: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)
0 100.00 % 50.00 %
1 99.82 % 33.33 %
2 99.64 % 25.00 %
3 99.46 % 20.00 %
24 95.71 % 3.85 %
72 87.14 % 1.35 %
120 78.57 % 0.82 %
168 (7 days) 70.00 % 0.59 %
Click here to see the Approval and Support curves

: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 (piece wise linear): 50% → 1%

Click here for specification of Approval and Support over time
Hours Approval (linear) Support (reciprocal)
0 100.00 % 50.00 %
1 99.91 % 49.84 %
2 99.82 % 49.67 %
3 99.73 % 49.51 %
24 97.86 % 46.08 %
312 73.21 % 1.00 %
324 71.07 % 1.00 %
336 (14 days) 70.00 % 1.00 %
Click here to see the Approval and Support curves

: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)
0 100.00 % 50.00 %
1 99.82 % 33.33 %
2 99.64 % 25.00 %
3 99.46 % 20.00 %
24 95.71 % 3.85 %
72 87.14 % 1.35 %
120 78.57 % 0.82 %
168 (7 days) 70.00 % 0.59 %
Click here to see the Approval and Support curves

:six: Referendum Killer

Max Deciding Decision Deposit Prepare Period Decision Period Confirmation Period Enactment Period
Referendum Killer 20 75,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)
0 100.00 % 50.00 %
1 99.82 % 33.33 %
2 99.64 % 25.00 %
3 99.46 % 20.00 %
24 95.71 % 3.85 %
72 87.14 % 1.35 %
120 78.57 % 0.82 %
168 (7 days) 70.00 % 0.59 %
Click here to see the Approval and Support curves

Changes to our governance process

In addition to the proposed parameters above, the following changes are also proposed to our governance process.

Naming of CPs

Instead of using the RFC prefix in the forum post when the CP is created, e.g. RFC: Centrifuge Migration to OpenGov, use CPXXX, where XXX is the pull request # from the GitHub submission, e.g. CP108: Centrifuge Migration to OpenGov. This will require the CP to be submitted to GitHub before it is posted on the forum.

Status of CPs

A CP can have the following status:

  • rfc
  • voting
  • passed / rejected

This should be indicated the forum post’s header (see section below) and tags as well as on GitHub, as the CP progresses through the stages.

Other tags to include in the forum post is:

  • tag of the component used (e.g. cp1, cp2, cp3, cp4 etc.)
  • tags specific for the CP (e.g. runtime-upgrade, governance-process, pool-fees etc.)

Headers of CPs in forum posts + GitHub

To keep the forum post and the file on GitHub consistent, the same standard header should be used both places for all CPs:

cp: [XXX]
title:
authors: [forum handles]
contributors: [forum handles]
uses-component: [cp1|cp2|cp3|cp4|cp5|cp32|cp63]
technical proposal: [yes|no]
requires onchain: [yes|no]
status: [rfc|voting|passed|rejected]
date-proposed: [YYYY-MM-DD]
date-ended: [YYYY-MM-DD]

Note that it is possible to include more than one component in a CP, e.g. you can have a CP that uses both component CP2 and CP4 etc.

The CP2 component (Tresury proposals) should include two additional lines:

beneficiary: [name]
wallet: [wallet address]

Adding new component

CP63 should be added as a component to CP0.


Change or improvement

This proposal, if passed, will make our onchain governance more decentralised, by removing the council so there are no entities that hold special powers over the network.

The Centrifuge Treasury will also fully be in the hand of all token holders, rather than being administered by a council.

However, these changes will also mean that CFG token holders, as a collective, will have more responsibility in terms of actively voting on governance proposals.

It will also bring more flexibility as it will allow us to

  • customise the lifecycle of each type of referendum
  • delegate tokens to vote on specific tracks

Our governance process will also be more clear as there will be standard templates to use when creating a CP.


Alignment to the mission of Centrifuge DAO

Given that Centrifuge operates as a decentralized organization, it is inherent that our governance aligns with this as well. The submission and outcome of all onchain proposals in OpenGov will be entirely in the hands of CFG token holders and not single entities.


Next steps

After the RFC period, the proposal will be submitted to GitHub, followed by an Opensquare snapshot (offchain voting). If that vote passes, the migration will be included in an upcoming Runtime Upgrade with the defined tracks and parameters. The Runtime Upgrade will most likely happen sometime in the beginning of Q3 2024.

If the proposal passes, the following tasks will need to be done asap post-migration:

  • Notify SubSquare to update the UI to support OpenGov referenda
  • Notify Subscan to update the UI to support OpenGov referenda
  • Notify Nova Wallet to update the UI to support OpenGov referenda
  • Update governance documentation based on the above changes

UPDATE

2024-05-06:

2024-05-13:

  • OpenSquare snapshot passed
9 Likes

The mandate proposal for the OpenGov Technical Committee is live on the forum.

2 Likes

Since this CP was made, new information has come to light regarding the electorate. We can include the balance of specific wallet addresses to be subtracted from the total supply in order to calculate the electorate, rather than defining an absolute electorate (like we initially did with 400M CFG).

Electorate

We propose to exclude the Treasury wallet (currently ~15.2M CFG) from the electorate. Given the only current inflation comes from block rewards (3% annually) - where the majority goes into the treasury - the only increase in the electorate should come from the amount that is paid out to collators from the block rewards.

Currently, the total supply is 546M CFG, so this means that the electorate would be 546-15.2 = 530.8M CFG which is an increase of roughly 33% compared to the initial 400M CFG.

In addition to the OpenGov parameters in this CP, we also propose to make some small changes to our governance templates.

Naming of CPs

Instead of using the RFC prefix in the forum post when the CP is created, e.g. “RFC: Centrifuge Migration to OpenGov”, use CPXXX, where XXX is the pull request # from the GitHub submission, e.g. “CP108: Centrifuge Migration to OpenGov”.
If the proposal has not yet been submitted to GitHub, XXX can be replaced with the actual number once it is.

Status of CPs

A CP can have the following status:

  • rfc
  • voting
  • passed/rejected

This should be indicated the forum post’s header (see section below) and tags as well as on GitHub, as the CP progresses through the stages.

Other tags to include in the forum post is:

  • tag of the component used (e.g. cp1, cp2, cp3, cp4 etc.)
  • tags specific for the CP (e.g. runtime-upgrade, governance-process, pool-fees etc.)

There is no need to include the month and year tags anymore, but the status tags are good for filtering topics on the forum, e.g. if you are looking for all ongoing CPs that are rfc or CPs that are being voted on.

Headers of CPs in forum posts + GitHub

To keep the forum post and the file on GitHub consistent, the same standard header should be used both places for all CPs:

cp: [XXX]
title:
authors: [forum handles]
contributors: [forum handles]
uses-component: [cp1|cp2|cp3|cp4|cp5|cp32|cp63]
technical proposal: [yes|no]
requires onchain: [yes|no]
status: [rfc|voting|passed|rejected]
date-proposed: [YYYY-MM-DD]
date-ended: [YYYY-MM-DD]

Note that it is possible to include more than one component in a CP, e.g. you can have a CP that uses both component CP2 and CP4 etc.

The CP2 component (Tresury proposals) should include two additional lines:

beneficiary: [name]
wallet: [wallet address]

See example in the screenshot below:

1 Like

Big fan of governance process optimization. In the long term, it will make more sense :heart:

It would be great if the author of the proposal submitted the proposal by himself (or ask GCG to help )
before publishing on the forum in a way:

  • To have the same CPXXX number with the pull request from day 1
  • To have a historical change of the proposal (in case if the proposal will be changed after the RFC stage or due to feedback received from the community).

So it would be cool to make a strict requirement to submit the on Git Hub first ( not applicable for discussion posts).

  • polling for off-chain voting on Opensquare

Should we also exclude the Bridge wallet since the bridge wallet account has the biggest amount of wCFG ( 95,000,000 wCFG) and wCFG can`t be used in voting?
Even if instant swapping is possible.

  • +status: [rfc|voting| polling |passed|rejected]

Additionally:

We need to update CP0 and add missed component:

CP63: cps/cps/CP63.md at main · centrifuge/cps · GitHub

1 Like

I like this idea and actually considered this as well and it would be ideal to do it this way but it could be difficult to ensure every time. If people remember to do it (or ask us), an “empty” PR with just the name of the file and the header can be created to get the PR# and hence CP# - then the rest of the proposal just needs to be added before it moves on to a vote.

But I will add it as a requirement to submit to GitHub before posting the RFC on the forum.

I think we can call them both voting - polling is a leftover word for when we started using OpenSquare snapshots instead of forum polls. We removed that part in the last change with CP52 so OpenSquare snapshots are optional, unless the outcome of the snapshot is binding or it is going to be part of RU/followed by an onchain vote straight after.

If we want to distinguish between the two types of votes we could use onchain-voting and offchain-voting - but for simplicity I think it makes the most sense to refer to both of them as just voting.

See above.

Seeing changes can be helpful indeed but personally I think it is the final version of a proposal that is the most relevant to add to GitHub but I am open for suggestions if this is something the DAO thinks could be useful to have. The changes can easily be tracked in the forum post though if someone wants to (either by reading the replies or checking changes in the main topic).

I think it is more relevant to see what the proposal is rather than what it could have been.

But just out of curiosity; how did you imagine to do this in the file on GitHub?

This is noted and will be added. Thanks.

Yeah, will be less confusing.

CP108 has now been updated based on the changes suggested in the replies above and been merged into the proposal repository on GitHub and is now final.

The OpenSquare snapshot has been published and will go live 6th May 15:00 CET and will be open until 13th May 15:00 CET (exactly 7 days).

:ballot_box: Please vote here: CP108: Centrifuge Migration to OpenGov

The OpenSquare snapshot for CP108 has passed.

The transition to OpenGov will be implemented in an upcoming Runtime Upgrade on Centrifuge (TBD). Our documentation will be updated asap to reflect the changes to our governance process that also passed with this CP.

Thank you for voting everyone!

1 Like