Feature Request: Add `ChargeAssetTxPayment` Signed Extension for Sufficient Assets

[joepetrowski]

When transacting from an account with 0 KSM, users should be able to pay fees using sufficient assets by specifying an AssetId in the ChargeAssetTxPayment signed extension.

Currently the UI does not recognize this:

Request: If an account possesses any sufficient assets, add an option to choose the fee-paying asset (and if they own no KSM/DOT, it should default to one of them).

[impelcrypto]

Hi @jacogr, I'd like to know if you have a plan to solve this issue. I'm also facing the same issue and hope to implement the request above on Polkadot.js.

[jacogr]

It is in the queue, so will bubble to the top of the list at some point.

Interest noted.

[fiexer]

This would make the USDT/C coming in from Statemine/Statemint so much more user-friendly to be used in XCM. Looking forward having this available 🙏 . Thanks for all your work you have been doing for the entire dotsama ecosystem @jacogr

[joepetrowski]

Any chance this could get done in the near future? USDT is sufficient on Statemint from ~10 Dec and would be nice to have this support.

[jacogr]

Will only be able to be done after I can get my hands on sufficient assets (it needs to be tested when done, cannot throw up untested code that could/couldn’t work)

Judging by the queue, unlikely to be looked at by me this year since there are tight 3rd-party deliveries elsewhere.

[fiexer]

Feel free to contact me @jacogr if you need assets to test. Do share your Statemint address so I can send you some USDt.

[jacogr]

@fiexer Thanks for the offer. My comment was certainly not "begging for tokens" - I will convert some for testing when the time comes and fund.

[marshacb]

Hey @jacogr, I'm currently working on adding ChargeAssetTxPayment support to txwrapper-core in advance of Statemint USDT becoming sufficient on Dec 10 and had a couple of questions. Would the correct steps be to add support for the AssetId as part of the ExtrinsicPayload type? Is there is a recommended way of testing a local polkadot-js branch and using/linking to it from another package?

Also, I wanted to know if you are alright with me and @TarikGul working on a PR for this if you didn't have plans to in the short term?

[jacogr]

Not sure I understand the first question - if you are asking about Polkadot-JS api support, it is already there and has been since the introduction of the signed extension in Substrate. Both in terms of having all the fields in the signed extension and mapping from signer options to the encoded extrinsic. (The apps UI is a completely different project, with the need for extra UI components and queries to fill all this in when passing data to the api - hence this issue as logged)

PRs welcome. (Just don’t get the question as to where this in intended based on this specific issue and your library usage. Sorry about being confused.)

[marshacb]

@jacogr In txwrapper-core we decode a signingPayload into an ExtrinsicPayload in order to log its transaction information. Since ExtrinsicPayload contains a tip but not an assetId (ChargeAssetTxPayment having an asset_id and tip) we assumed that perhaps this needed to be extended in order to support the signedExtension or at least for logging this field when decoding. Im still testing this so Im sorry for the confusion or if my understanding/assumption itself happen to be incorrect.

[jacogr]

Please log that as an API support issue in the correct repo and let's keep this specific to the apps UI - it is very difficult to cross tracks. This is not the correct place to get support on unrelated requests. (Hope you understand that, just trying to keep noise to a minimum and allow focus on the actual issue at hand)