TL:DR
This batched proposal is to Accept/Open an HRMP channel with InvArch and Register Asset xcVARCH
Summary
We propose to open a bi-directional channel between Moonbeam and InvArch. Initially, the main use case will be to transfer GLMR and xcVARCH between the two chains, but it can be further expanded to other use cases. The proposal also includes the VARCH asset registration as xcVARCH, with the following details:
- Multilocation: {“parents”: 1, “interior”: {“X2”: [{“Parachain”: 3340}, {“GeneralIndex”: 0 }]}}
- Decimals: 12
- Name: InvArch
- Symbol: xcVARCH
xcVARCH will have the following asset ID and XC-20 address:
- Asset ID: 231000050626813105388752285227530839203
- XC-20 address: 0xffffffffadc8fdd0b273ab44ca6b38a7dcefe4a3
On-Chain Proposal Reference
On-Chain Proposal #[104] with the associated hash: 0x45eafb9cab51ce419ba996cac40a329bab68567ad1d5b238995f0ddb99a1f948
Technical details:
The procedure for opening the channels is as follows:
- InvArch: already proposed to open an HRMP channel to Moonbeam
- Moonbeam: democracy batched proposal:
- Accept HRMP channel from InvArchNetwork to Moonbeam
- Open Moonbeam to InvArch HRMP channel
- Register xcVARCH asset as an XC-20
Once the HRMP channels are ready, XCM based cross-chain transfer will be possible. The extrinsics that need to be executed on the relay chain, are:
- To accept the HRMP channel to Moonbeam: hrmp.hrmpAcceptOpenChannel(sender:3340) , which hex-encoded call data is
0x3c01f2070000 - To open the HRMP channel from Moonbeam: hrmp.hrmpInitOpenChannel(recipient: 3340, proposedMaxCapacity: 1000, proposedMaxMessageSize: 102400), which its hex-encoded call data is
0x3c000c0d0000e803000000900100
The *proposedMaxCapacity *and proposedMaxMessageSize are set to the values of Polkadot/Kusama configuration.activeConfig.hrmpChannelMaxCapacity and configuration.activeConfig.hrmpChannelMaxMessageSize values, respectively.
These extrinsics need to be called from the parachain’s sovereign account as origin, via a democracy proposal. The proposal will use polkadotXcm pallet to send XCM message to the Relay Chain with the following items:
- Withdraw asset: take funds out of the Sovereign Account of the origin parachain (in the relay chain) to a holding state
- Buy execution: buys execution time from the relay chain, to execute the XCM message
- Transact: provides the call data to be executed
- Deposit asset (optional): refunds the leftover funds after the execution. If this is not provided, no refunds will be carried out
The asset will be registered with the metadata described in the summary. The setAssetUnitsPerSecond was calculated using the value for VARCH value on 2025-03-20, targeting a XCM transaction cost of 0.02$.
If you are interested, the hex-encoded call data for this proposal in Moonbeam is:
0x1e020c6b09000c0d0000e803000000900100010401000100e40b5402000000000000000000000002286bee0200040001006b09010c0d0000010401000100e40b5402000000000000000000000002286bee0200040001001e00087200a3e4efdca7386bca44ab73b2d0fdc8ad010200313405000c1c786356415243481c496e76417263687300010200313405000000b48c31edd33c6800000000000000
As a prerequisite, the parachain’s sovereign account must contain at least 20 DOT/KSM to be locked as collateral (10 for each channel direction), plus some DOT/KSM to pay for XCM execution fees.
