Deep Dive | What Should Future Blockchain Wallets Look Like?

This article was published in Crypto Valley Live, authored by Billy Rennekamp, translated by Li Hanbo and Edward. In the forum post "Cosmos Hub as a Universal Wallet," I proposed a futuristic relationship between users and blockchains, involving a combination of the current Cosmos-SDK and upcoming features. The "sub-private key" (or Msg authorization) is referred to as the standard for Interchain Accounts (ICS-27) and the security of the Cosmos Hub itself.

This is an imaginative proposal, but it makes me think about the steps we need to take to enter a future that is secure and easy to interact with many blockchains. However, what exactly does this require? I propose a way forward that results in the separation of concerns and the establishment of a new class of wallets that create account coordination functionality.

Current Wallet Status

So far, we have seen many wallet solutions that attempt to do many things at once. Wallet functionality is still incomplete, but as we enter a world where users want to interact with many networks, the current non-scalable architecture fails to meet this demand. At a high level, the various responsibilities of a wallet include:

• Private key management

• Application interface

• Transaction management

Ethereum has experienced some of these growing pains because a Turing-complete virtual machine like EVM allows for almost any kind of application to exist, and they all expect to work from a single wallet. While Ethereum wallets have proposed protocols and clever solutions to provide interfaces for a wide variety of applications, they still expect these applications to come from a universal EVM infrastructure. As we see the emergence of specific application blockchains becoming a reality, the boundaries of how Ethereum handles various applications will be broken through IBC connections.

A practical approach is to separate concerns. Let these three tasks exist as independent solutions, each focusing on doing its unique task well. This will reveal a demand for a new type of service that I have been calling account coordination functionality.

Private Key Management

Cryptography is hard. If you are not an expert, the chances of making mistakes are high, and the consequences can be catastrophic. It is unfair to expect all wallet and dApp developers to have this expertise in-house. Traditional applications have recognized this and often solve it by delegating authentication to third parties using the oAuth standard.

You might think that the wallet's only real responsibility is to ensure your private keys are secure. But as I introduce other common functionalities, you will find that this is far from the case. In fact, this is often the capability that wallet builders are least equipped with. Cryptography and security experts should be responsible for developing industry-standard solutions and implementing best practices for private key storage. This should be their entire business; however, instead, we see that current wallets do a decent job in terms of security—but that is not good enough when it comes to cryptography.

If the responsibility for private key storage is removed from wallets, it could lead to more types of security solutions that rely on different assumptions and provide different functionalities. There are already many private key solutions that go beyond traditional software storage: hardware security modules like those in Ledger, or other cryptographic techniques like Shamir's secret sharing used by Torus, threshold schemes used by ZenGo, multiparty computation, or novel zero-knowledge technologies. I must emphasize that I believe the shared responsibility space for custodial private key management has also not been fully developed.

Regardless of how private keys are stored, the responsibility for storage solutions should actually stop there. It should do one thing and do it well—store private keys. Access to private keys should be handled by similar secure authorization technologies.

WalletConnect, or similar protocols for transmitting data between private key managers and applications, is where further authorization should occur.

Application Interface

Today, a wallet's scope of application interfaces is quite broad. On one hand, some wallets provide deep integrated access to application functionalities. Argent and Gnosis Safe support increasingly customizable interfaces on a per-application basis. This is also the route for most Cosmos wallets, where the network expects at least minimal stake and governance interfaces. Providing custom interfaces directly within the wallet means you can ensure a better user experience, but it limits the number of applications the wallet can access and restricts the wallet from becoming a new application.

On the other end are wallets that attempt to push most of the interface responsibility onto application developers. Generally, wallets use web3.js or cosmJS to connect an API or interface to the application. Alternatively, wallets may include their own browser and have already integrated APIs (Mist, Metamask Mobile, Status, and Coinbase Wallet). They can also leverage browser extensions to connect to APIs (Metamask, Keplr). WalletConnect allows interfaces to be transmitted between mobile and desktop browsers as well as between mobile devices. In either case, it is up to the application developers to access and utilize the wallet API to provide signing functionality for users. This path eliminates the wallet as a bottleneck for accessing applications but also brings its own challenges—namely, security and a smooth user experience.

