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

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

Implement XCM Custom Asset Claimer instruction #4190

acatangiu opened this issue Apr 18, 2024 · 1 comment
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
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

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: In Progress
Development

No branches or pull requests

2 participants