Use case:

Alice submits an extrinsic on chain A which, among other things, sends an XCM message including a Transact operation to chain B.

On chain A, Alice pays for the extrinsic execution. What I am trying to do, is to let Alice also pay with her account on chain B.

The XCM that is composed inside the extrinsic is the following:

    AccountId32 {
      network: None,
      id: dispatcher.into(),
  BuyExecution {
    fees: asset,
    weight_limit: Unlimited,
  Transact {
    origin_kind: OriginKind::Native,
    require_weight_at_most: weight,
    call: dest_tx,

where dispatcher is the signed origin on chain A, asset and weight are parameters of the extrinsic and must be under the control of Alice on chain B.

Clearly, I could only use a OriginKind::Native since otherwise the call would not have the parachain priviledge. Nevertheless, I cannot get the Transact to be executed without getting a BadOrigin error. It does not seem possible, right now, to have an OriginConverter which accepts a Multilocation of type ../Parachain(x)/AccountId(acc). The LocationConverter works fine with just using the provided Account32Hash<(), AccountId>, although a new PR is in the making to address this. On the contrary, origin conversion does not seem to be supported, and of course any attempt to insert a ClearOrigin call before the Transact would fail.

Is calling UniversalOrigin the only way to charge a user on chain B for the execution of the Transact? Or is there some other way to charge the user on chain B while still making sure that only the chain A can indeed send such XCM message? An OriginKind::SoverignAccount does not seem to be good for our case since everyone could just send it via the XCM pallet, while chain A wants to give chain B guarantees that the messages has higher priviledge then a simple user.


Your Answer

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

Browse other questions tagged or ask your own question.