[Proposal: 34] Proposal to Accept/Open an HRMP channel with Composable Polkadot and register xcibcMOVR, xcibcPICA, xcibcTIA, xcibcIST, xcibcBLD and xcibcATOM


This batched proposal is to Accept/Open an HRMP channel with Composable from Moonbeam and register xcIBCMOVR, xcibcPICA, xcibcTIA, xcibcIST, xcibcBLD to the Moonbeam Asset Registry.

The previous proposal failed due to an incorrectly submitted preimage. We have also renamed the tickers to xcibc prior to the original ticker upon the request of the communtiy.


Our proposal is to open a bi-directional channel between Moonbeam and Composable. The main use case will be the transfer of trust-minimised assets from:

  • IBC-enabled Cosmos chains on launch and Ethereum IBC once it goes live in late Q4.
  • Parachains on Kusama, including Moonbeam’s canary parachain, Moonriver.
  • Picasso and protocols built on Picasso, such as the Pablo DEX.

Tokens Metadata

Multilocation: { “parents”: 1, “interior”: { “X3”: [{ “Parachain”: 2019 }, {“PalletInstance”: 59 }, { “GeneralIndex”: “79228162514264337593543950355” }]}}
Decimals: 18
Name: IBC Moonriver
Symbol: xcibcMOVR
The UnitsPerSecond needs to be set 4025764895330112721

Multilocation: { “parents”: 1, “interior”: { “X3”: [{ “Parachain”: 2019 }, {“PalletInstance”: 59 }, { “GeneralIndex”: “79228162514264337593543950337” }]}
Decimals: 12
Name: Picasso
Symbol: xcPICA
The UnitsPerSecond needs to be set 16700847735031030

Multilocation: { “parents”: 1, “interior”: { “X3”: [{ “Parachain”: 2019 }, {“PalletInstance”: 59 }, { “GeneralIndex”: “79228162514264337593543950361” }]}}
Decimals: 6
Name: Inter Stable Token
Symbol: xcIST
The UnitsPerSecond needs to be set 24950099

Multilocation: { “parents”: 1, “interior”: { “X3”: [{ “Parachain”: 2019 }, {“PalletInstance”: 59 }, { “GeneralIndex”: “79228162514264337593543950354” }]}}
Decimals: 6
Name: Agoric
Symbol: xcBLD
The UnitsPerSecond needs to be set 170842046

Multilocation: { “X3”: [{ “Parachain”: 2019 }, {“PalletInstance”: 59 }, { “GeneralIndex”: “79228162514264337593543950355” }]}}
Decimals: 6
Name: Celestia
Symbol: xcTIA
The UnitsPerSecond needs to be set 10460251

Multilocation: { “X3”: [{ “Parachain”: 2019 }, {“PalletInstance”: 59 }, { “GeneralIndex”: “79228162514264337593543950355” }]}}
Decimals: 6
Name: Cosmos Hub
Symbol: xcATOM
The UnitsPerSecond needs to be set 2900232

Please note that we have included the extrinsic to register the assetspersecond of these assets in order to make them legible for payment of XCM execution fees. This is because when users bridge via any IBC-enabled Cosmos chain to Moonbeam, we have created pallet-multihop, which executes IBC and XCM messaging in one transaction. It is akin to a packet-forwarding middleware package to enhance UX.

Without registering the assetspersecond of these assets, users would be required to hold an asset on the Composable chain to pay for the XCM execution fees and therefore, disrupting the one-click bridging process.

We are committed to serving as the second trust-minimised transport layer to Moonbeam (the first being XCMP) and bridge liquidity for the entire ecosystem of users, developers and applications.

We are excited to facilitate initiatives to bring in liquidity to Moonbeam such as bringing IST to the ecosystem.

On-Chain Proposal Reference

On-Chain Proposal #[__] with the associated hash: _____________ (Will be included later today)

NOTE: Ensure that the parachain’s sovereign account contains at least 10 DOT to be locked as collateral (5 for each channel direction), plus some DOT to pay for XCM execution fees, as this is a prerequisite.

Technical details:

The procedure for opening the channels is as follows:

  1. The Composable team sends a channel request from Composable to Moonbeam via OpenGov referendum.
  2. Moonriver proposes to accept the Picasso to Moonriver HRMP channel and open a Moonriver to Picasso HRMP channel via this proposal [Moonriver Governance Batch call] and add xcPICA to the Moonriver asset registry.
  3. Wait until the proposal on step 3 gets approved & enacted.
  4. Picasso accepts the Moonriver to Picasso HRMP channel.
  5. Wait for another session on Polkadot for the change to be effective.
  6. Picasso proposes to register Moonriver’s assets.
  7. XCM-based cross-chain transfers will be possible at this stage.

The extrinsics that need to be sent with xcm messages so they can be executed on the relay chain are as follows for step 2:

  • xcmTransactor.HrmpManage.InitOpen(recipient: 2019, proposedMaxCapacity: 1000, proposedMaxMessageSize: 102400) , which hex-encoded is 0x6b0900e3070000e803000000900100010301000100e40b5402000000000000000000000002286bee02000400010700863ba10102000800

  • xcmTransactor.HrmpManage.Accept(sender: 2019, proposedMaxCapacity: 1000, proposedMaxMessageSize: 102400) , the call hex-encoded is 0x6b0901e3070000010301000100e40b5402000000000000000000000002286bee02000400010700863ba10102000800

If any user or dApp developer would like to see other assets from the Cosmos bridge to Moonbeam via IBC, please let us know in the comments.


Proposal Preimage: 0x25ebc1c5ae34630100853803fe1bde2d2633a54d52021ede14b2f303be48e5dd

Link to the on-chain proposal:

Before I place the decision deposit, can the community please confirm if these tickers are sufficient to mark distinctiveness?

If there are any objections please say them now sers

hey, it seems that the token symbols remain unchanged. @AlbertoV19, what do you think? should the token symbols also clearly denote their association with Composable?

Hey, I’ve changed all of the tickers to add ibc as an additional prefix to the symbol

E.g. xcATOM in the previous proposal is now xcibcATOM, xcTIA is now xcibcTIA etc

The new symbols do contain ibc in the ticket. That is the messaging protocol being used but not really the origin from which the assets are originating Composable

I’m not familiar enough with their IBC implementation tho, so maybe it is fine as is.


Funny how we’re really going to list composable wrapped Moonriver tokens before actual xcMOVR Moonriver tokens. Quite Ironic for a protocol that envisions multi-chain but has not found a way to connect to it’s Kusama-counterpart after more than a year.

I don’t know where the priorities of Moonbeam are at the moment but it doesn’t seem to be putting adoption, user friendliness or market traction anywhere on top. It looks like it keeps on building, but no one knows where to, what for or what problems it will really solve.

I see many projects reaching out to Moonbeam to list their XC variant but Moonbeam doesn’t reach out, the Metamask experience for GLMR looks to be half-finished since its inception; no ticker logo, no network logo, all very technical and not appealing to the eye. Does it want to fit the Polkadot ecosystem that bad? (pun intended)

Before I diverge too much from my actual point, Moonbeam needs some big fundamental changes. There is no point in giving out grants in a half-finished project that none knows about and none sees. Effort is better spent elsewhere at this point. There is no point in tipping the scale that much to the technical side of things.

The greatest diamonds in the crust of the earth that will never be dug up, will remain long after we’re gone. Great, yes, but unnoticed.

A roadmap would be amazing, some clarity for the community about everything ongoing, some goals, some partnerships, translating some github developments that normal people aren’t able to read would be nice. I think we can learn something from Astar here as the team has shown to be breaking away from the Polkadot narrative joke I made above.

For the masses to join Moonbeam you need to TRANSLATE. That’s it. Talk about everything in normal words, give information, these Moonbuilder programmes are not it! Moonbeam has been talking to it’s developers all this time! NOT to its community of holders and enthousisasts! Moonbeam is way too lazy here and relies on everyone to find out for themselves as if we’re all techies.

I am unsure of the route that Moonbeam is taking, it’s way too passive and laid back. This proposal just hits that nail.

hey, I find your comment a bit over emotional, tbh. not sure why you’re posting all this under the Composable proposal, coz it’s literally unrelated. but, okay

Composable is essentially a bridge, so there’s nothing ironic here. Composable will mint their bridged representation of MOVR, meaning it’s not native MOVR. you can already bridge MOVR to Moonbeam via the Synapseprotocol bridge, but there’s no liquidity yet

bridging Moonriver assets to Moonbeam via XCM will be possible when the BridgeHub system parachain goes live, which is currently in the development stage

Moonbeam continues to establish new HRMP channels with parachains, allowing ecosystem devs to introduce more use cases in their projects. these opened HRMP channels let projects deployed on Moonbeam create use cases for their users

Moonbeam keeps integrating with top-notch GMP protocols, enabling developers on Moonbeam to use these protocols under the hood. Moonbeam’s goal is to provide an ever-expanding toolkit for builders building dApps on top of Moonbeam

first and foremost, Moonbeam is a builder-focused platform, aiming to provide convenient and powerful tools to developers. this helps them build great use cases, allowing other projects to leverage these features. Moonbeam is always focused on builders. but, you can check out our blogs, where we always explain things: Recent Blogs and Tutorials About the Moonbeam Network

here, you can see Moonbeam’s strategic focus areas: Moonbeam: Powering Real-World Innovation with Web3 Partnerships

It also seems that Moonbeam CM is working on a roadmap @_phyn , and revamping the Ambassador program platform, which will launch soon. Ambassadors will help explain various topics and assist in building content to spread info to the broader community

regarding Moonbeam’s logos on MetaMask, I’ll tag @kevin, we discussed this a long time ago, and I’m not sure why it’s still an issue, but probably Kevin can clarify

1 Like