Open HRMP channel between Phala and Acala

TL;DR

Similar with the earlier Khala proposal , we propose to open HRMP communication between Phala and Acala.

Summary

We propose to open a bi-directional channel between Phala and Acala. Initially, the main usecase will be to transfer PHA and ACA between the two chains, as a necessary step for the pre-proposal for list $PHA on Karura pools . What’s more, with Phala EVM bridge opened, user also can transfer ACA to the supported EVM chains directly.

Proposal

There is no on-chain proposal yet; #TBD.

Technical details:

The procedure for opening the channels is as follows:

  1. Acala propose to request to open Acala to Phala HRMP channel
  2. Wait until proposal on step 1 get approved & encated
  3. Phala propose to accept the request and request to open Phala to Acala HRMP channel(Batch call)
  4. Wait until proposal on step 3 get approved & encated
  5. Acala propose to accept Phala to Acala HRMP channel
  6. Wait until proposals on step 5 are approved & enacted
  7. Wait for another session on Polkadot for the change to be effective
  8. XCM based crosschain transfer will be possible at this stage.

The extrinsics that need to be executed on the relay chain , are:

  • For step 1: hrmp.hrmpInitOpenChannel(recipient: 2035, proposedMaxCapacity: 1000, proposedMaxMessageSize: 102400) , which hex-encoded is 0x3c00f3070000e803000000900100
  • For step 3: first call is hrmp.hrmpAcceptOpenChannel(sender: 2000), second call is hrmp.hrmpInitOpenChannel(recipient: 2000, proposedMaxCapacity: 1000, proposedMaxMessageSize: 102400), the batch call hex-encoded is 0x1a00083c01d00700003c00d0070000e803000000900100
  • For step 5: hrmp.hrmpAcceptOpenChannel(sender: 2035) , which hex-encoded is 0x3c01f3070000

The proposedMaxCapacity and proposedMaxMessageSize are set to the values of Polkadot configuration.activeConfig.hrmpChannelMaxCapacity and configuration.activeConfig.hrmpChannelMaxMessageSize values, respectively.

These extrinsics need to be called with the parachain’s sovereign account as origin. To achieve this, on the Phala side we will use polkadot-xcm pallet to send xcm message to the relaychain, by executing the following extrinsic from the parachain. Acala should make a open request call and a accept request call with its orml-xcm pallet.

polkadotXcm.send(
  dest: XcmVersionedMultiLocation
  {
    V1: {
      parents: 1
      interior: Here
    }
  }
  
  message: XcmVersionedXcm
  {
    V2: [
      {
        WithdrawAsset: [
          {
            id: {
              Concrete: {
                parents: 0
                interior: Here
              }
            }
            fun: {
              Fungible: 100,000,000,000
            }
          }
        ]
      }
      {
        BuyExecution: {
          fees: {
            id: {
              Concrete: {
                parents: 0
                interior: Here
              }
            }
            fun: {
              Fungible: 100,000,000,000
            }
          }
          weightLimit: Unlimited
        }
      }
      {
        Transact: {
          originType: Native
          requireWeightAtMost: 1,000,000,000
          call: {
            encoded: 0x1800083c01d00700003c00d0070000e803000000900100
          }
        }
      }
      {
        RefundSurplus
      }
      {
        DepositAsset: {
          assets: {
            Wild: All
          }
          maxAssets: 1
          beneficiary: {
            parents: 0
            interior: {
              X1: {
                AccountId32: {
                  network: Any
                  id: 0x70617261f3070000000000000000000000000000000000000000000000000000
                }
              }
            }
          }
        }
      }
    ]
  }
)

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

2 Likes