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
When an account gets moved from the Relay to the Asset Hub then we dont know whether it was a normal account or a derived one (xcm sovereign, utility::as_derivative, pure proxy, multisig).
Some of these will have the same derived account ID on AH, since they dont contain any pallet index or similar.
But others may have a different account id, that would make them inaccessible on the asset hub after the migration.
Having access to the same AccountId on different system chains is standard behaviour for keyed accounts, which is why I think it could make adoption easier if we allowed a way for that for keyless accounts.
One way to solve this would be to create a recover_relay_account(call: EncodedAhCall) call on the Relay chain call that can only be called from an AccountId origin, sends an XCM over to Asset Hub and allows to use the same AccountId on AH.
This is simpler than polkadot-fellows/RFCs#111 because both involved chains are trusted.
The text was updated successfully, but these errors were encountered:
Even in the linked RFC both chains need to trust each other, or better the receiving needs to trust the sending one. Actually I don't really get how your proposal here is different to what the RFC proposes, because it also just proposes to send the data to the other chain.
And if all the data is migrated, why aren't the proxies migrated as well?
Even in the linked RFC both chains need to trust each other, or better the receiving needs to trust the sending one. Actually I don't really get how your proposal here is different to what the RFC proposes, because it also just proposes to send the data to the other chain.
Ah right, I thought that it would be easier since there is a trust assumption, but the RFC also implies that.
Then the only difference is that this is a hacky version of it for the AssetHub migration, if we dont figure out the XCM changes in time 🫠
Or maybe we can use it to prototype the RFC and see how well it works?
And if all the data is migrated, why aren't the proxies migrated as well?
Yes we want to migrate the proxies pallet. This issue here is about arbitrary keyless accounts, not really caring about whether they are proxies.
When an account gets moved from the Relay to the Asset Hub then we dont know whether it was a normal account or a derived one (xcm sovereign,
utility::as_derivative
, pure proxy, multisig).Some of these will have the same derived account ID on AH, since they dont contain any pallet index or similar.
But others may have a different account id, that would make them inaccessible on the asset hub after the migration.
Having access to the same AccountId on different system chains is standard behaviour for keyed accounts, which is why I think it could make adoption easier if we allowed a way for that for keyless accounts.
One way to solve this would be to create a
recover_relay_account(call: EncodedAhCall)
call on the Relay chain call that can only be called from an AccountId origin, sends an XCM over to Asset Hub and allows to use the same AccountId on AH.This is simpler than polkadot-fellows/RFCs#111 because both involved chains are trusted.
The text was updated successfully, but these errors were encountered: