The word “wallet” gets used a lot, but is rarely defined. Whether you're fresh to web3 or a seasoned veteran, you've likely felt this confusion. Even worse: maybe you don't know you're confused? Let me explain.
In each of these questions, "wallet" refers to a completely different part of the Wallet Stack: a
Wallet Client, an
Account & Account Address, and a
Recovery Method—which itself infers the existence of a
Colloquially, calling every part of the stack a "wallet" isn't an issue. For many people right now, they all indeed feel like the same thing. Where the problem becomes real is in the UI copy itself.
Across and within various
Wallet Clients, the word wallet leaks inconsistently into the user experience. It's no wonder people get confused. For new users this can be misleading. For experienced users it may never be clear what's actually going on underneath.
Let me pick on Coinbase Wallet for a moment to ground this in an example. Not only are they the most successful brand in blockchain, they are also one of the worst abusers of the word wallet.
To enter Coinbase Wallet's world, one must:
Wallet Client), which will prompt you to
Recovery Methodthat will generate a password protected
Wallet Structure), at which point
Accountsidentified by their unique
Because many people only go through this flow once, and never bother going into settings, their confusion may be fleeting. But can you imagine what internal Coinbase Wallet sprint planning looks like? "Alex, can you fix the bug with wallets being derived non-deterministically from the wallet a user imports into the latest version of our wallet?"
Poor Alex. Poor us.
Those of us designing and building need to be more precise. So: let's get precise.
A couple of notes: This post uses Ethereum examples, but the ideas hold true for smart contract enabled chains in general, and will be identical in practice for all EVM compatible chains. You’ll also notice I’m explicitly not using the word dapp. If a dapp is software whose backend is strictly hosted on a blockchain, that is a subset of all apps. I believe all apps will have wallet interactions in the near future.
When someone asks "Which wallet should I use?" what they're really asking is "Which wallet client should I use?"—examples being Metamask, Rainbow, Coinbase Wallet, a Ledger Nano, or a Gnosis Safe. The
Wallet Client is the interface they'll use to connect to an app, sign messages and transactions, and manage their on-chain assets.
A wide variety of
Wallet Clients exist, and the list grows daily. To thoughtfully recommend one, it's important to know a bit more about a person's intentions. What's their threat model? Which chain(s) are they going to be using? What do they want to do in web3?
Even with clear answers to those questions, making the right recommendation can be complicated. There are just so many options out there. It’s helpful to think about the ways you can categorize
Wallet Clientto manage the financial activity they’re engaged in on-chain: monitoring their portfolio value, or swapping and staking assets. But, over the past year we've seen
Wallet Clientssuch as Autonomy and Rainbow begin to support viewing and interacting with an NFT collection, and even constructing public profiles. These features address the emerging desire to garden on-chain identities—or rather, inventories.
Wallet Clientsfocus on support for a single blockchain ecosystem: Metamask on Ethereum, Phantom on Solana, Kepler on Cosmos, or Kukai on Tezos. But there are options that support multiple chains from a single interface. Trust Wallet may have the broadest blockchain support out of the box, while Metamask has begun supporting additional blockchain networks via its 3rd party Snaps add-ons. Single chain
Wallet Clientstend to be more mature and have better UX, but multi-chain clients are the final destination.
Wallet Clientsrely on Externally Owned Accounts (EOAs) under the hood and require a single signature to “okay” a transaction—we'll explain this in more depth shortly. When you want to up your security, diversify your recovery paths, bundle transactions, set spending limits, or support other sophisticated organizational workflows, there are also contract-based clients. Gnosis Safe and Argent are examples of contract-based clients that enable features such as multiple signatures (multi-sigs) to process a transaction. Beware: not all apps support multi-sigs directly.
Wallet Clientspull triple duty in the web3 space, handling: private key management, application UI, and transaction/asset management. Billy Rennekamp explains how this could be restructured with his proposed Account Coordinator pattern.
Wallet Clientto an app using a wallet transport layer like Wallet Connect. Or you’re hoping your
Wallet Clienthas decided to emulate Metamask.
Wallet Client, launch its in-app web browser, and then paste the URL. Once again, implementing
Wallet Connectin your app helps alleviate this and allows your users use their mobile browser of choice. As a sidenote, most web3-enabled apps are neither responsive nor mobile-friendly; it is imperative that developers and designers adopt a mobile first approach to user experience.
Wallet Clientscontinue to engage in user research to identify the right mental models and terminology to support them—with a mind towards localization as well!
When someone asks "Which wallet should I send this to?" what they're really asking is "What's the account address I should send this to?"—the long base-58 string that identifies your account on the chain.
So, what exactly is the account that address identifies? Well, there are two distinct types.
Externally Owned Accounts (EOAs):
Though Contract Accounts are becoming more common, most people still have EOAs. This is because, even if you use a Contract Account, an EOA must still be present somewhere in the chain to trigger the action you want to take—though there are plans in motion to address this with Account Abstraction.
With both types of accounts, the
Account Address is the way that you refer to it in a transaction.
Most folks can’t just remember and rattle off the 20 byte long base-58 string that is their
Account Address. So, protocols such as ENS allow a human-readable alias to be mapped to any address. The result is that I can invite you to send tips to
depatchedmode.eth (🤑) instead of forcing you to test the limits of human memory (and typing skills). Many apps and
Wallet Clients support these aliases in both directions: raw addresses will show up as ENS domains when they exist, and pasting ENS domains in various places will resolve to their underlying addresses.
It is worth underscoring that you can change the address your ENS domain points to, in case you migrate to a new primary account in the future. Because of this, an ENS domain can be a more stable way to identify yourself to other people in much the same way that your phone number remains stable as you move from one home to the next.
Nothing. Surprised? This is one of the reasons that many people say a "wallet" is a broken metaphor. When you think of a wallet, you imagine a thing that:
The blockchain account you’re managing in your wallet shares neither of those characteristics. A blockchain account:
Account Addresshow do you know which chain or network they are targeting? This hasn’t been a problem in single chain
Wallet Clients, but in a multi-chain world this problem becomes very real. There are technical standards to address this, but still not many user experience best practices.
When someone asks "Can I import my wallet?" what they're really asking is "Can I use my recovery method in this wallet client to rebuild the wallet structure that contains all of my accounts?" Bit of a mouthful, I know. Let’s break it down.
Let’s start with the
Recovery Methods. These do exactly what you’d expect: help to recover your accounts or set them up for the first time on a new device. There are a lot of potential ways to design recovery methods, but let’s focus on the two standards-based approaches most commonly supported by
Wallet Clients today:
These recovery methods are incredibly powerful! They help your
Wallet Client consistently derive what we’ll call the
Wallet Structure: the list of all your accounts and the private keys that control them.
"Wait—what do you mean ‘derive’? Why don't you just say ‘create’?"
Because—brace yourself—every possible account in any blockchain address space already exists 🤯. Check out Dmitri Cherniak's Dead Ringers for a visually sumptuous example of this in action. So, we say derived because your
Recovery Phrase is used to discover a specific public/private keypair that controls an account.
“But wait… how do you avoid two people getting access to the same account?”
Incomprehensibly large numbers of things. There are so many possible accounts that, even though we’re deriving keypairs for them randomly, the odds of generating the same one twice are infinitesimally small. You have a better chance of hitting the moon by throwing a rock. But a well designed
Recovery Method lets you derive the account deterministically.
“Wait—can you clarify what you mean by ‘deterministically’? Just so I’m sure.”
We say it is deterministic because the same
Recovery Method will derive the same keypairs 100% of the time. Almost all
Wallet Clients achieve this through the magic of Hierarchical Deterministic Wallets (HD wallet)—the most common
"OMG, yet another thing called a wallet!?" Yes.
It's a tree of accounts derived from a single root keypair, and originated in the Bitcoin world as BIP-32.
An HD Wallet is a pretty interesting construct because, using BIP-44, a
Wallet Client can walk what's called a derivation path and “discover” all the accounts that have associated on-chain activity—magic! This aspect of an HD wallet's tree of accounts is pretty under-explored. Most wallet clients support just a single account, or a single layer of accounts. But technically you can have children accounts, and grand children accounts, and so on. There’s no limit to the number of levels!
Now, I’m but a simple designer. There are many reasons to be cautious about how HD Wallets are used, and how many accounts and child accounts you tie to a single recovery method; as they say, don’t put all your eggs in one basket. But, it seems worth investigating them more deeply as a means of addressing at least part of the account composition problem. Not everybody has the same threat model.
Diverse Threat Models: Even software professionals are not security experts. It’s hard for most people to know exactly how much time and energy they should put into securing their assets—a problem that is not unique to blockchains—and what sort of practices they should routinely engage in to monitor and respond to changing circumstances. This practice is called threat modelling. There’s a lot of room for building tools and practices that help increase awareness and default people into the practices that best fit their current threat model.
Accessibility: Though recovery phrases push accessibility forward a bit, the BIP-39 spec explicitly states “it is strongly discouraged to use non-English wordlists.” The vast majority of people on Earth speak no English. So many things in this space carry with them the baggage of the programming languages that support them being English and ASCII prime.
Fragility: You only have to make a mistake with your recovery mechanism once, and then it is compromised—or lost! You may not even realize you’ve compromised or lost your recovery method until it’s too late. It’s hard to strike the right balance between ensuring a Recovery Method is at hand when you need it, but that also secured against theft. Vitalik has written a great introduction to the importance of Social Recovery as an alternative approach moving forward:
So, I hope you've got a clearer model of how the pieces of the Wallet Stack weave together. And the next 10 times you feel the word “wallet” on the tip of your tongue, I hope you momentarily pause to check that you’re using the most precise term you can.
I hope that, in the next Coinbase Wallet sprint, someone asks “Alex, can you fix the bug with
accounts being derived non-deterministically in the
wallet structure when users input their
recovery method in the latest version of our
wallet client?” It’ll take some practice, but over time it’ll pay dividends for us, our collaborators, and the ecosystem as a whole.
Is there any single piece of the Wallet Stack that we can simply call a “wallet”, though? In Glen Weyl, Puja Ohlhaver and Vitalik Buterin’s latest white paper “Decentralized Society: Finding Web3’s Soul”, they opt to use wallet as a synonym for account (emphasis mine).
We begin by explaining the primitives of DeSoc, centered around accounts (or wallets) holding non-transferable (initially public) “soulbound” tokens (SBTs) representing commitments, credentials, and affiliations. Such tokens would be like an extended resume, issued by other wallets that attest to these social relations.
I’ll save my quibbles with the word “soul” for a separate post, but as goes Vitalik’s steady thought leadership, so goes much of the community. I suspect the wallet/account terminological collapse is where we’re headed. And that is fine, as long as we aim for consistency and clarity—both in our discussions about what to build, and the UI copy our wallet clients expose.
Great challenges and opportunities lay ahead for the Wallet Stack in a multi-chain world! My only wish is that we pursue them with common terms.
I’m currently working on UX patterns for local-first edge application development at fission.codes. I’m in the midst of putting together a chain-agnostic account metadata standard proposal. If you’d like to talk about any of this, you can find me on Twitter, and everywhere else, as @depatchedmode.