pub type ForeignChainAliasAccount<AccountId> = HashedDescription<AccountId, LegacyDescribeForeignChainAccount>;
👎Deprecated: Use HashedDescription<AccountId, LegacyDescribeForeignChainAccount> instead
Expand description

This is deprecated in favor of the more modular HashedDescription converter. If your chain has previously used this, then you can retain backwards compatibility using HashedDescription and a tuple with LegacyDescribeForeignChainAccount as the first element. For example:

pub type LocationToAccount = HashedDescription<
  // Legacy conversion - MUST BE FIRST!
  LegacyDescribeForeignChainAccount,
  // Other conversions
  DescribeTerminus,
  DescribePalletTerminal,
>;

This type is equivalent to the above but without any other conversions.

Old documentation

This converter will for a given AccountId32/AccountKey20 always generate the same “remote” account for a specific sending chain. I.e. the user gets the same remote account on every consuming para-chain and relay chain.

Can be used as a converter in SovereignSignedViaLocation

Example

Assuming the following network layout.

             R
          /    \
         /      \
       P1       P2
       / \       / \
      /   \     /   \
    P1.1 P1.2  P2.1  P2.2

Then a given account A will have the same alias accounts in the same plane. So, it is important which chain account A acts from. E.g.

  • From P1.2 A will act as
    • hash(ParaPrefix, A, 1, 1) on P1.2
    • hash(ParaPrefix, A, 1, 0) on P1
  • From P1 A will act as
    • hash(RelayPrefix, A, 1) on P1.2 & P1.1
    • hash(ParaPrefix, A, 1, 1) on P2
    • hash(ParaPrefix, A, 1, 0) on R

Note that the alias accounts have overlaps but never on the same chain when the sender comes from different chains.