I was wondering is there any specific reason why Polkadot still does not support XCM execution from Computed Origins LocalOriginConverter - Apologies as I'm not a Substrate developer but I looked into the xcm_config.rs file in Polkadot's Runtime and I don't see SovereignAccountOf of LocalOriginConverter supported this.


I ask the question because LIDO was original using Moonbeam's Sovereign account and a utility.asDerivative to remotely transact on Polkadot via an index that was registered on Moonbeam via Governance. But if we allow Computed Origins on Polkadot, then this would open the possibility to everyone.

Is this something that is being looked at in the Polkadot Roadmap?

Thanks in advance!

  • You mean letting any user on an external chain have a sovereign account in Polkadot relay? Commented Oct 19, 2023 at 9:23
  • @FranciscoAguirre well I sure, I'm not sure what is the official name but in the past we've said "Computed Origins" or "Remote Origins" So that if there is a message received on Polkadot with "DescendOrigin", Polkadot can compute an account to dispatch from based on: blake2_256("ChildChain" | paraId | "AccountKey20" | address) This is from Moonbeam because of "AccountKey20".
    – AlbertoV19
    Commented Oct 20, 2023 at 10:31

1 Answer 1


A computed origin might be a lot of things, such as accounts on sibling parachains or even multisigs or other entities. Each of these computed origins needs to have a way to derive a sovereign account for use in a foreign chain. As we come up with more use cases where it's beneficial a particular entity (for example a collective voice or majority) can have a sovereign account then we can add more derivations with HashedDescription.

Right now, accounts on other chains do not have sovereign accounts on the relays or system parachains. There is a PR however that adds HashedDescription<AccountId, DescribeFamily<DescribeAllTerminal>> to the runtimes. This would allow almost many computed origins to have sovereign accounts, like accounts, pallets, treasuries on sibling chains, for example. It's still an open question whether that will go in the relay, since the goal is to move all the functionality to system parachains. The answer depends on how fast we can make the move and how necessary this ability is.

  • Thanks! I the idea here was so that Moonbeam could offer DOT liquid staking solution without relying on its sovereign account and "utility.asDerivative" as I know in the past there were some concerns and Gavin wanted to limited that specific call but we pushed back as it was the core route to provide a decentralized/trustless way to do remote executions on the relay Thanks again
    – AlbertoV19
    Commented Oct 24, 2023 at 9:12

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.