In the forum post Cosmos Hub as Universal Wallet, I proposed a futuristic relationship between users and blockchains that involves a combination of current and upcoming features of the Cosmos-SDK: “Sub-keys” (or Msg Authorization); the Interchain Standard called Interchain Accounts (ICS-27); and the security of the Cosmos Hub itself (or theoretically any other secure network).
That was a sort of full-on expanding-brain proposal but it got me thinking about what steps are actually needed to take us into a future where it’s safe and easy to interact with many interconnected blockchains. I propose a path forward that results in a separation of concerns and a new class of wallet, called an Account Coordinator.
State of Wallets Today
To date we’ve seen a lot of wallet solutions that are trying to do many things at once. So far the list of responsibilities is still manageable, but as we move into a world where users will want to interact with many networks, the current architecture won’t scale. 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 already, since a turing complete virtual machine like the EVM allows for almost any variety of application to exist and they all expect to work from a single wallet. While Ethereum wallets have come up with protocols and clever solutions to provide interfaces for a wide variety of applications, they still expect these to be from a common EVM infrastructure. As we see the paradigm of application specific blockchains become a reality, connected via IBC, the bounds of how Ethereum has handled a variety of applications will break down.
The practical way forward is a separation of concerns. Let these three tasks exist as standalone solutions, where each can focus on doing its sole task well. This will reveal the need for a new kind of service that I’ve been calling an Account Coordinator.
Private Key Management
Cryptography is hard. If you’re not an expert, the chances of making a mistake are high and the fallout can be catastrophic. It’s unfair to expect all wallet and dApp developers to have this expertise in-house. Traditional apps have already recognized this and often separate concerns by delegating authentication to third parties using the oAuth standard.
You might think this is the only real responsibility of a wallet — to keep your keys secure. But as I go over the other common features you’ll see this is far from it. In fact it’s often the capacity that wallet builders are least qualified for. Cryptography and security experts should be responsible for developing industry standard solutions and implementing best practices for key storage. This should be their entire business, however instead we’ve seen wallets implementing “just good enough” security practices — but when it comes to cryptography this isn’t just good enough.
If the responsibility of key storage was removed from the wallet, it may result in a larger variety of security solutions that rely on different assumptions and provide different features. There are already a number of private key solutions that go beyond traditional software storage: hardware security modules like those in Ledger, or other cryptographic techniques such as shamir secret sharing used by Torus, threshold schemes like those used by ZenGo, multi-party computation, or novel zero knowledge techniques. For the record, I think the space for shared responsibility of custodial key management is also entirely underexplored.
Regardless of exactly how a key is stored, the responsibilities of the storage solution should really stop there. Do one thing and do it well — store the key. Access to the keys should be handled by similarly secure authorization techniques. WalletConnect, or a similar protocol for transporting data between key managers and applications is where further authorization should take place.
Application Interface
Today, the range of care a wallet pays towards an application interface is quite wide. On one side of the spectrum, some wallets provide deeply integrated access to application features. Argent and Gnosis Safe both support a growing number of custom interfaces on a per application basis. This has been the route for most Cosmos wallets as well, where networks expect a minimum of staking and governance interfaces. Providing a custom interface directly within the wallet means you can ensure a better user experience, but it limits the number of applications the wallet can access and turns the wallet into a bottleneck for new applications.
On the other end of the spectrum are wallets which try to push the bulk of interface responsibilities onto the application developer. Generally wallets inject an API or interface into an application using web3.js or cosmJS. Alternatively, the wallet may contain it’s own browser with the API already integrated (Mist, Metamask Mobile, Status, and Coinbase Wallet). They may also leverage a browser extension to inject the API (Metamask, Keplr). WalletConnect allows the interface to be transported between mobile and desktop browsers as well as between mobile and mobile. Either way, it’s up to the application developer to access and utilize the wallet API in order to provide a user with signing capabilities. This path removes the wallet as a bottleneck to accessing applications but comes with its own challenges — namely security and a smooth user experience.
A secure authorization technique should be considered to ensure that an application is able to access signing capabilities without overwhelming a user with confirmation screens or receiving authorization for unintentional transactions. MetaMask has been trying to address this by creating a composable, secure interface for keys to communicate with applications called “Snaps”. It borrows heavily from Agoric’s Chief Scientist, Mark Miller’s work on object capabilities, which encode precise object-level controls that can be transported across environments. Snaps provide the security and standardization needed to connect applications to key managers, but I’d argue Metamask doesn’t go far enough with this architecture, as all three wallet functions may be isolated and composed using this same model.
Transaction Management
While we’ve seen many wallets take on the burden of providing application interfaces, I’d still argue that to date the primary responsibility of wallets has been key management. This has left the third duty of a wallet, transaction management, sorely under resourced. I’d like to see this become the primary role of wallets as the application interface and key management becomes the responsibility of designated third parties.
Transaction management can be thought of as the actual interface between an application and a signing solution. This is the step where a request to perform some action is parsed into a format that can be signed by a private key. It includes communication with the application as well as communication with the key management. In between, the data that needs to be signed should be parsed and displayed to a user in a way that they can understand what they are signing and why. Furthermore 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 transaction type (eth_send) but it includes a data field that can reference any number of methods when aimed at a smart contract. If you’re lucky, the wallet is able to access an ABI file for the specific contract it’s interacting with that allows the data field to be converted into a function name and parameters. An ABI file can also allow the wallet to display the events which were emitted after a transaction was successfully processed. This gets into the territory of a block explorer, which is a full service dedicated essentially to account history — as well as the history of the entire network. To date however, block-explorers are mostly single-minded when it comes to networks.
In the Cosmos space there are many different messages which can be included in a transaction. Each of these messages have different capabilities, but have traditionally been self describing so there was no need for an external ABI file. With the migration to protobuf, we’re seeing ongoing discussions on how to preserve the self-describing nature while ensuring all of the performance increases that come with proto. One option will be to use in the protobuf file like an ABI but there are many other solutions still being explored.
Regardless of the network architecture, this is a tricky problem, but one that is essential to ensuring a user can verify what exactly they’re doing. This problem gets further complicated when additional keys are added to the mix. Some wallets already allow you to create many accounts which are all sourced from a common seed with key derivation paths. This is a helpful feature for users who don’t want to mix up their defi account with their gaming account (or their sketchy dark market wallet). Switching between networks is possible with key derivation, although I don’t know a single Ethereum wallet that allows you to consolidate accounts by supporting multiple seeds and private keys (Keplr does though). This puts the burden on users to keep track of which identity is associated with which key — and often which wallet contains any given key.
Account Coordinator
Transaction management has been under-served and the problem is only growing worse with additional networks and more corresponding keys. It will increase exponentially with the addition of sub-keys — the ability to assign account capabilities to specific keys. The expanded scope of duty warrants a new name for this role: I’d like to make a case for a new type of wallet that is primarily concerned with being an Account Coordinator.
The Account Coordinator’s primary goal is to keep track of which keys have which capabilities on which networks — and how to access the signing capabilities of those keys using protocols like WalletConnect. While it should strive for privacy and anonymity externally, from the user’s perspective, it should give a complete overview of activity across all dApps, key stores, and networks. It may ask for the master public key of a key seed in order to derive all possible public keys. This will allow the Account Coordinator to check all the possible accounts on all the possible networks to see if you’ve ever interacted there. It will detect whether the key is part of a multi-sig, contract based wallet, group module or sub-key. With your confirmation it will start tracking all of these accounts for you, remembering your preferences for which key to use when.
The Account Coordinator should allow you to audit the interactions you’ve had on each application while preserving a coherent sense of self — think about Google’s oAuth telling what services and devices you’ve currently logged into. Ultimately this should look something like a user-centric multi-network block explorer, tracking all of your own keys and coordinating them on your behalf. This will require a lot of contextual knowledge about the multitude of networks you’ve used or may interact with in the future. This context can be gathered from different sources and will depend on exactly which kind of app you’re dealing with. I imagine most information should be coming from the application itself over an interface like WalletConnect.
The Account Coordinator will stand firmly between your keys and the application, it will act as a broker between both parties and will join you in all of your interactions across blockchain based networks. It will be built to serve only you, so while it will have a treasure trove of your information, it will only be accessible at your discretion.
Next Steps
This proposal is just a feeling I have. I know there are other visions for the future of wallets and I’m looking for feedback and critiques. If you’re interested in discussing this proposal, drop by the Cosmos Forum and share your thoughts.
Post Script: Thoughts on Monetization
When wallets stop trying to do everything at once a number of business models become available. For example, providing a better user experience and holistic account overview allows a wallet to analyze personal activity and offer insights at a price. This information can remain private or may be monetizable with data brokerage applications like Ocean Protocol or other platforms that recognize data as labor. If the value of the service is great enough users may be willing to just pay a subscription fee, or pay to leverage their information in order to automate their tax filings.
Alternatively this Account Coordinator could offer various other services that users may be willing to pay for. For instance with regard to IBC connected networks, IBC packets are created with IBC transactions but, similar to Ethereum Meta-Transactions, someone has to relay those packets inside of new transactions to their destination networks. An Account Coordinator will be monitoring the creation of the initial transaction and could offer a paid service to ensure IBC relaying is taken care of and paid for.
With the addition of sub-keys it is expected that capabilities within networks will be finely tuned down to a per key permission system. That means that a user should expect to have hundreds if not thousands of keys that — considering best security practices — need to be rotated by various trusted threshold interactions. An Account Coordinator is exactly the entity to make those happen and would easily be able to charge for such a high value service.
One classic model that some Cosmos wallets are already following is to combine with staking services. They can promote their own validator over others and capture user delegations in order to earn staking rewards through a commission rate.
As the designated party who is crafting transactions on behalf of users, the Account Coordinator may want to include a small fee into the transaction, something which is especially easy using the Cosmos SDK where multiple messages can be grouped into a single transaction requiring only one signature. This could be set as a default but disabled and may eventually establish a new norm of tipping your wallet as a thank you.
Wallets have had trouble finding sustainable business models but the future is bright for them. With new capabilities comes new options and with a growing user base the demand will only increase for wallets which find the right balance between security, capabilities and ease of use. Hopefully the Account Coordinator can be a large step in that direction.
My name is Billy Rennekamp. I’m the Grants Manager at the Interchain Foundation focusing on the Cosmos Network. I’m a co-founder of Bin Studio, a multidisciplinary research, design and development studio based in Berlin. We built Clovers Network, a novel proof-of-work game supported by the ECF — Ethereum Community Fund. I’ve worked on a lot of other great projects including Gnosis, ENS Nifty, Meme Lordz and Doneth. If any of that sounds interesting to you, follow my twitter , my github or just say hello 👋
Join Coinmonks Telegram group and learn about crypto trading and investing
Also, Read
- What is a Flash loan?
- The Best Crypto Trading Bot
- 3Commas Review | Pionex Review | Coinrule review
- AAX Exchange Review | Deribit Review |FTX Crypto Exchange Review
- NGRAVE ZERO review
- Bybit Exchange Review | Bityard Review | Interdax Review
- 3Commas vs Cryptohopper
- The Best Bitcoin Hardware wallet | BitBox02 Review
- Ledger vs Ngrave
- Crypto Copy Trading Platforms | Bityard copy trading
- ledger nano s vs x
- Vauld Review | YouHodler Review | BlockFi Review
- The Best Crypto Tax Software | CoinTracking Review
- Best Crypto Lending Platforms
- Ledger Nano S vs Trezor one vs Trezor T vs Ledger Nano X
- BlockFi vs Celsius | Hodlnaut Review
- Bitsgap review | Quadency Review
- Ellipal Titan Review | SecuX Stone Review
- BlockFi Review | Earn up to 8.6% interests in your Crypto
- DEX Explorer and Blockchain APIs
- Crypto arbitrage guide: How to make money as a beginner
- Best Crypto Charting Tool
- What are the best books to learn about Bitcoin?
Top comments (0)