You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
# 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] #6228Fixes#3434Fixes#4190Fixes#5209Fixes#5241Fixes#4284
---------
Signed-off-by: Adrian Catangiu <[email protected]>
Co-authored-by: Adrian Catangiu <[email protected]>
Co-authored-by: Andrii <[email protected]>
Co-authored-by: Branislav Kontur <[email protected]>
Co-authored-by: Joseph Zhao <[email protected]>
Co-authored-by: Nazar Mokrynskyi <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>
Co-authored-by: Shawn Tabrizi <[email protected]>
Co-authored-by: command-bot <>
Co-authored-by: GitHub Action <[email protected]>
Co-authored-by: Serban Iorga <[email protected]>
Is there an existing issue?
Experiencing problems? Have you tried our Stack Exchange first?
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:
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!
The text was updated successfully, but these errors were encountered: