Something's not right

No matter which version of the web you believe we are currently on, our situation is far from ideal. We are still missing fundamental pieces.

This is not to suggest progress has halted. So many communities continue to contribute so much! But we often overstate our position on the roadmap. There has not been a Web 1, Web 2, or Web 3. Instead, there has been a Web 0.1, Web 0.2, and Web 0.3.

We are still incrementing on Web 0.x

We are not yet feature-complete. How do we know this? Because basic agency does not yet exist. Let's express a claim:

As a person living in a digitally-mediated world, regardless of my degree of data literacy and technical proficiency, I must be empowered to make my own decisions with my data. To make the right decisions for me and for the communities I inhabit.

Does this claim hold true today? In the worst case, it is not even possible for me to make the right decisions with my data (e.g. moving the personal relationships I've built on Facebook to another platform). In the best case, it may be possible but is far from obvious to most how they would do it (e.g. moving my email history from Gmail to a new client).

We have failed to meet an acceptable standard.

Possible != Probable

Simply making a secure outcome possible does not make it probable.

Secure means so much more than just “security at the technical layer.” It means enabling an environment and set of relations between individuals, that empowers communities to operate as they wish or need to.

The broken systems we rely on today must do more. They must ensure our experiences are secure by design — and designed thoughtfully enough to provide us with the agency we deserve. From concept, all the way down to code, and back up again: into the interfaces that govern our interactions.

The user experience of our digital existence must place every person, regardless of ability, in a position to be secure with their data. A truly secure system needs to be:

1. Easy & Obvious: Most vulnerabilities in a system occur when we find insecure workarounds, so the secure path must be the easiest and most obvious path for us to take.

2. Maximally De-risked: It is not realistic to expect us to be experts in keeping things secure. Therefore, systems must take the responsibility to reduce our risk by default as much as possible.

3. Just Granular Enough: We should have control over what we permit other systems, individuals, and organizations to see and do with our data. However, this control should not be so granular that it becomes overwhelming and burdensome for us to set up and maintain.

4. Sufficiently Legible: Informed consent is critical. We must be able to understand the actions and outcomes before we take those actions. Actors and objects in the system should also be labeled clearly and in a way that we can quickly understand.

5. Sufficiently Auditable: Mistakes will be made. All actions taken on our data should be auditable & reversible. All permissions we delegate should be revokable. Parts of our history should be ejectable.

6. Aware Things Change: Nothing is forever. Our circumstances may change; the world may change. We need optionality to move our data, adjust our threat models, and rotate our security factors.

7. Reflective of My Intentions: Most critically, the system must still enable us do what we intend to do. It must allow us to present ourselves to the world in the many ways we desire or need to be presented.

This list above is forever indebted to the work that came before us in what some have begun to refer to as the Pyramid of Secure Design — happy to turn it into a more complex polygon, though:

• User Interaction Design for Secure Systems by Ka-Ping Yee

• Rich Sharing for the Web by Marc Stiegler

• Privacy by Design by Ann Cavoukian

What can you do?

1. I would love your feedback, or links to any related initiatives. I'm still learning and exploring, and I'm sure there are a mountain of previous thoughts on these matters.

2. Join our working group. This is a very rough draft, to help focus the initial conversations we are having in the Secure Design Working Group. If any of this resonates with you, positively or critically, I urge you to join us in our effort to articulate a clearer path to secure outcomes.

3. Let’s develop heuristics to help evaluate the principles. Once we have a first version of these principles in a place we're happy with, I'd love to equip folks technical and non-technical alike with a checklist of heuristics they can apply to systems they build or use to asses whether these principles are being upheld.

4. Share your work — whether that’s putting your own thoughts in to writing, sharing your team’s research findings, or publishing your patterns (like the great work being done at decentpatterns.com).

🤝

Ryan leads design at Fission where he’s working on UX and DX patterns for the future of the Internet, alongside some protocol engineering phenoms. You can find him wherever he is under the alias depatchedmode.

What Is a Wallet?

• "Which wallet should I use?"

• "What wallet should I send this to?"

• "Can I import my wallet?"

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 Wallet Structure.

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:

1. Install Coinbase Wallet (a Wallet Client), which will prompt you to

2. Create a new Wallet (aka set up a new Recovery Method that will generate a password protected Wallet Structure), at which point

3. The app will provision you with 10 Wallets (which are actually 10 Accounts identified by their unique Account Addresses).

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.

Wallet Clients

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.

Varieties Of Wallet Client

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 Clients:

• Software vs Hardware: Most folks will start out by using a software wallet on their laptop, tablet or phone—either in the form of a native app, web app, or a browser extension. Eventually, they're going to want more security and are likely to move to something like a Ledger Nano—a dedicated piece of hardware with embedded firmware. Software and hardware clients mostly map to the concept of hot wallets and cold wallets respectively. TLDR: putting valuable assets into cold storage on a hardware wallet client is a good move.

• Finance vs Identity-focused: Historically, folks have turned to their Wallet Client to 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 Clients such 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.

• Single vs Multi-chain: Most Wallet Clients focus 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 Clients tend to be more mature and have better UX, but multi-chain clients are the final destination.

• EOA vs Contract-based: Signing transactions and messages (for better and for worse) is the backbone of web3 experiences. Most Wallet Clients rely 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.

Challenges Wallet Clients Face

• Overloaded Scope: At this moment in time, Wallet Clients pull 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.

• Not Being Metamask: If you're using anything other than Metamask, chances are high you're connecting your Wallet Client to an app using a wallet transport layer like Wallet Connect. Or you’re hoping your Wallet Client has decided to emulate Metamask.

• Poor Mobile Support: On mobile, most apps expect you to copy the URL to your clipboard, open your Wallet Client, launch its in-app web browser, and then paste the URL. Once again, implementing Wallet Connect in 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.

• Inconsistent Terminology: Accounts? Wallets? Import? Add? Connect? Link? Different combinations of these words appear all over the place referring to different things. Hopefully this post will help to chip away at some of that confusion, but there is still a lot of ground to cover. It is critical the teams behind Wallet Clients continue to engage in user research to identify the right mental models and terminology to support them—with a mind towards localization as well!

• No Settings Portability: If you've ever tried migrating to a different instance of Metamask, or from Metamask to Rainbow Wallet—not picking on either of them specifically—you've learned with some frustration that you have to setup everything from scratch again: account names, block and allow lists, token lists, network settings, etc. That process is both tedious and error prone to do even once, let alone maintain on an ongoing basis.

• Centralization Under the Hood: Many of the user experience improvements wallets have achieved in terms of displaying assets and transaction history have been gained through leveraging highly centralized 3rd party APIs. Moxie Marlinspike published an excellent tear down of where this centralization has introduced fragility into the ecosystem. There are better ways.

Accounts & Account Addresses

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):

• live off-chain—ie. they are “external” to the blockchain

• are controlled by a private key, from which a public key and address are derived

• are responsible for initiating all transactions

Contract Accounts:

• live on-chain as code

• are controlled by the functions defined in that on-chain code

• can only act in response to transactions issued by 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.

Human-Readable Aliases

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.

What's In Your Account?

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:

1. Contains Stuff: It’s full of coins, bills and cards that you fold up and slide into your front pocket.

2. Is Default Private: Nobody can see any of that stuff unless you decide to show them.

The blockchain account you’re managing in your wallet shares neither of those characteristics. A blockchain account:

1. Contains Nothing: When I say that nothing is in your account, I mean it. No matter what asset you are referring to, whether it be ETH, an ERC-20, or an NFT, the balance that is attributed to your account is stored elsewhere and points to your account. In the case of an EOA this shouldn't be surprising, because the assets are on chain and—as we just illustrated—your account is not. The same is true for contract accounts.

2. Is Default Public: Anyone can look up your ENS domain or public address to see the entire list of current and past assets associated with that account, as well as all its transactions.

Challenges That Accounts Face

https://twitter.com/punk6529/status/1495450982079254541?s=21

• Account Composition: Beyond the wallet being a broken metaphor, Dan Finlay has gone so far as to say recently that even "account" is a skeuomorphic dead end. And many folks are weighing in on how you might want to compose your set of accounts in order to best protect yourself against loss and theft.

• Consent Layer: Because blockchains are permission-less and the assets are pointed at your address from elsewhere, anybody can put anything "in" your account at any time. This leaves the door open for a great deal of harassment, fraud, and general mischief. We need to carefully consider appropriate counter measures. Where and how does a consent layer (aka requesting permission) best fit into a permission-less system?

• Multi-chain Address Space: In many instances, the same addresses can exist on multiple chains and networks. In other instances, it’s impossible for an address on one chain to exist on another. This all comes down to the compatibility of encryption methods used. When someone provides just an Account Address how 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.

• Nascent Contract Account Support: As I already mentioned, there are a lot of benefits that Contract Accounts can bring, but they are still not widely supported for interacting with apps.

The Recovery Method & Wallet Structure

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:

• Private Keys: As we saw above, every account has both a private key and a public key. If you have an account's private key, you can always use it to recover the public key and account address. It’s created from a combination of randomness and cryptographic math. Strong arguments can be made that private keys should never be user facing.

• Recovery Phrases (aka Seed Phrases/Mnemonic Phrases): These are the 12 or 24 word phrases (defined by BIP-39) that you are encouraged to back up safely & securely. Their original intention was to be a human readable way to produce the randomness required to generate a private key. They are less prone to transcription errors than a base-58 string, easier to speak aloud (see: accessibility), and possibly (though it’s a stretch for most) even memorized.

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 Wallet Structure.

"OMG, yet another thing called a wallet!?" Yes.

What Is An HD Wallet?

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.

Challenges That Current Recovery Methods Face

• 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:

  https://vitalik.ca/general/2021/01/11/recovery.html

Wallet Out

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.