The multi-wallet future: perspectives on privacy & user experience
The future is multi-chain. The philosophy behind this vision concerns that use cases should be built on chains with optimized architectures. An on-chain order-book would therefore be built on a highly scalable chain with fast finality. A lending protocol may sacrifice some scalability for increased security and decentralization.
This means we will increasingly transact and operate across multiple-chains when interacting with Web3 apps. A key priority across Web3 teams is abstracting this process as much as possible and creating seamless multi-chain experiences. Cosmos Hub, for example, has released IBC which make sending messages & assets between different Cosmos chains as easy as apple pie.
An interesting consequence of a multi-chain future is that we are, by extension, also creating a multi-wallet future.
Blockchains require chain-native wallets to effectuate transactions. This is a core design feature. As a result, the more multi-chain we live, the more wallets we will create. Furthermore, it is not uncommon for users to create multiple wallets per chain. While there are many reasons a user may choose to do this, two obvious ones are privacy and security.
Multi-wallets for privacy: Wallets can be considered as on-chain identities with most blockchains tracking transactions and balances in a transparent ledger. As a result, many users choose to create multiple wallets to obfuscate some of their on-chain identity.
Multi-wallets for security: Hacks and exploits are still prevalent. The lazarus group has demonstrated that phishing and social engineering scams are remarkably effective to gain access to private keys. Security conscious crypto holders therefore hedge against such a risk by spreading assets across wallets.
A user may hold one Ethereum hard-ware wallet for long-term investments, another one for daily transactions to test new dApps, and yet another for curating their NFT collection. Now imagine multiplying this across an increasing number of Layer 1 and 2 chains. It is not hard to imagine Web3 netizens of the future will be managing dozens of wallets.
Managing two dozen wallets: Rise of the chain-agnostic wallet manager
The winning Web3 wallet will allow a user to intuitively interact with multi and cross-chain dApps, while abstracting away the long list of actual chain specific wallet interactions required to create such an experience.
Metamask, which started its product journey as an Ethereum wallet is increasingly supporting multiple EVM chains. In the future, through Metamask Snaps, they will even allow support for non-native blockchains and tokens, such as Bitcoin. While this is a welcomed user experience improvement, it still does not create an intuitive multi and cross-chain dApps experience. Currently, wallet interfaces require a user to select a single wallet when connecting to a dApp. This is cumbersome when an interaction may involve both an Ethereum and Polygon wallet, such as showing a combined lending position in a DeFi protocol.
A possible solution comes in the form of a chain agnostic API. The purpose of this initiative is to define a standard procedure for dApps to interface with wallets which govern accounts on multiple chains, as well as defining a set of rules to be followed during a given session. The latter is crucial as a chain-agnostic API has significant privacy and user experience implications.
Some Chain agnostic API perspectives on Security, Privacy and UX
To summarize, a multi-chain future will create an equally multi-wallet future. This is a nightmare from a user-experience perspective, with users creating and managing dozens of wallets. Wallet companies will compete for users by solving this issue and a promising solution will be extend wallets to support multiple wallets per chain as well as multiple chains. A chain agnostic API can then allow dApps to call multiple wallets across multiple chains creating a great user experience. Problem solved? Not quite.
In the discussion above on why a user may opt to create multiple wallets, core concerns revolve around security and privacy. It is too early to understand exactly how users will react to dApps interfacing with a broad swaths of wallets simultaneously, however these two factors must be carefully considered in any design choices. Specifically from a privacy perspective, users may feel uncomfortable passing on an array of all their wallet identities to any given dApps. To draw a real-world comparison, we do not list all our bank account numbers when making a single payment.
Possible solutions will likely begin with education. A wallet owners should always be conscious of which data from which wallets are connected to a dApp. Another interesting possibility would be to enable users to cluster wallets into different 'profiles.' For instance, a user may be an avid NFT collector and holds NFTs across an Avalanche, Arbitrum, and Solana wallet. At the same time, this user also does algorithmic trading and uses multiple Bitcoin and Ethereum wallets to run their bots. This user may create an "NFT" profile for connecting with NFT dApps, permissioning the chain agnostic API to only interface with the Avalanche, Arbitrum and Solana wallets. The "Trading" profile would allow trusted apps to connect with the Ethereum and Bitcoin wallets.
With proper education, such a "privacy profile" feature could become an extremely powerful user experience tool. Similar to how we may have a more public social identity across social media platforms and increasingly private identities across friend groups, payments, investments, we can architect similar distinct identities that will be aggregated from the multi-wallet future. chain with fast finality. A lending protocol may sacrifice some scalability for increased security and decentralization.