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

Hello Community :raised_hand:
We would like to share upcoming integration and several motions that will be:

  1. Motion #1 on Centrifuge
  2. Motion #2 on Polkadot / Statemint
  3. Motion #3 on Centrifuge

:dart: Goal

We want to open hrmp channels with:

  • Statemint - to support USDT XCM transfers, the first pools currency on Centrifuge
  • Moonbeam - to support Connectors v1 and Axelar USDC
  • Acala - to support aUSD XCM transfers

This articles describes all the steps and motions required to open hrmp channels with Statemint, Moonbeam, and Acala and register USDT, Axelar USDC, and aUSD on Centrifuge’s asset registry.

:stop_sign: Pre-Requirements

We need to get enough DOT into the Centrifuge parachain account on the Polkadot relay chain. This DOT will be used to pay for fees and deposits associated with initiating and acccepting hrmp channel requests.

:earth_americas: Process Overview

This visual illustrates the 3-step (minimum) process involved in opening hrmp channels between Centrifuge and another parachain bidirectionally.

We want to open channels with Statemint + Moonbeam + Acala, so we turn step 1 in the figure above into a batch call that will send an init request to the three parachains individually.

  1. Motion #1 on Centrifuge
    This first motion will send hrmp channel invites from Centrifuge to Statemint, Moonbeam, and Acala. It will also register USDT, Axelar USDC, and aUSD on the Centrifuge asset registry.
  2. Motion #2 on Polkadot / Statemint
    This motion will have Statemint accepting the request Centrifuge -> Statemint of motion #1 + init a request back, i.e, Statemint -> CentrifugeNote: The same motion needs to take place on Moonbeam and on Acala, but that’s not in our power to submit.
  3. Motion #3 on Centrifuge
    This third motion will serve to accept the hrmp channel requests that we will get back from Statemint when motion #2 is enacted and from Moonbeam and Acala once they accept the request we sent to them on step 1 and send us a request back.
    NOTE: we most likely want a seperate motion to accept each of these requests, since motion #2 may take over 3 months to be enacted and we don’t want to wait that long to accept Moonbeam’s and Acala’s channels requests which may take, say, 7-14 days to be ready.

:rocket: Motions Explained

→ Motion #1 @ Centrifuge

This motion will be sending the init requests for each parachain, that each respectivelly will then need to accept and send init request back.

Pre-image

The pre-image that we will submit on Centrifuge will be:

batch
    - pallet_xcm.forceDefaultXcmVersion(2)
    - pallet_xcm.send(<relay_encoded_call_opening_channels>)
    - batch
        - asset_registry::register(USDT)
        - asset_registry::register(Axelar_USDC)
        - asset_registry::register(aUSD)

where <relay_encoded_call_opening_channels> is the encoded relay-chain call that will be executing the following on Polkadot:

batch
    - hrmp.init(Statemint)
    - hrmp.init(Moonbeam)
    - hrmp.init(Acala)
    

NOTE : include hrmp.accept(Acala) if they send an init beforehand`

↳ Follow-up steps

1.1 Submit motion #2 (see below)
1.2 Ask Moonbeam to accept our request and send a request back
1.3 Ask Acala to accept our request and send a request back
1.4. New batch motion accepting the requests from Statemint , Moonbeam , and Acala (see motion #3 below)

→ Motion #2 @ Polkadot

Submit a motion on Polkadot to accept and init channels with Statemint.

The centrifuge motion #1 described above will send an init request for Centrifuge -> Statemint ; this step here should accept that request AND send a request back to open the inverse channel, Statemint -> Centrifuge .

TL;DR : We will submit a motion on Polkadot requesting to have Statemint executing the calls to 1) accept our hrmp channel request Centrifuge -> Statemint and 2) send a request for the inverse channel, Statemint -> Centrifuge that we will then need to accept.

The pre-image is submitted on Polkadot (Relay) and it proposes to batch these two calls:

  1. force transfer enough DOT from the Polkadot Treasury to the Statemint parachain account on Polkadot. This DOT will be used to pay for fees and deposits involved in having Statemint accepting the hrmp init request from our parachain and to send init request back to our parachain.
  2. send an XCM message from Polkadot to Statemint requesting to Transact (i.e., execute) a call in Statemint sending an XCM back to Polkadot, as root, that batches hrmp.init + hrmp.accept in Polkadot.

e.g : Open HRMP channel between Statemine and Kintsugi

→ Motion #3 @ Centrifuge

We can either batch this motion or submit three different motions, depending on the time that each parachain we are opening channels with. If Statemint takes 4 months to open channels but Moonbeam and Acala take 2 weeks, we should have a motion to accept Moonbeam’s and Acala’s requests first and a seperate one to accept Statemint later on.

Regardless, this motion should be:

batch
    - pallet_xcm.send(<relay_encoded_call_accepting_channels>)

where <relay_encoded_call_opening_channels> is the encoded relay-chain call that will be executing the following on Polkadot:

batch
    - hrmp.accept(Statemint)
    - hrmp.accept(Moonbeam)
    - hrmp.accept(Acala)

Source: Centrifuge - Open hrmp channels to support USDT, Axelar USDC, aUSD - HackMD.
Thank you @nuno for sharing this information.

:grey_question: If you have any questions, feel free to ask them :point_down:

8 Likes

Council Motion 23: Opening HRMP channels between Statemint, Moonbeam and Acala
:raising_hand_man: :gear: :inbox_tray: :outbox_tray:

The Centrifuge council has proposed a motion for opening the HRMP channel between Centrifuge and the parachains Statemint, Moonbeam and Acala. This will be made as a batch call that will send an init request to the three parachains individually. At the same time, USDT, Axelar USDC, and aUSD will also be registered on the Centrifuge asset registry.

  • Statemint - to support USDT XCM transfers, the first pools currency on Centrifuge
  • Moonbeam - to support Connectors v1 and Axelar USDC
  • Acala - to support aUSD XCM transfers

You can find more information here: Council Motion 23: Opening HRMP channels between Statemint, Moonbeam and Acala

8 Likes

Good day

Council motion 23 has passed successfully - Subscan | Aggregate Substrate ecological network High-precision Web3 explorer

Referendum 9 is now open for all CFG token holders to vote on.

The referendum will be open for all token holders to vote on for 7200 blocks (~24 hours) and will be closed at block #1,234,302

See the referendum on Subscan here .

:coin: :ballot_box: Please cast your vote here .

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.

4 Likes

Update

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:

4 Likes

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:

2 Likes

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

3 Likes

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:

2 Likes

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 (с)

3 Likes

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.

2 Likes

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:

4 Likes

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!

2 Likes

Thank you Nuno for your fast and detailed reply.

1 Like