Governance Update - Runtime Upgrade 4

Hello everyone,

We are excited to announce that we are ready to propose the next runtime upgrade to be voted by the community. RTU4 has been verified successfully in our testnets and a release has been cut on the centrifuge-chain repository.
As mentioned in the community call and in previous posts this upgrade enables token transfers, among other work around collator selection (more information on this to follow soon).

Proposal timeline sequence:

  • Monday 24th Jan EOD UTC: Council Motion to vote on externalProposeMajority on the preimage hash of the code upgrade (parachainSystem.authorizeUpgrade(…))
  • Monday 24th Jan EOD UTC: Council Motion to vote on fastrack on the preimage above with a delay on voting of 50,400 blocks (7 days @ 12s/block)

Proposed codeHash: 0xb7294a2baef2fa984a4b960de35d597301777481fc5ec08e0e5b9a1808267eb6

After these steps (Monday 24th Jan EOD UTC), the upgrade will be up for public referenda voting by the community for a duration of 7 days.
Let us know if you have any questions!

Motion started here:


Democracy vote for the implementation of Runtime Upgrade is now open!
Runtime Upgrade 4 will:

  • Removes the Sudo Key
  • Enables AIR transfers


codeHash: H256
proposal hash:

Everyone could vote with AIR : Aye or Nay
The upgrade will be up for public referenda voting by the community for a duration of 7 days

1 Like

I voted no because it would be priced low due to the bad condition of the market.

1 Like

Everyone could vote Aye or Nay!
Thank you for participating in governance voting!


Bonjour, donc toujours pas de jetons sur Kraken :frowning:

Salut, Kraken will distribute the crowdloan rewards after Runtime upgrade goes live. The voting is open around 2 more days

1 Like

How can it be that voting is still on? The screenshot from above is 9 days old and the referenda ist still running with 14 hours left. Could somebody please explain this?

1 Like

Good day Supermario

Timeline calculated in a base of produced blocks ( 50,400 blocks - please check the first message)
You can find the average time for producing each block here:


So if the time of producing 1 block will increase or decrease this will directly correlate with a deadline time

1 Like

This is the same way Polkadot and Kusama indicate roughly the deadline because nobody knows exactly the time of deadline and timeframe calculated in base of produced blocks.

Feel free to check by yourself this via link.


Thank you very much, I should have paid attention to the detais above. Do you also know how the target of 12 seconds is set and how this can or will be adjusted over the time running? Thanks in advance!

Oh unfortunately i don’t have enough knowledge to answer this question, but one of Team members for sure will be able to answer.

Hi @Supermario as @ImdioR mentioned the 12s is the target time that a parachain should take to produce and include a block. That is imposed by the relay chain (kusama or polkadot) to make sure consensus on the parachain and on the relay chain for the candidate block makes it on “constant” time and verifying and including blocks from one parachain doesnt affect finalization of other parachains.
In our case, we had a hidden issue in one of our collators that caused the higher times in block production since one of the authorities was not able to produce the next block in the slot allocated when it was its turn to propose.
That should be fixed now, and back to the expected throughput.