## TL:DR

This batched proposal is to Accept/Open an HRMP channel with Shiden and to register the SDN token

## Summary

We propose to open a bi-directional channel between Moonriver and Shiden . Initially, the main use case will be to transfer MOVR and SDN between the two chains, but it can be further expanded to other use cases. The proposal also includes the SDN asset registration as xcSDN, with the following details:

- Multilocation: *{ "parents": 1, "interior": {"X1": { "Parachain": 2007}}}*
- Decimals: *18*
- Name: *SDN*
- Symbol: *xcSDN*

xcSDN will have the following asset ID and XC-20 address:

 - Asset ID: 16797826370226091782818345603793389938
 - XC-20 address:  0xffffffff0ca324c842330521525e7de111f38972

## Proposal

Proposal #24 with the following hash: *0x1574f7ff82961dce53de55ae1c545ab3655105c40b16dba92fe03057028034e0*

## Technical details:

The procedure for opening the channels is as follows:

 - Shiden: already proposed to open an HRMP channel to Moonriver
 - Moonriver: democracy batched proposal:
    - Open Moonriver to Shiden HRMP channel
    - Accept Shiden to Moonriver HRMP channel
    - Register SDN asset as an XC-20 
 - Shiden: democracy proposal to accept Moonriver to Shiden HRMP channel

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 open the HRMP channel from Moonriver: *hrmp.hrmpInitOpenChannel(recipient: 2007, proposedMaxCapacity: 1000, proposedMaxMessageSize: 102400)*, which its hex-encoded call data is *0x3c00d7070000e803000000900100*
 - To accept the HRMP channel to Moonriver: *hrmp.hrmpAcceptOpenChannel(sender: 2007)* , which hex-encoded call data is *0x3c01d7070000*

The *proposedMaxCapacity *and *proposedMaxMessageSize *are set to the values of Kusama’s *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 SDN value on July 8th 2022, targeting a XCM transaction cost of 0.02$.

If you are interested, the hex-encoded call data for this proposal in [Moonriver](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fwss.api.moonriver.moonbeam.network#/extrinsics/decode) is:

0x1e020c670001010002100004000000000700e876481713000000000700e8764817010700f2052a01060002286bee183c01d70700000d0100040001010070617261e7070000000000000000000000000000000000000000000000000000670001010002100004000000000700e876481713000000000700e8764817010700f2052a01060002286bee383c00d7070000e8030000009001000d0100040001010070617261e70700000000000000000000000000000000000000000000000000001e020c6900000101005d1f1853686964656e14786353444e120001000000000000000000000000000000016901000101005d1f9f732c79e022c54e04000000000000001700000000050411011da53b775b270400e7e61ed5cbc5a146ea70f53d5a3306ce02aaf97049cf181a43978d284fa908a0e6d41980ebc91eefffffffff0ca324c842330521525e7de111f38972181460006000fd

As a prerequisite, the parachain’s sovereign account must contain at least 10 KSM to be locked as collateral (5 for each channel direction), plus some KSM to pay for XCM execution fees.

 Transfer some liquid free balance to another account.

 `transfer` will set the `FreeBalance` of the sender and receiver.
 It will decrease the total issuance of the system by the `TransferFee`.
 If the sender's account is below the existential deposit as a result
 of the transfer, the account will be reaped.

 The dispatch origin for this call must be `Signed` by the transactor.

 # <weight>
 - Dependent on arguments but not critical, given proper implementations for
   input config types. See related functions below.
 - It contains a limited number of reads and writes internally and no complex computation.

 Related functions:

   - `ensure_can_withdraw` is always called internally but has a bounded complexity.
   - Transferring balances to accounts that did not exist before will cause
      `T::OnNewAccount::on_new_account` to be called.
   - Removing enough funds from an account will trigger `T::DustRemoval::on_unbalanced`.
   - `transfer_keep_alive` works the same way as `transfer`, but has an additional
     check that the transfer will not kill the origin account.
 ---------------------------------
 - Base Weight: 73.64 µs, worst case scenario (account created, account removed)
 - DB Weight: 1 Read and 1 Write to destination account
 - Origin account is already in memory, so no DB operations for them.
 # </weight>

Problem Statement and Audience:
- Problem Statement: The proposal aims to open a bi-directional channel between Moonriver and Shiden and register the SDN token.
- Audience: Polkassembly members and stakeholders interested in cross-chain transfers between Moonriver and Shiden.

Significance:
- The proposal allows for the transfer of MOVR and SDN tokens between Moonriver and Shiden, with potential for expansion to other use cases.

Proposed Solution:
- Open an HRMP channel from Moonriver to Shiden and accept an HRMP channel from Shiden to Moonriver.
- Register the SDN token as xcSDN with specific details.

Expected Outcomes:
- Enable XCM-based cross-chain transfers between Moonriver and Shiden.
- Facilitate the transfer of MOVR and SDN tokens between the two chains.
- Increase interoperability and connectivity between Moonriver and Shiden.

#102 Open/Accept HRMP channel to/from Shiden and Register SDN Asset

No Active Proposals