By default, Parity Vault uses the chain in derivation paths: If you make an account on polkadot, then you’ll have a derivation path like //polkadot//... If you make an account on AssetHub from the same secret words, then you’ll have a derivation path like //statemint//...
This means once relay chain accounts are migrated to AssetHub then if users simply import metadata for assethub and press the button to generate assethub accounts, then they’ll have a different public-secret key pair, without any affiliated balance, even after the migration.
Instead, migrated relay chain account holders should import metadata for assethub and when they say to generate a key they must manually edit the suggested //statemint//.. derivation path to //polkadot//... This will recreate the exact same public-secret key pair used by the realy chain account.
This must be done for each of your relay chain accounts.
See also Polkadot Support
4 Likes
Thanks for pointing out this potential headache with the AssetHub migration for Parity Vault users.
You nailed it – the way Vault handles derivation paths (creating different accounts per network) could really confuse people, causing them to not find their funds if they’re not careful with the manual derivation path changes.
It’s a tricky situation because Vault’s design was aiming for better security, but now we’ve got this UX challenge.
I’m curious to hear your thoughts on how you think this UX experience could be best addressed. What would be your approach to guide users through this process in the most user-friendly and error-proof way possible, minimizing the risk of funds being inaccessible post-migration?
3 Likes
I’ve no particular thoughts on outreach, but simply telling people in the different venues, like Reddit - The heart of the internet, https://substrate.stackexchange.com/, the major twitter accounts, etc. A short yt video might help some. etc.
Vault has good reasons for doing this besides reducing the privacy dumpster fire: If nonces advance sequentially, then you risk replay attacks when using the same key across multiple chains. We’ll maybe have some nice replay attacks in ETH roll up land. 
We hopefully use non-sequential nonces, which mitigates this, but if not then we do have some problems for non-Vault users too. Also sometimes Vault’s trick could be by project or app though, not by actual chain, so then if a project or app runs across 10 parachains then they all use the same keys.
I think UTXO coins like BTC typically do different keys for different UTXOs, unless maybe they use soft derivation paths, which provide nothing, so not exactly a new idea. Also, we really need stronger privacy measures, but that’s a whole other world of complexity, like see Zcash under the hood.
2 Likes