Reserve transfer DOT/KSM shouldn't work #2398
Comments
No, it's not. This is supposed to work. |
|
Can you elaborate more on how does it work? If someone reserve transfer DOT from Statemint to Acala without any involving Polkadot. Acala won’t have those DOT on polkadot. Then how can Acala user transfer those DOT to Polkadot? |
Right, because they are on Statemint.
Send an XCM program to Statemint telling it to teleport the DOT to the Relay with your user's beneficiary account. |
|
Ok. I will need someone to write a detailed documentation on how to deal with two reserve chains. How to track balances. How to move funds between reserves. How to handle edge cases. How to handle reserve migration. Otherwise I will insist multi reserve is a bug not a feature. |
The reserves track them. That's literally what a reserve is.
Teleport.
?
Your parachain is an entity itself in the network. Companies for example have bank accounts in multiple countries to manage paying employees in multiple jurisdictions. It is up to the companies to manage those, you don't ask the banks to sort out your payroll. The parachain origin controlling its sovereign accounts on multiple chains is very powerful, and XCM is language you can write quite powerful programs with to do that management. But one thing I completely agree with you about is needing more documentation and examples of common user stories. |
How does parachain track balances on difference reserves? e.g. Parachain A have 100 DOT on Polkadot. 200 DOT on Statemint. User want to XCM 300 DOT to parachain B. Explain in detail how would this work? Yeah it is parachain's job to implement this but I do believe it is reserves' job to ensure the integration implementation is developer friendly. On top of that, how exactly parachain know the balances on each reserves? Do we track it locally? Which is impossible to make it precise. e.g. It is not possible to accurately determine fees before an action. Then we need to sync local balance and remove balance and then we have rate condition to solve. This isn't as easy as "The reserves track them. "
When to move? How much to move? How to handle race conditions? How to handle errors? Do we want to actively rebalance the funds across different reserves?
I believe the long term goal is remove DOT from relaychain and therefore it will no longer be a reserve. So again we need a very detailed migration plan or like any undocumented "features", it is a bug. |
Yes but I don't see how that's relevant or a bug. There isn't a detailed migration plan because there are lot of things to figure out, like how staking and governance will work when they are on different parachains. We fully expect multiple reserve locations to exist for other assets, including parachain tokens like ACA. If you teleport ACA to Statemint, users can then reserve transfer it to another parachain (let's say para 3000). Users can also reserve transfer from Acala to para 3000. Para 3000 then has two reserve locations for ACA. So it's not like two reserves is just a temporary thing to deal with until DOT is off the Relay Chain. Yes, DOT will move off the Relay Chain, but that doesn't mean dealing with two reserve locations of an asset is an issue that's going away nor that it's a bug. |
|
Maybe relevant to the conversation: #925 (comment) |
cumulus/parachains/integration-tests/statemint/xcm/4_hrmp.yml
Line 183 in 066db6b
It shouldn't work but it worked??
The correct way to transfer DOT/KSM from system chain to community parachain is teleport it to relay and reserve transfer to para. But instead it just do the normal reserve transfer of non-reserve asset which shouldn't work.
While Statemint was designed to be the reserve chain for relay token, but I don't think this thing can be enabled currently. It doesn't make sense to have a token to have two reserve chains.
Also it refers to KSM in the statemint tests, but it should be DOT.
The text was updated successfully, but these errors were encountered: