<a href="https://forum.moonbeam.network/t/xcm-disclosure-invarch/2056">Forum post: InvArch XCM Disclosures</a>
<a href="https://forum.moonbeam.network/t/proposal-104-invarch-poposal-open-accept-hrmp-channel-and-register-asset-xcvarch/2057">Forum post: InvArch XCM Proposal</a>
<h2>TL:DR</h2>
This batched proposal is to Accept/Open an HRMP channel with InvArch and Register Asset xcVARCH
<h2>Summary</h2>
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:
<ul>
<li>Multilocation: {"parents": 1, "interior": {"X2": [{"Parachain": 3340}, {"GeneralIndex": 0 }]}}</li>
<li>Decimals: 12</li>
<li>Name: InvArch</li>
<li>Symbol: xcVARCH</li>
</ul>
xcVARCH will have the following asset ID and XC-20 address:
<ul>
<li>Asset ID: 231000050626813105388752285227530839203</li>
<li>XC-20 address: 0xffffffffadc8fdd0b273ab44ca6b38a7dcefe4a3</li>
</ul>
<h2>On-Chain Proposal Reference</h2>
On-Chain Proposal <a href="https://moonbeam.polkassembly.io/referenda/104">#[104]</a> with the associated hash: <code>0x45eafb9cab51ce419ba996cac40a329bab68567ad1d5b238995f0ddb99a1f948</code>
<h2>Technical details:</h2>
The procedure for opening the channels is as follows:
<ul>
<li>InvArch: already proposed to open an HRMP channel to Moonbeam</li>
<li>Moonbeam: democracy batched proposal:
<ul>
<li>Accept HRMP channel from InvArchNetwork to Moonbeam</li>
<li>Open Moonbeam to InvArch HRMP channel</li>
<li>Register xcVARCH asset as an XC-20</li>
</ul>
</li>
</ul>
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:
<ul>
<li>To accept the HRMP channel to Moonbeam: hrmp.hrmpAcceptOpenChannel(sender:3340) , which hex-encoded call data is <code>0x3c01f2070000</code></li>
<li>To open the HRMP channel from Moonbeam: hrmp.hrmpInitOpenChannel(recipient: 3340, proposedMaxCapacity: 1000, proposedMaxMessageSize: 102400), which its hex-encoded call data is <code>0x3c000c0d0000e803000000900100</code></li>
</ul>
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:
<ul>
<li>Withdraw asset: take funds out of the Sovereign Account of the origin parachain (in the relay chain) to a holding state</li>
<li>Buy execution: buys execution time from the relay chain, to execute the XCM message</li>
<li>Transact: provides the call data to be executed</li>
<li>Deposit asset (optional): refunds the leftover funds after the execution. If this is not provided, no refunds will be carried out</li>
</ul>
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 <a href="https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fwss.api.moonbeam.network#/extrinsics/decode">Moonbeam</a> is:
<blockquote>
0x1e020c6b09000c0d0000e803000000900100010401000100e40b5402000000000000000000000002286bee0200040001006b09010c0d0000010401000100e40b5402000000000000000000000002286bee0200040001001e00087200a3e4efdca7386bca44ab73b2d0fdc8ad010200313405000c1c786356415243481c496e76417263687300010200313405000000b48c31edd33c6800000000000000
</blockquote>

Send a batch of dispatch calls and atomically execute them.
The whole transaction will rollback and fail if any of the calls failed.

May be called from any origin except `None`.

- `calls`: The calls to be dispatched from the same origin. The number of call must not
  exceed the constant: `batched_calls_limit` (available in constant metadata).

If origin is root then the calls are dispatched without checking origin filter. (This
includes bypassing `frame_system::Config::BaseCallFilter`).

## Complexity
- O(C) where C is the number of calls to be batched.

- **Problem Statement:** Batched proposal to establish an HRMP channel with InvArch and register asset xcVARCH.
- **Significance:** Facilitating bi-directional transfer of GLMR and xcVARCH between Moonbeam and InvArch, with potential for broader use cases.
- **Proposed Solution:** Opening HRMP channels between Moonbeam and InvArch, registering xcVARCH asset, and executing necessary extrinsics for cross-chain transfers.
- **Expected Outcomes:** Enable XCM-based cross-chain transfers, streamline asset registration, and optimize XCM transaction costs to $0.02.

#104 InvArch Proposal Open/Accept HRMP channel and Register Asset xcVARCH

No Active Proposals