When looking at Kusamas's pallet_xcm::Config we can see that it allows only the council to use send arbitrary XCM messages while it allows everyone to execute arbitrary XCM messages.

  1. Why is sending a more privileged operation than executing?
  2. Can't a user send arbitrary XCM by executing a wrapping instruction like InitiateTeleport anyways?
  3. What is it a user cannot do when they can only execute but not send?
  • hey Alexander, do you think this question was properly answered already. I am also interested in the rationale behind this.
    – Iker
    Jul 20, 2022 at 8:27
  • I was asking around internally at Parity but probably didn't asked the right people, yet. I have a vague idea but I don't want to speculate here. We just leave it open for now until somebody answers with confidence. Jul 21, 2022 at 18:01

1 Answer 1


Can't answer authoritatively on the 1st or 3rd, but maybe answers to the 2nd question may help illuminate.

  1. The answer is no, but let's list out all of the instructions that allow a user to provide an arbitrary XCM blob as a parameter and sends it onward to another destination:
ExportMessage // XCMv3 instruction

For the top 3, every time the XCM blob is sent to the intended destination, a ClearOrigin instruction is inserted right before executing the XCM blob, making it impossible for the XCM blob to run any privileged operations. Take for instance, the WithdrawAsset instruction and look at how it is executed:

WithdrawAsset(assets) => {
    // Take `assets` from the origin account (on-chain) and place in holding.
    let origin = self.origin_ref().ok_or(XcmError::BadOrigin)?.clone();
    for asset in assets.into_inner().into_iter() {
        Config::AssetTransactor::withdraw_asset(&asset, &origin, Some(&self.context))?;

Right on the first line, we see that it's trying to get a reference to the local origin register. Since the origin register has been cleared out via ClearOrigin, this line will fail and we won't be able to send and execute such an instruction via InitiateTeleport, InititateReserveWithdraw or DepositReserveAsset.

In addition, the two instructions InitiateTeleport and DepositReserveAsset requires the destination to whitelist the sender as a safe teleporter/reserve, adding another layer of security against arbitrary XCM executions.

For ExportMessage, there is a validation function that is called during the execution of it, which is controlled by the message exporter, so the responsibility of ensuring that nothing weird gets sent via the bridge is up to the bridge itself.

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.