A secure authorization technology should be considered to ensure that applications can access signing functionality without deterring users due to confirmation interfaces and without putting users in a position where they might accidentally sign something. MetaMask has been trying to address this issue by creating a composable secure interface for communication between private keys and applications, called "Snaps." It largely draws on the work of Agoric's chief scientist Mark Miller on object capabilities, which encode precise object-level control that can be transferred across environments. Snaps provide the security and standardization needed to connect applications and private key managers, but I believe Metamask has not gone far enough with this architecture, as all three wallet functions could potentially be isolated and composed using this model.

Transaction Management

While we have seen many wallets take on the heavy lifting of providing application interfaces, I still believe that, so far, the primary responsibility of wallets is private key management. This leaves the wallet's third responsibility—transaction management—seriously under-resourced. I would like to see this become the primary responsibility of wallets, as application interfaces and private key management become the responsibility of designated third parties.

Transaction management can be seen as the practical interface between applications and signing solutions. It is the step where requests for some operations are parsed into a format that can be signed by private keys. It involves communication with the application as well as communication with private key management. In between these two, the data that needs to be signed should be parsed and presented to the user in a way that they can understand what they are signing and why. Additionally, the history and status of these signing requests should be recorded and made available to the user.

When using Ethereum, transaction management is tricky because there is essentially only one type of transaction (eth_send), but it includes a data field that can reference any number of methods when targeting smart contracts. If you are lucky, the wallet can access the ABI file of the specific contract it interacts with, allowing the data field to be converted into function names and parameters. The ABI file also allows the wallet to display events emitted after a transaction is successfully processed. This enters the realm of block explorers, which are a complete service essentially dedicated to account history—and the history of the entire network. However, so far, block explorers have mostly been singular in their network focus.

In this space, there are many different messages that can be included in a transaction. Each of these messages has different functionalities but traditionally runs on its own, so there is no need for an external ABI file. With the migration to protobuf, we see ongoing discussions about how to retain these properties while ensuring all the performance improvements that protobuf brings. One option would be to use protobuf files like ABI, but there are many other solutions still being explored.

Regardless of the network architecture, this is a tricky issue, but it is crucial for ensuring that users can verify what they are actually doing. When additional private keys are added to this mix, the problem becomes even more complex. Some wallets already allow you to create many accounts, all derived from a common mnemonic and private key derivation path. This is a useful feature for users who do not want to mix their DeFi accounts with their gaming accounts. Private key derivation allows switching between networks, although I am not aware of any Ethereum wallet that allows you to merge accounts by supporting multiple mnemonics and private keys (though Keplr does). This places a burden on users to keep track of which identity is associated with which private key.

Account Coordination Functionality

Transaction management has been under-served, and as the number of networks and corresponding private keys increases, this issue will only become more severe. With the increase in the ability of sub-private keys to allocate account capabilities to specific private keys, this problem will multiply. The expansion of responsibilities warrants a new name for this role. I would like to propose a rationale for a new type of wallet that primarily focuses on being an account coordination service.

The main goal of account coordination functionality is to track which private keys have which functionalities on which networks—and how to access the signing capabilities of these private keys using protocols like WalletConnect. While it should strive for external privacy and anonymity, from the user's perspective, it should provide a comprehensive overview of all dApp, private key storage, and network activities. It may require a master public key from a private key mnemonic to derive all possible public keys. This would allow the account coordination functionality to check all possible accounts on all possible networks to see if you have ever interacted there. It will detect whether the private key is part of a multi-signature, contract-based wallet, group module, or sub-private key. With your confirmation, it will begin tracking all these accounts for you, remembering your preferences for when to use which private key.

Account coordination functionality should allow you to audit your interactions with each application while maintaining a coherent history—think of how Google’s oAuth tells you which services and devices you are currently logged into. Ultimately, this should look like a user-centric multi-network block explorer that tracks all your private keys and coordinates them on your behalf. This will require a wealth of information about the many networks you have interacted with or may interact with in the future. This information can be gathered from various sources and will depend on what kind of application you are facing. I envision that most of the information should come from the applications themselves, through interfaces like WalletConnect.

Account coordination functionality will firmly stand between your private keys and applications, acting as an intermediary between the two and joining all your interactions on blockchain-based networks. Its establishment will serve only you, so while it will hold your information repository, it will be solely up to you to decide whether to access it.