Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

On sending back Statemine assets to Statemine through XCM #925

Open
girazoki opened this issue Jan 21, 2022 · 3 comments
Open

On sending back Statemine assets to Statemine through XCM #925

girazoki opened this issue Jan 21, 2022 · 3 comments
Labels
T6-XCM This PR/Issue is related to XCM. T7-system_parachains This PR/Issue is related to System Parachains.

Comments

@girazoki
Copy link
Contributor

girazoki commented Jan 21, 2022

I have been thinking a lot on how to send statemine assets back to Statemine through xcm. I would like to discuss the inconvenients that I see when analizing possible solutions:

Problem statement:

  1. Statemine only supports paying for XCM execution in KSM
  2. Statemine assets are created as non-sufficient (i.e., the account to which you transfer needs to have a provider, tipically by transferring to it KSM > Existential Deposit).
  3. In order to be able to transfer back Statemine assets back to Statemine, we need to send both KSM and the corresponding asset (KSM to pay for the fees).

Point number 3 implies that the sovereign account of the parachain that is transferring back the Statemine assets holds KSM. This can be achieved by:

3.1. Doing a reserve transfer asset of KSM from Statemine directly to the parachain.
3.2. Manually funding the sovereign account.

If we go for 3.1, I think we need to distinguish between KSM that came from Statemine and KSM that came from the Relay. Let's imagine that we have SovRelay and SovStatemine. If we map KSM coming from both chains to the same token in the parachain, a user could drain one of the sovereigns. For instance, say SovRelay contains 500 KSM. A user could transfer 500KSM from Statemine to the parachain (SovStatemine +500), and then withdraw SovRelay, leaving those who want to interact directly with the Relay without the possibility to do so.

So that leaves us with the necessity of having to map those two scenarios to different tokens in the parachain (or at least, record somehow how many KSM came from Statemine and how many from the Relay). The problem I am encountering is that I am not entirely sure how to do this with the existing code. I think I would need to distinguish based on the Origin (as the MultiLocation would be identical in both cases), but I dont see how FungiblesAdapter could do this

If we go for 3.2, users could simply withdraw enough KSM so that the balance of SovStatemine account goes below ED, eliminating its provider reference. This would prevent any other asset from being sent from Statemine to the parachain until someone funds again the Sovereign account.

Any thoughts on this? Any possibility of accepting XCM fee payment in any other asset that is not the Relay Token? Dont know if I missed anything, but if so please feel free to point it out

Thanks in advance

@girazoki girazoki changed the title On sending back Statemine assets to Statemine trhough XCM On sending back Statemine assets to Statemine through XCM Jan 21, 2022
@xlc
Copy link
Contributor

xlc commented Jan 21, 2022

Also Statemine should at least accept self-sufficient assets for XCM fee, which is accepted for tx fee.
But yeah the DX for handling non-sufficient assets is nightmare to me.

@hbulgarini hbulgarini added this to To do in Common Good Parachains via automation Jan 21, 2022
@hbulgarini hbulgarini added the T7-system_parachains This PR/Issue is related to System Parachains. label Jan 21, 2022
@girazoki
Copy link
Contributor Author

I agree, but does Statemine as of today have an asset that is self-sufficient?

@KiChjang
Copy link
Contributor

As we discussed in chat, this is actually a general problem arising from recognizing two reserve chains for the same asset. The simplistic solution would be to recognize only Statemine as the only reserve chain for KSM, but this is not ideal because the relay chain should have the ability to be a reserve chain for its own native asset.

For book-keeping purposes, we'll thus need to pass around an XcmContext object so that it keeps track of the origin and other kinds of data pertaining to a particular XCM. Fortunately, there is a new PR that is trying to solve such an issue here. For a more immediate solution, I can currently think of extending the XCM executor or adding in more instructions as a means to provide more context to the received assets.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
T6-XCM This PR/Issue is related to XCM. T7-system_parachains This PR/Issue is related to System Parachains.
Development

No branches or pull requests

4 participants