Centrifuge - Open HRMP channels to support USDT, Axelar USDC, aUSD

Referendum 9 has passed with a SimpleMajority at block #1,234,302.

And was dispatched at block #1,234,303.
Referendum 9 enabled HRMP channels between Centrifuge, Statemint, Moonbeam and Acala.
Thanks, everyone for voting and participating.

1 Like

Hey community! Nuno here, cross-chain and protocol engineer at Centrifuge :wave:

The motion executed sucessfully on Centrifuge on block 123403. The XCM sent to Polkadot to execute hrmp init requests to Statemint, Moonbeam, and Acala was received on block 12028830 but it failed with a FailedToTransact error.

I am working on debugging what went wrong. As soon as we learned that lesson, we will need to re-submit this XCM call to the relaychain, meaning an extra step in the timeline.

My apologies, doing my best to get us going as fast and reliably as possible.
Will keep you posted!

Edit: Added links to block mentioned block numbers.



The most obvious reason for the failed execution on Polkadot is that I specified the DOT to be withdrawn in a 12-decimal base, whereas DOT is a 10 decimal asset. I based off that XCM call on the ones made in Kusama, where KSM is 12 decimals.

Once again, I want to apologise for my mistake.

I will be working on submitting a new pre-image that will batch:

  • Register GLMR (Moonbeam) in our asset registry; it has been decided that fees for Axelar USDC transfers will be done in GLRM so we have to register it. GLRM transfers through XCM have already been tested on the Moonbase Alpha testnet

  • PolkadotXcm.send
    Essentially the fixed call that has failed, now correctly specifying DOT in a 10-decimal base

Once I have submitted the pre-image, I will get in touch with the council to submit the council motion.

Thanks :pray:


Hi Nuno.

Thanks for the update, the transparent analysis and the quick fix.

Here is a noob question from my side: would it be possible, to “test” such upgrades on the Altair network (Centrifuge’s wild cousin) or can they be made only on Centrifuge chain because the configurations are totally different?

1 Like

All questions are welcomed!

We always thrive to first test everything on Centrifuge @ Rococo or Altair @ Rococo or on other testnets. In this case, we have tested with Centrifuge on Moonbase Alpha and we have also opened other chanels already on Altair @ Kusama.

Testing opening these Centrifuge/Polkadot specific channels on Altair/Kusama wouldn’t be very useful since indeed, the configurations are different: the parachain ids are different, the decimals of DOT and KSM are different, etc.

So in this case we have done everything we could have done to test everything out first on testnets, it just really came down to my mistake of confusing DOT decimals with KSM’s.

I hope that clarifies it :slight_smile:


Thank you for the fast fix and detailed explanation, as always!

1 Like

It’s my pleasure, I appreciate the engagement and understanding.

I have just submitted the pre-image described above with hash 0x297c5ad16534080a2af40e3de65636c0743ef6f31d125cfde270c70432d56a4d on block #1236568

1 Like

Good day
Council Motion 23 executed sucessfully on Centrifuge on block 123403. The XCM sent to Polkadot to execute hrmp init requests to Statemint, Moonbeam, and Acala was received on block 12028830 but it failed with a FailedToTransact error.

The issue was identified and addressed by @nuno and you can find the explanation here.

A new motion (Council Motion 24) has therefore been submitted. The details of Council Motion 24 are the same as for Council Motion 23 - the issue mentioned above has just been fixed.


Thanks again. “You can’t compare apples with pears” :wink:

Great job!

Hey, Community!

The last referenda was activated on block #1,257,060 and succeeded on Centrifuge. However, for the second time the XCM sent to Polkadot to batching hrmp init channel requests with Statemint, Moonbeam, and Acala has failed on block #12,076,308 , this time with a MaxWeightInvalid error.

This error means that the require_weight_at_most that I had specified in the Transact instruction of the XCM message was too low to cover for the weight costs associated with executing the batch described above.

First, I am sincerely sorry for my mistake. I understand this is frustrating and a bad look on me and it’s totally my bad and I apologise for that.

To get us going further as fast and reliably as possible, I have been in touch with the larger XCM community to have a look at the last failed call and ensure that only the require_weight_at_most was wrong and what conservative value we should set to not have this call failing again.

We learned that a single hrmpInitOpenChannel extrinsic has a weight of 677,297,000; Because we are batching 3, we see a total sum that’s just slightly above 3* that, at a total of

2,063,824,000. To play on the safe side, I am setting the require_weight_at_most to 6,000,000,000 (almost the triple). Any surplus will be refunded.

New PreImage

With that, I have submitted a new pre-image with all the values corrected and double checked.

:point_right: pre-image: 0xdc4ebe26e5131c30b214340d4710c119f50155c1ada855c1ff81efab243d7376

  • WithdrawAsset and BuyExecution with 30,000,000,000
  • Transact require_weight_at_most: 6,000,000,000 - covering expected max weight of 2,063,824,000
  • noted on block #1,261,477

My commitment is to 1) automate the creation of these pre-images to avoid further human error and to ensure that every call I submit as a pre-image is first ran and verified in a local environment that mimics the real one to the exact configuration.

I appreciate your patience and understanding :raised_hand:t2:


Good day Nuno
Thank you for continuously updating the situation even if the result is not like your expected.
But I guess that your experience is much more useful for others because thanks to your experience and described error next project can use it.
So this is a piece of very important knowledge for all Polkadot systems.

A person who never made a mistake never tried anything new (с)


Thank you for the update @nuno.

As Ivan mentions, this is an important experience and we are all learning as we move forward - no need to feel bad about it!

You (and the other devs) are doing a great job and this is just a minor thing in the grand scheme of successful updates - no harm has been done.


thank you for the update

reposting here

Good news! The Centrifuge motion #25 has been executed on block #1,281,810 on Centrifuge and on block #12127326 on the Polkadot relaychain :partying_face:

As explained previously, the next steps now involve waiting for Moonbeam’s, Statemint’s, and Acala’s accept+init requests which we follow with a final accept call.

More updates soon!
Thanks everyone for your patience :surfing_man:


Good day Nuno!
What is the next step?

Hi :wave:

Now we are waiting on a few things:

  1. On Axelar to register xcUSDC so that we can batch updating the USDC’s MultiLocation on our asset registry alongside with accepting Moonbeam’s hrmp channel request
  2. On Statemint accepting our request and sending us a request back
  3. On Acala doing the same as described on point 2.

As soon as we can move forward I will make sure to get us going!


Thank you Nuno for your fast and detailed reply.

1 Like

:raising_hand_man: :gear: :inbox_tray: :outbox_tray:
Hello Community :raised_hand:,

The Centrifuge Council just initiated Council Motion 37: Accept the Moonbeam and Statemint’s HRMP open channel request to Centrifuge.

You can find more information here: Council Motion 37: Accept the Moonbeam and Statemint’s HRMP open channel request to Centrifuge.

Hey all :wave:

The Polkadot referendum 74 aiming to open hrmp channels with Centrifuge amongst other parachains has failed. Quoting Joe from Web3 on the reason, in short:

The initial fix to prevent an exploit required that batched calls come either from a Signed or Root origin. A message from a parachain has neither. So, when Statemint sends a message to the Relay Chain to accept the five open channel requests, it will not be authorized to make a batched call.

The Centrifuge referendum 19 aiming to accept Statemint’s and Moonbeam’s hrmp openChannel requests will still succeed in accepting Moonbeam’s request but it will fail for Statemint’s since the latter has not been submitted successfully.

Moving forward, we hope to soon see the re-submitted, corrected motion from Polkadot. Afterwards, we will also have to open up a new motion accepting Statemint’s request.

Will keep everyone posted :surfing_man:


Good day Nuno
Thank you for keeping the Community always updated! :partying_face: :top:

1 Like