Cross-chain bridge for transferring assets between Phala and other blockchains.
location
must be a MultiLocation. For example, the location of KAR
is MultiLocation::new(1, X2(Parachain(2000), General(0x0080)))
. If your asset is an EVM asset, the location
should be MultiLocation::new(1, X3(Parachain(2004), GeneralIndex(chain_id), GeneralKey(erc20_address)))
. chain_id
should match the chain your asset deployed on. So far chain id of Ethereum is 0
, and chain id of Moonriver EVM is 2
.is mintable
represents whether your ERC20 smart contract support mint
and burn
, if set as true, your users will need to give the mint authority to our contract when the first time they use SubBridge. Check Assets Registration find more details about what we have done on registration.Thala
with polkadot-launch
. Check here to find more about polkadot-launch
.
For both parachain assets and EVM assets, the necessary step is to test the whole integration stuff on Rococo with the Phala team. The parachain registration on Rococo is maintained by Parity, if you are a parachain asset and you havenβt been a Rococo parachain, please notice the Parity team to onboard your chain on Rococo, also donβt forget to let them open HRMP channels between your parachain and Rhala network. If you are an EVM asset, please deploy an ERC20 asset on Kovan in advance, which will be used to config the EVM bridge. The architecture of the test net is as follow:
Rhala Testnet Architecture
Contract | Address |
---|---|
bridge | 0x0316Ea56000BCdB7D7EAED54fd70898a1fF90C09 |
erc20Handler | 0x7b11b07318E2E01b28A75da99F7EB8d635A6d46b |
0x7804e66ec9eea3d8daf6273ffbe0a8af25a8879cf43f14d0ebbb30941f578242
on your parachain0xA29D4E0F035cb50C0d78c8CeBb56Ca292616Ab20
on Kovanπ‘ Steps 1 - 3 are the stuff to open HRMP channels between our two parachains. You can directly jump to Step 4 if it has been done. Information of PHA are as follows:
Type | Value |
---|---|
Name | PHA |
Symbol | PHA |
Decimals | 12 |
ED | 0.01 PHA |
Location | MultiLocation::new(1, X1(Parachain(2004)) |
{ recipient: 2004 , proposedMaxCapacity: 1000, proposedMaxMessageSize: 102400}
0x3c00d4070000e803000000900100
Send HRMP Open Request
0x03000821040101009d1f02000000210001010002140004000000000700e876481713000000000700e876481700060002286bee383c00e7070000e803000000900100140d0100040001010070617261d4070000000000000000000000000000000000000000000000000000
, you can decode the call at page https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkhala.api.onfinality.io%2Fpublic-ws#/extrinsics/decode
Tips:
DepositAsset
should be an AccountId32
and put your parachain sovereign account public key to id field.π‘ Please let us know when the XCM message is executed successfully on Kusama, then we will propose to send an XCM message to receive the request and send open the request to your parachain at the same time.Step 3: Receive HRMP open request from Khala network HRMP channel is a one-way channel, which means you also need to receive our open request on your side or your parachain will not be able to receive messages from our parachain. The steps to receive the request from the Khala network are similar to the open request we did before. When the Khala network successfully sends the open request, you should do as follow:
{ sender: 2004 }
Accept HRMP Open Request
PHA
is MultiLocation::new(1, X1(Parachain(2004)). You may want to add it to your runtime XCM trader config according to your implementation.
Contract | Address |
---|---|
bridge | 0x8F92e7353b180937895E0C5937d616E8ea1A2Bb9 |
erc20Handler1 | 0xEEc0fb4913119567cDfC0c5fc2Bf8f9F9B226c2d |
erc20Handler2 | 0xcd38b15a419491c7c1238b0659f65c755792e257 |
Contract | Address |
---|---|
bridge | 0xCe6652551A989C13B41f70cac504341A5F711c8d |
erc20Handler | 0xf88337a0db6e24Dff0fCD7F92ab0655B97A68d38 |
Relayer | Address |
---|---|
relayer1 | 0xA97Dc452Ca3699c4Eb62171FE2f994ff7aE48400 |
relayer2 | 0xdca0f5B3686cc87415100808a2568879fE74E01a |
relayer2 | 0x4EE535bE2ce432151916E36B3c684E1dB8Cbf8c1 |
π‘ You should receive the update when we finish the registration.
dest
specification we defined previously on your client. The difference between doing crosschain transfer on a parachain and an EVM chain is that in the former case you will need to interact with the XCM implementation pallet on that parachain, while in the latter you will need to interact with the smart contract deployed by Phala.
Bridge.deposit
which is the interface to issue crosschain transfer we need to call ERC20 approve method to let user approve the specific amount of assets to ERC20Handler
contract of SygmaBridge. This operation will allow ERC20Handler
to spend up to the specific number of assets from the user account. After approval done, we can deposit asset through SygmaBridge contract. Luckily, Sygma has provided SDK to handle all of these stuffs, head to their SDK repo for more details.
We prepared the following 5 examples that almost covered all of the scenarios. If the transaction is issued on parachain, we have provided an encoded call you can decode on https://polkadot.js.app, and if the transaction is issued on EVM chains, we have provided a code snippet.
Example1: transfer an asset from Phala network to other parachain
An example of transferring 100 PHA from the Phala network to Moonbeam, the recipient address is 0xA29D4E0F035cb50C0d78c8CeBb56Ca292616Ab20
:
0xA29D4E0F035cb50C0d78c8CeBb56Ca292616Ab20
. Note small amount of PHA will be deducted as the fee of SygmaBridge:
Alice
. Karura XCM transfer based on the implementation of [xtoken pallet]https://github.com/open-web3-stack/open-runtime-module-library/tree/master/xtokens):
0xA29D4E0F035cb50C0d78c8CeBb56Ca292616Ab20
. Note small amount of PHA will be deducted as the fee of SygmaBridge: