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

Implement XCM Custom Asset Claimer instruction #4190

Closed
2 tasks done
acatangiu opened this issue Apr 18, 2024 · 1 comment · Fixed by #4826
Closed
2 tasks done

Implement XCM Custom Asset Claimer instruction #4190

acatangiu opened this issue Apr 18, 2024 · 1 comment · Fixed by #4826
Assignees
Labels
I5-enhancement An additional feature request. T6-XCM This PR/Issue is related to XCM.

Comments

@acatangiu
Copy link
Contributor

Is there an existing issue?

  • I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

  • This is not a support question.

Motivation

XCM is an important feature of the Polkadot ecosystem that enables inter-chain communication and value transfer between ecosystem parachains. When assets (fungible or non-fungible) are transferred using XCM, they may be dropped due to miscellaneous errors during the execution. The probability of such an event is low, but it is not negligible, and dropped assets will need to be recovered to restore the user control of them. The process of such recovery is called "claiming", and the account that has the permission to perform it is called "claimer".

Currently, determining a claimer of dropped assets is implementation-specific, and there is no way to set a custom claimer. The implementation could choose a predictable claimer origin such as the same origin as the origin of the XCM message. But also, this choice could be arbitrary if there is no origin, e.g., if ClearOrigin was executed before an error happened.

The latter case includes reserve-based transfers. Given that parachains mostly rely on reserve-based transfers, a way to define a custom claimer for the dropped assets makes rescuing more convenient since it provides more ways to do so compared to an arbitrary claimer setting defined by a specific implementation.

Having this could become especially important when transferring multiple currencies or NFTs:

When transferring multiple currencies, one must choose a currency to pay execution fees. If there are insufficient funds in the chosen currency, all the assets will be dropped. And the dropped amount could be significant, so we need a convenient way to recover it.
When transferring NFTs, we must transfer some fungibles alongside them to pay fees. This is precisely the same situation as with multiple currencies. Also, an NFT representing a unique object could be subjectively very valuable to a user, so its dropping can be compared to dropping a large number of fungibles.

This RFC proposes adding a new instruction SetAssetClaimer. The new instruction sets a custom claimer to the dropped assets.

Note: If there is a need for complex claiming logic, a smart contract could be set as a claimer.

Request

Implement https://github.com/paritytech/xcm-format/blob/master/proposals/0037-custom-asset-claimer.md

Solution

Implement https://github.com/paritytech/xcm-format/blob/master/proposals/0037-custom-asset-claimer.md

Are you willing to help with this request?

Yes!

@acatangiu acatangiu added T6-XCM This PR/Issue is related to XCM. I5-enhancement An additional feature request. labels Apr 18, 2024
@acatangiu acatangiu moved this to Todo in Bridges + XCM Apr 18, 2024
@acatangiu
Copy link
Contributor Author

Since this is a new XCM instruction, it will be delivered with XCMv5.

These are the current XCMv5 planned changes: polkadot-fellows/xcm-format#60

I am hoping to get a polkadot-sdk XCMv5 implementation out around Aug/Sep (RFCs + impl + audit) - but depends on the level of engagement from the community and how fast the RFCs get approved

@franciscoaguirre franciscoaguirre mentioned this issue Aug 16, 2024
10 tasks
@x3c41a x3c41a moved this from Todo to In Progress in Bridges + XCM Aug 16, 2024
github-merge-queue bot pushed a commit that referenced this issue Nov 6, 2024
# Context

This PR aims to introduce XCMv5, for now it's in progress and will be
updated over time.
This branch will serve as a milestone branch for merging in all features
we want to add to XCM, roughly outlined
[here](polkadot-fellows/xcm-format#60).
More features could be added.

## TODO
- [x] Migrate foreign assets from v3 to v4
- [x] Setup v5 skeleton
- [x] Remove XCMv2
- [x] #5390
- [x] #5585
- [x] #5420
- [x] #5876
- [x] #5971
- [x] #6148
- [x] #6228

Fixes #3434 
Fixes #4190
Fixes #5209
Fixes #5241
Fixes #4284

---------

Signed-off-by: Adrian Catangiu <adrian@parity.io>
Co-authored-by: Adrian Catangiu <adrian@parity.io>
Co-authored-by: Andrii <ndk@parity.io>
Co-authored-by: Branislav Kontur <bkontur@gmail.com>
Co-authored-by: Joseph Zhao <65984904+programskillforverification@users.noreply.github.com>
Co-authored-by: Nazar Mokrynskyi <nazar@mokrynskyi.com>
Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>
Co-authored-by: command-bot <>
Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: Serban Iorga <serban@parity.io>
@github-project-automation github-project-automation bot moved this from In Progress to Done in Bridges + XCM Nov 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I5-enhancement An additional feature request. T6-XCM This PR/Issue is related to XCM.
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants