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

Sending bridged DOT from AH to parachain fails after upgrade #281

Open
olanod opened this issue Apr 21, 2024 · 6 comments · Fixed by #311
Open

Sending bridged DOT from AH to parachain fails after upgrade #281

olanod opened this issue Apr 21, 2024 · 6 comments · Fixed by #311

Comments

@olanod
Copy link
Contributor

olanod commented Apr 21, 2024

Before the last upgrade at block 6793666 there's an example of a limited reserve transfer assets of DOT from Kusama asset hub to parachain 2281 which was successful, after the upgrade we can see another example at block 6814790 which fails with the error InvalidAssetUnknownReserve. It seems like a regression unless sending such foreign asset to a Kusama parachain is expected to be done differently now.

@joepetrowski
Copy link
Contributor

@olanod olanod changed the title Sending bridged DOT from AH to parachain fails after update Sending bridged DOT from AH to parachain fails after upgrade Apr 22, 2024
@acatangiu
Copy link
Contributor

Yes, it is an unintended regression.

The fact that we could do it before the upgrade with the old extrinsic was just "lucky". Once on the parachain, the extrinsic could not send it anywhere else (not even back).

The currently deployed runtime includes paritytech/polkadot-sdk#1672 and paritytech/polkadot-sdk#2388 which allow transfers of foreign assets in all directions within same consensus.

Unfortunately, for bridged assets the "smart logic" added to the extrinsics in above PRs doesn't work anymore because the code cannot determine anymore which chain on this side of the bridge is allowed to act as a reserve for an asset on the other side of the bridge.

For moving bridged assets around I created a new extrinsic paritytech/polkadot-sdk#3695 that allows the caller to force/override/specify reserve locations for "exotic" assets (where such information is not available in the runtime). I am also pushing for an offchain asset registry to hold this information: https://forum.polkadot.network/t/xcm-asset-registry/1168/3.
Unfortunately, paritytech/polkadot-sdk#3695 did not make it into AH 1.2.0 runtimes, but I plan to add it very soon in a AH runtime "patch upgrade".

@olanod
Copy link
Contributor Author

olanod commented May 13, 2024

@acatangiu will this be possible already in 1.2.2 ? how would the transfer extrinsic look like?

@acatangiu
Copy link
Contributor

acatangiu commented May 13, 2024

will this be possible already in 1.2.2 ?

Not possible yet in 1.2.2, I see on https://github.com/polkadot-fellows/runtimes/releases/ that 1.2.1, 1.2.2 and 1.2.3 were patch releases for other chains for other issues. Asset Hub runtimes latest release is still 1.2.0.

I'll try to get it in #288, but I can't promise I'll make it (many things on my plate).
You can try to do it yourself too (backport this new method from latest pallet-xcm to whatever pallet-xcm version was used in 1.2.0 - this can help you easily find which versions used where https://github.com/paritytech/psvm).

how would the transfer extrinsic look like?

Example test for bridged asset AssetHub->Parachain - the actual call used here.
Example test for bridged asset Parachain->AssetHub - the actual call used here.

In general, the emulated tests should cover all transfers scenarios and showcase how to do anything. Please let me know if you have a scenario not covered there.

P.S.: there's many other goodies on the way too: https://forum.polkadot.network/t/xcm-user-and-developer-experience-improvements/4511/21

@acatangiu
Copy link
Contributor

Backported for upcoming release: #311

fellowship-merge-bot bot pushed a commit that referenced this issue May 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants