AssetId always converted to Multilocation or errors with numbers other than 0

[Robiquet]

Bug report

At Zeitgeist we use pallet-asset-tx-payment to pay fees in other currencies. We use it like this:

const keyring = new Keyring({ type: "sr25519" });
const alice = keyring.addFromUri("//Alice", { name: "Alice default" });
const signedTx = await tx.signAsync(alice, {assetId: 0});

However now that we are using the latest version assetId is being forced into a Multilocation or in other cases it just errors.

Here are some examples:

const signedTx = await tx.signAsync(alice, {assetId: 0});
console.log(signTx.assetId) // {"parents": "0","interior": "Here"}

const signedTx = await tx.signAsync(alice, {assetId: 1});
console.log(signTx.assetId) // "Error: Struct: failed on assetId: Option<MultiLocation>:: Struct: Cannot decode value 1 (typeof number), expected an input object, map or array"

Moving forward we would like to use arbitrary values like this but run into similar issues:

const signedTx = await tx.signAsync(alice, {assetId: { ForeignAsset: 0 }});
console.log(signTx.assetId) // {"parents": "0","interior": "Here"}

const signedTx = await tx.signAsync(alice, {assetId: { ForeignAsset: 1 }});
console.log(signTx.assetId) // {"parents": "0","interior": "Here"}

Seems related to the changes made in this pr: #5752

• Please tell us about your environment:

• Version: 10.12.6

• Environment:

  • Node.js
  • Browser
  • Other (limited support for other environments)

• Language:

  • JavaScript
  • TypeScript (include tsc --version)
  • Other

[TarikGul]

If I am not mistaken you can add any typesBundle or typesSpec fields to override certain types when instantiating the ApiPromise. And you would set TAssetConversion to Option<AssetId> as seen here in the PR you referenced.

Moving forward we would like to use arbitrary values like this but run into similar issues:

I don't see the api supporting an input like { ForeignAsset: 1 }. IMO the asset passed in should always be a valid and explicit MultiLocation. Short cuts especially for something as specific as a multiLocation can cause unwanted behavior or bugs.

[sea212]

Is there a way to use anything else than MultiLocation as AssetId?

One pallet used to allow transaction fee payment with assets is a standard Substrate frame pallet pallet-asset-tx-payment. In the transaction validation function, it uses an AssetId that can be specified by the developer. It seems wrong to me to force the asset id type within the sdk when it is configurable in the pallet that processes the asset id on the blockchain side.

[TarikGul]

Is there a way to use anything else than MultiLocation as AssetId?

Yes, you should be able to do this by following what I wrote in the above:

If I am not mistaken you can add any typesBundle or typesSpec fields to override certain types when instantiating the ApiPromise. And you would set TAssetConversion to Option as seen here in the PR you referenced.

[Robiquet]

Thanks @TarikGul we managed to get it working with this change and signing with a keyring pair, see transaction here. However when we try to sign with an extension we get the following error:

I'm guessing this means that we need to add the overrides to this repo in a similar fashion to the asset hubs, what do you think?

[Robiquet]

Hi @TarikGul would you be able to take a look at this and let us know the best course of action?

[TarikGul]

I'm guessing this means that we need to add the overrides to this repo in a similar fashion to the asset hubs, what do you think?

I am not completely sure to be honest, what version of the extension are you using?

[Robiquet]

I'm using version 0.44.1. I think this is the issue because it looks very similar to this. It looks like the reason for it was that these changes to override the types had not yet been deployed. So it seems like we will need to add similar overrides for Zeitgeist