I have 2 scenerio

  1. Para A sends instruction to relay chain for sending tokens from Alice in Relay Chain to Bob inside relay chain using native relay chain tokens ( Remote transfer )

But the instruction initiates from Para A whereby Alice signs the txn.

let message = Xcm::<()>(vec![

                WithdrawAsset((Here, amount).into()),

                buy_execution((Here, amount)),

                DepositAsset { assets: All.into(), beneficiary: AccountId32 { network: None, id: BOB.into() }.into() },


                VanePalletXcm::send_xcm(AccountId32 { network: None, id: ALICE.into() }, Parent, message)

But it doesnt work.

But if I change the origin in the send_xcm call to be Here indicating using Para A soverign Account, then it works fine, but that will be sending the tokens from Para A to Bob and not Alice to Bob inside the Relay Chain

                VanePalletXcm::send_xcm(Here, Parent, message)

Does XCM not allowing signed sovereign accounts while sending xcm instructions to be processed remotely?

And the error message is not verbose enough it just indicates the execution's success is false.

1 Answer 1


This is a good question. In most situations, chains do not allow sovereign accounts to control funds for a local account with the same ID. So if Alice has ID 0x00... on Para A then she cannot control account ID 0x00... on the relay chain. As far as I understand, we do not allow this for two reasons:

  1. The relay chain does not trust Para A. Para A could sent a message to the relay chain with Alice (0x00) as origin while the message was never signed by Alice.
  2. If the relay chain does trust Para A and the messages are sent by the correct origin, it is still possible that Para A uses a different signature scheme then the Relay chain. So address 0x00... on Para A could be controlled by a different private key then the private key controlling address 0x00... on the relay chain.

There are different approaches to solve this problem:

  1. Alice directly transfers the funds on the Relay chain. She can do this using conventional extrinsics or by executing an XCM locally on the relay chain using the pallet_xcm execute extrinsic. Note that not all chains allow local execution of XCM using this extrinsic.
  2. The chain receiving this message maps the AccountId32 origin to some hashed accountId. For example AssetHubKusama and AssetHubPolkadot take this approach by using the HashedDescripion type. Lets say in your example instead of sending the message to the relay chain you sent it to AssetHub. The origin of the message would be:
MultiLocation {
    interior: X2(Parachain(*PARA A ID*), AccountId32 { network: None, id: ALICE.into() })

AssetHub would convert this origin to some unique address by hashing the AccountId32 id with some extra description describing the location the message originated from. It can be something like: hash("SiblingChain" + *PARA A ID* + "AccountId32" + id)

  1. In situations where there is a trust relationship between two chains and the signature schemes are the same, we can take another approach. For example, a system parachain like AssetHub could trust the relay chain. In this case AssetHub could configure it's xcm config to allow a sovereign AccountId32 from the relay chain to alias as local AccountId32 using the AliasOrigin instruction. This instruction would allow the sovereign user to replace the XCM origin from:
MultiLocation {
    interior: X2(Parachain(*PARA A ID*), AccountId32 { network: None, id: ALICE.into() })


MultiLocation {
    interior: X1(AccountId32 { network: None, id: ALICE.into()})

This instruction would be used before the WithdrawAsset instruction. However, as I mentioned, this would only be used in special circumstances where chains trust each other like system chains.

For the third implementation the Aliasers config item has to be configured to check if the origin of the AliasOrigin instruction is allowed to alias as the target in the instruction.

When the origin has Aliased as a local AccountId32 (like the example above), it is converted to an AccountId using the AccountId32Aliases location converter.

I hope this answers your question!

  • but one thing, It can be possible to make sure that, indeed the Alice in Para A is indeed the same one in Relay Chain as they both have same private key. I think XCM can be extended and have pre checks before sending a signed origin message which shoud execute remotely. Aug 25, 2023 at 16:59
  • Also concerning the Account Aliases, can this be possible at the moment but the message coming from Para A to be executing in Relay Chain Aug 25, 2023 at 17:06
  • I guess the real question is, the solution can utilise the Alias in the config. But the issue is atm configuring Alias is done manually and through a runtime upgrade, I think Polkadot should put a streamlined approach and utilise storage for individuals to configure Account Alias securely. Aug 25, 2023 at 17:26
  • If I understand your question correctly, you are talking about the Aliasers configuration item in the XCM Config, right? I do not completely understand your question about the storage for individuals. The Aliasers config item can only be set by the runtime developers and describes which locations can Alias. So it can be hardcoded to a single (or couple) of accounts or can be configured to allow all AccountId32s from a certain parachain. So again, the runtime developers decide which locations can Alias, and not any individual.
    – Just
    Aug 28, 2023 at 8:22
  • Yes as the last part, Parachain dev can configure to allow all AccountId32's of certain para to work. But as that is a good soln but what if the config actually just refers to a storageMap lets say in Para A -> (Account, Account), whereby the tuple indicates the Aliasing accounts set by individuals via an extrisnic. As for ex, u may not want to just allow all accountId32 of certain parachain but also manually configuring whcih accountid32's should alias as a developer. Aug 28, 2023 at 8:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.