5

I've had a discussion with colleagues from Crust Shadow and Moonbeam(check here) about OriginKind usage in XCM's Transact instruction and thought it'd be best to ask here for further explanation.

Let's assume the following scenario between Shiden & Crust Shadow (because they share the same account scheme).

  • I want to send a XCM from Shiden to Crust Shadow, as a normal user (no special privileges)
  • on Shiden, I prepare a XCM which will be sent to Crust Shadow
  • instructions are DescendOrigin, WithdrawAsset, BuyExecution and Transact
    • Crust supports this instruction set and ordering
  • as part of Transact instruction, I have to select OriginKind
    • this can be either Native, SovereignAccount, Superuser or Xcm

I am aware of the OriginKind enum description here but am unsure which type is the correct one to use here. My understanding was that I should use Native since I want the destination (Crust) to interpret this as if I'm just a normal user (not with sovereign account privileges). In case I'd specify SovereignAccount, this would imply I want to execute something with Shiden's sovereign account privileges. I'd expect to be rejected in this case.

After discussion and repeated looks at the code, I guess my understanding was incorrect but it's still unclear to me how OriginKind should be interpreted.

Is Native only for cases when I want to execute XCM locally (e.g. via polkadot-xcm => execute call)?

1 Answer 1

9

You could find a lot of info in this file: origin_conversion.rs

Your focus is the difference between Native and SovereignAccount, I will try to explain these two first.

If you use SovereignAccount, it just signed(location). Buf if you use Native and send it to other chain, it will be wrapped in an Origin, may be Origin::Parachain(paraId), or Origin::SiblingParachain(paraId), or Origin::Relay, it depends on what is the sender chain and the xcm_config of receiver chain. And please note that if you choose Native and send from a parachain, it owns the parachain privileges, and you should use sudo or governance to send it(like request initOpenHrmp), otherwise it will match failed due to DescendOrigin change the origin location.


Let's see an example to compare SovereignAccount and Native: ParaA send XCM to relay_chain, transact call hrmp.hrmpCloseChannelRequests.

If you use SovereignAccount and send it to relay_chain, it will failed because ensure_parachain needs to make sure the account have sender chain privileges and is Origin::Parachain(paraId).

Then we should use Native and send it to relay_chain, converted by ChildParachainAsNative, it will be Origin::Parachain(paraId), and can pass the ensure_parachain.


OriginKind::Superuser can be used in a scenario like call assets.forceCreate(on statemint) from relaychain. We should send the XCM via sudo or governance, then origin will be converted by ParentAsSuperuser, it will be root and can pass AssetsForceOrigin.

1
  • 2
    Thank you @Guantong, this is a great and detailed answer! I did check the origin_conversion.rs file before but I must have interpreted the info differently. My understanding of Native and Sovereign in this case was swapped.
    – Dinonard
    Commented Sep 29, 2022 at 7:46

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.