Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Asset Transactor on Asset Hubs not Working With Sufficient Assets #3958

Open
joepetrowski opened this issue Apr 3, 2024 · 12 comments
Open
Assignees
Labels
T6-XCM This PR/Issue is related to XCM. T14-system_parachains This PR/Issue is related to system parachains.

Comments

@joepetrowski
Copy link
Contributor

An account on AH should be able to transact using only sufficient assets (and not require DOT/KSM). However, something in the XCM Executor is preventing this right now.

Here is a local transfer that worked (using USDT as the fee asset to transfer USDT): https://assethub-polkadot.subscan.io/extrinsic/5982448-2

Here is an attempt to use XCM to send USDT to Moonbeam, which failed: https://assethub-polkadot.subscan.io/extrinsic/5982488-2

However, an account with KSM succeeded (constructing the transaction the same way): https://assethub-kusama.subscan.io/extrinsic/6717729-2


Notes:

cc @muharem @franciscoaguirre

@joepetrowski joepetrowski added T6-XCM This PR/Issue is related to XCM. T14-system_parachains This PR/Issue is related to system parachains. labels Apr 3, 2024
@muharem
Copy link
Contributor

muharem commented Apr 4, 2024

I could reproduce it locally, and the issue is that the fees which should be paid for xcm message delivery (e.g. xcm message sent to deposit reserved funds to a receiving parachain), right now can be paid only in a native currency. XcmRouter which implements SendXcm trait and provides a price for the message delivery, does not take into consideration which assets are provided by user and only attempts to change in a native currency.

In the third example provided above, the sender has some KSMs on it's account, and the fees for the message delivery paid in KSM.

@acatangiu
Copy link
Contributor

Charging delivery fees out of band bites us again 👹

#3434 will eliminate the problem completely, but that's XCMv5

should we try to fix it in XcmRouter in the meantime? we could go through asset conversion during charge_fees and charge native but swap whatever for that native..

@muharem
Copy link
Contributor

muharem commented Apr 4, 2024

@acatangiu I do not think it can be done just with a different implementation of existing contracts, I think the contract should be changed, to be similar to FeeManager.
@franciscoaguirre should know better.

@franciscoaguirre
Copy link
Contributor

I knew it'd be an issue that delivery fees use a completely different mechanism from weight and traders. We already have a good story around those two, now we need to integrate delivery fees into the mix.

This could be fixed in the meantime in the router, since we specify the asset id for paying fees there. We would need to swap USDT for DOT for example.

@Polkadot-Forum
Copy link

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/sufficiency-on-assethub/7095/23

@muharem
Copy link
Contributor

muharem commented Apr 15, 2024

I knew it'd be an issue that delivery fees use a completely different mechanism from weight and traders. We already have a good story around those two, now we need to integrate delivery fees into the mix.

Be weight mechanics you mean - WeightTrader, and by traders - FeeManager, right? It would be nice if we can use the same tools like SwapFirstAssetTrader in both cases.

This could be fixed in the meantime in the router, since we specify the asset id for paying fees there. We would need to swap USDT for DOT for example.

We can set it as USDT or DOT, or any other asset, but it can be only one of them. And it does not know what a user have or willing to use as an asset to cover the fee.

@joepetrowski
Copy link
Contributor Author

How come it can only be one? One of the main ideas of Asset Conversion was that the system technically only accepts one asset (DOT) for fee payment, but you can give it any asset, and if it's not DOT, then it will swap that asset for DOT. Maybe I am thinking at the wrong layer of the call stack, but there should be a "give it anything" entry point and then DOT should come out.

@muharem
Copy link
Contributor

muharem commented Apr 16, 2024

If I understood @franciscoaguirre right, in that sentence he is proposing a quick fix with no changes to the current contract. the current contracts lets as only set it to one asset, which is DOT now

@franciscoaguirre franciscoaguirre moved this from High Priority to In Progress in Bridges + XCM Apr 30, 2024
@Polkadot-Forum
Copy link

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/asset-hub-brainstorming-session-call-notes-and-discussion-continuation/7260/5

@franciscoaguirre
Copy link
Contributor

@muharem @joepetrowski I have the following PR tackling this: #4375

It's still work in progress for now. It breaks some API things but pretty minimal.
I already have some tests working for transfering only USDT or only a sufficient foreign asset.
I'm still fleshing out some other cases.

@Polkadot-Forum
Copy link

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/xcm-user-and-developer-experience-improvements/4511/21

@Polkadot-Forum
Copy link

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/asset-hub-brainstorming-session-call-notes-and-discussion-continuation/7260/7

@svyatonik svyatonik moved this from In Progress to High Priority in Bridges + XCM May 15, 2024
@svyatonik svyatonik moved this from High Priority to In Progress in Bridges + XCM May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T6-XCM This PR/Issue is related to XCM. T14-system_parachains This PR/Issue is related to system parachains.
Projects
Status: In Development
Status: In Progress
Development

No branches or pull requests

5 participants