It was recently discovered in a Polkadot PR that parachains nowadays use the same MultiLocation to represent both the native token of the relay chain and its local derivative token.
While it is not harmful per se since it is not currently possible to teleport relay chain native tokens to parachains, the fact that one MultiLocation is being used to represent 2 different assets is not logically sound to me. If we push the analogy of file paths further, this phenomenon is akin to having a single path pointing to two different files.
Since there are quite a number of parachain projects that do such “location punning”, I am wondering how we should proceed forward on this point. Should we continue to ignore this and jettison the idea of “one MultiLocation, one asset”, or should we try and get everyone to not use the same MultiLocation for 2 different assets? I recall hearing from the parachain summit that someone wanted a sort of standardized asset ID issuance; perhaps this is related as well?
Can you elaborate on the potential issues this might bring? Because we have treated the derivative asset as a 1-1 mapping to the number of relay chain tokens held in the sovereign account. If this derivative asset cannot be burnt/minted was other than XCM, is this an issue?
Going further on this, say we used another multilocation (say, we created our own reserve that we mint everytime we receive DOT). Currently the scenario parachains are working with is that chains only accept reserve transfers if the token being transferred comes from its reserve chain. If we created our own reserve token with our own multilocation, this derivative could be transferred to other chains without any guarantee that we as a chain will maintain such 1-1 mapping with the DOT being held in our sovereign.
If the derivative is tied to the real asset multilocation, chains wont accept the derivative but rather the real asset only. So if someone tries to send the derivative to another chain, this should be able to reject it because it does not come from its reserve chain.
Have we as parachains made wrong assumptions here? If so we would be opened to discuss it.
Here, we need to be more explicit. How exactly are the derivatives transferred to another chain? Via reserve-backed asset transfers? If so, then it would have gone through the reserve chain to transfer such a derivative. If it’s via a teleport, then we all know it’s an extremely privileged operation, so we can safely assume that all necessary implications of sending a derivative asset to another chain is properly negotiated beforehand.
Thus, I don’t actually see any problems with transferring derivative assets to another parachain. It should be allowed, with the caveat being that there’s currently no way to directly transfer the actual derivative asset to another chain without some prior consensus on its method and side effects.
One thing I can immediately think of is if a community parachain decides to become a common good parachain. If they had previously used location punning, then they would not be able to differentiate between the reserve asset and the derivative asset, and this gets even more complicated when one assumes that the reserve asset is the relay chain’s native token, since that also becomes the native token of the current CGP parachain.
All in all, I don’t necessarily believe that using the same MultiLocation to represent both the reserve and derivative asset is wrong, but it is quite unexpected, as we may run into corner cases that I mentioned above. That said, I also somewhat understand the reasoning behind such a move – the implementation to send the derivative asset back to the reserve chain is simpler if both assets shared the same MultiLocation.
I am simply not certain whether we should really view this as a problem to solve, or simply let it be and let the community decide what’s best for themselves.
I think it is possible that this becomes a problem but unclear that it is a problem now. If it were to become a bigger problem in the future I think we would have much more information on how and why to solve it.
Can you elaborate on the potential issues this might bring?
I think it is reasonable to expect that parachains might prefer to allow other chains to transfer its asset directly between them rather than requiring cross-chain transactions to always flow through the reserve chain.
I think the same is likely true for the relay chains if we envision the future when XCM doesn’t necessarily go through them.
So I’ve talked internally within Parity, and the conclusion we arrived at is that the XCM executor that we currently have right now is opinionated, and will stay that way. Specifically to this case, because of the way it executes the InitiateReserveWithdraw instruction, it in fact does MultiLocation punning, when the spec does not explicitly say that it should.
Although I still think that a more generic approach to this problem should be adopted (i.e. making sure that the derivative and the reserve asset have different MultiLocations), it is currently not a priority now to change the logic of how InitiateReserveWithdraw is executed. Thus, for now, we’ll simply allow location punning.