Add support of META-accounts: In META-account by default one private key will be used to generate accounts for each network, and users can replace accounts for each network individually inside META-account.

I like the idea, can you please detail a bit?
I understand you will, by default derive new account from one single seed, per network.
But you let the user replace those accounts ?

I like both ideas, but I am not sure I like the mix of those. I don't doubt you can make a UI that will tell the user "Hey we made a new account for you for network XYZ, here it is, if you prefer, provide your other seed". The thing is that, in 3 years from now, when it comes to restoring those account, it will be hard for users to remember HOW those meta accounts were generated. Sure you can offer to backup the meta-account-data but that's another backup to lose...

I wonder (open to brainstorm) whether it would not be better to support 2 types of meta accounts:

• derivated (the user has no choice, those are made from ONE seed)
• custom (the user provides seeds and derivation paths) per network

Multi-asset support: Mobile app will be connected to all supported Substrate networks and UI will allow users to manage utility tokens & features without switching to separate accounts and/or changing networks.

Sound cool, needs to be done to be 200% sure that the user has no chance to get confused and send to the wrong network though. I would love some details about how you plan on avoiding confusion and making it super clear.

other networks (e.g. parachains) will be integrated together with parachain teams, or added by the Fearless Wallet team without any grant communications

Can you explain more please ? it sounds like a big question mark here in terms of budget but your request is fixed already.

Thank you @chevdor !

There is a section in the proposal which has a description of accounts structure and use cases (it has some nice mockups as well!):
https://docs.google.com/document/d/18dZzjmcJFohA-jKaleaG1_PNGV_-1SfHozydeUw1ynk/edit#heading=h.qouwid3js8sa

However, let me address your questions here as well:

I understand you will, by default derive new account from one single seed, per network. But you let the user replace those accounts?

If user will want to replace certain account of certain network inside of their META-account (WIP naming), then they will need to tap on it, select "Change account" and basically they can create/import account for this specific network, which will be used in this META-account. Thus user will have N account which share the same private key, and new one which user just updated for certain network.

The thing is that, in 3 years from now, when it comes to restoring those account, it will be hard for users to remember HOW those meta accounts were generated. Sure you can offer to backup the meta-account-data but that's another backup to lose...

For exporting META-accounts with changed (custom) accounts, users can use "Export META-account" feature" which will basically export all account in Restore JSON format (Polkadot JS extension already can export all your account via one JSON, the same format Fearless Wallet will use)

I wonder (open to brainstorm) whether it would not be better to support 2 types of meta accounts:

Although derivation path is supported in Fearless Wallet, its still 1) advanced feature, thus most of the users don't know know what it is and why they need it 2) there is no standard in the ecosystem about how you should use derivation path, so that there will be interoperability between different apps in the ecosystem. There is a case with Trust Wallet currently - you cannot export Polkadot account from it and use it in Polkadot JS / Fearless Wallet / Polkawallet / Parity signer since they are using BIP32 derivation path, which is different from the one which is used by apps in Polkadot ecosystem.

That's being said, derivation still won't help you to achieve ONE seed for all the accounts, since some of the networks (e.g. Moonriver) will have restrictions to the certain crypto type which their accounts are using, thus we cannot use the same private key of SR25519 with the Moonriver accounts - Moonriver account has to be different.

Sound cool, needs to be done to be 200% sure that the user has no chance to get confused and send to the wrong network though. I would love some details about how you plan on avoiding confusion and making it super clear.

You can see how it's done now in Fearless Wallet - you cannot transfer DOT tokens to Kusama accounts, and vice-versa - the app will tell you that the network is different.

Can you explain more please ? it sounds like a big question mark here in terms of budget but your request is fixed already

If parachain uses default Substrate balances pallet and we can get utility token information from AccountInfo, then its relevantly easy for us to add support of this network. In fact, using Fearless Wallet open source libraries for iOS/Android, any mobile app can add support of working with Runtime metadata, which allows you to add support for new networks with the same pallets relevantly easy.

During our benchmarking & research, we have connected Fearless Wallet (without UI, just in the integration test) to several networks: Polkadot, Kusama, Westend, Karura, Moonriver, MoonbaseAlpha, Edgeware, Plasm, SORA, Darwinia, Kulupu, ChainX, Centrifuge, Subsocial, Statemine; and the app was able to retrieve balances of all tokens dynamically!

You can check the code in Fearless iOS repo in multiasset research branch: https://github.com/soramitsu/fearless-iOS/tree/research/multiassets

We have optimized Runtime usage for this (the app on Wallet tab will only keep in-memory those parts of Runtime which are needed for balances), and in fact, our tests showed that iOS app can handle up to 150 WebSockets connections with different runtimes! Pretty nice buffer before we hit that in the ecosystem :)

That's being said, for certain parachains there is more work to do, thus it's not fair to request funding from Kusama network for such case, and we will work with parachains individually for that. Also, we are doing base integration of utility tokens since its basically reusage of existing Substrate pallets, however for specific features (e.g. UI for parachain's DEX or other feature) we will discuss it with parachains as well