An everyday spending wallet

A wallet people use to pay and be paid: first use, sending, receiving, activity, backup and recovery.

What is in it

The whole daily spending reference design, plus the pages its screens depend on: backups, handles, coin selection, privacy and key management.

369 rules

Design principles

23 rules

Visual language

10 rules

Spending, saving and delegating

6 rules

DoDecide which state of mind each screen is for, and design that screen for it alone.
Don'tCosts trustPut a savings total and a quick-pay action on the same screen. The total makes the payment feel smaller than it is.
DoBuild each state of mind on its own wallet, so the separation holds even when the interface does not. A layout can be redesigned; a key the everyday wallet never had cannot leak from it.
DoMake every move between states of mind a visible step the person takes, with its own confirmation.
Don'tCosts moneyLet the everyday wallet draw from savings on its own, or let an agent raise its own budget. Both turn a bridge into a leak.
DoPick the primary state of mind for the product, and say so. A payments app is for spending, with saving as an optional layer reached by a bridge. A savings product is for saving, with a quick top-up as its one shortcut. A product that will not choose ends up with the savings total next to the pay button.

Getting to know your users

8 rules

DoLead with the concrete benefit for the person in front of you. "Keep the 45p the card company takes on a £5 sale" beats any sentence containing the word sovereignty.
DoCount the ideas a person has to hold to finish their first task, not just the steps. Each new idea is a place they can stop.
Don'tTreat speed as comprehension. Removing friction removes the reason to stop; it does not answer "what did I just do?"
DoCosts trustLet the weight of a confirmation follow its consequence: whether it can be undone, how large the amount is against what the wallet holds, whether the recipient is new, and whether it grants something that keeps working after today.
Don'tCosts trustUse one confirmation style for everything. People learn the shape of "confirm" within a week and stop reading what is inside it.
DoDecide which of the three you are for, and say so. A product aimed at all three serves none well.
Don'tAssume somebody who has used another chain understands this one. They will look for a fee picker, wait for confirmations, and assume their recovery words work here. See Legacy compatibility.
DoTest recovery before you polish onboarding: confirm a new user can restore their wallet on a second device before refining the first-run screens.

Common user flows

5 rules

Don'tLead a store listing with self-custody or decentralisation. They are reasons to stay, not reasons to install.
DoUse the device's own biometric with a passcode fallback, and require authentication for payments above a threshold the user can see.
DoMake the wallet's own activity the place to find out whether something worked. See Activity.
DoOffer a view-only mode for people who should see a balance but not spend it.
DoCosts trustGive every failure on the send and connect flows a message that says whether money moved: "Nothing left your wallet" or "The payment went through".

Usage life cycle

12 rules

Accessibility

15 rules

Paying by handle

9 rules

DoAccept both forms in any field that takes a handle. A user pasting anna@example.com into a wallet using the newer scheme should simply work.
DoCosts moneyShow the profile name and avatar the handle resolved to, before the confirm button. Paying "Anna Keller" is checkable; paying anna@examplebank.com is only spellable.
DoCosts moneySay when the key behind a saved contact has changed since last time, and make the user acknowledge it. A silently rotated key is how a handle gets hijacked.
DoMake saving a resolved handle as a contact the obvious next step. The second payment to someone should never involve typing.
Don'tShow the derived address anywhere in the main flow. It is a one-time internal value and putting it on screen invites comparison nobody can perform.
DoOffer matches from saved contacts as the user types a handle, before accepting free text.
Don'tShow a handle on the review screen without the profile name it resolved to. On its own, a one-character difference is invisible.
DoCosts trustWarn plainly when a handle does not resolve, naming what failed: no such handle, domain unreachable, certificate invalid. "Couldn't find that" sends people to try again rather than to look harder at what they typed.
Don'tCosts trustFall back silently to a plain-address payment when a handle resolves but does not support the peer-to-peer flow. Say so, because the confirmation the user gets is weaker. See Legacy compatibility.

Amounts and units

21 rules

Wrong-network payments

13 rules

Errors and failed payments

9 rules

DoCosts trustSay whether money moved in every message that follows a payment attempt, including when the answer is that nothing left the wallet.
DoEnd every error with one thing the user can do, as a button where there is one.
DoPut the error code and technical detail in an expandable details area with a copy button, so support can ask for it.
DoKeep what the user entered. Return them to where they were with the amount, recipient and note still filled in.
Don'tWrite "Something went wrong" on its own. If you truly do not know what happened, say what you do know and whether money moved.
DoExplain a failure in the app when it is about the app's task, such as an article not unlocking, and in the wallet when it is about the user's money or permissions.
Don'tCosts moneyOffer "Try again" on a payment until you know the first attempt did not go out.
DoCosts moneyTell the user once when their wallet is retrying for them: "Your wallet will keep trying to send this. You don't need to pay again."
Don'tShow a refusal or an unanswered wallet prompt in an error style. Both are the user's choice, and red tells them they did something wrong.

Daily spending wallet

4 rules

DoRead the reasoning and adapt. A reference design that is copied screen for screen produces a product that is identical to everyone else's and fits nobody's users in particular.
DoStart from Connecting a wallet and Payments if you are building the real thing. Nearly every surprise traces back to one of those two.
Don'tTreat this as a specification. It is one defensible set of answers, and several of the questions are genuinely open. Most flow pages list their open questions.
DoAfter the first money arrives, suggest a maximum balance by asking the question that answers it: "How much would you be comfortable losing if this phone were stolen?" See Wallet setups.

First use

19 rules

Requesting

10 rules

Receiving

11 rules

Sending

18 rules

Send fees

5 rules

Don'tCosts trustKeep a fee picker because the design system already has one. It asks the user a question with no wrong answer, which teaches them that your questions are decorative.
DoCosts trustLeave the fee off the review screen entirely for ordinary payments, and put it in the transaction details afterwards for anyone who looks.
DoIn the payment's details, show the fee in local currency as one small line: "Fee: less than 1p". A figure in satoshis invites arithmetic nobody wanted to do.
Don'tExplain the fee model. A user who wanted to know about satoshis per byte will find it in the transaction details.
DoPay the fee on the user's behalf where the product can, and do not mention it. We suggest a shop absorb it as a cost of sale and an app fold it into its price. It is a real option because the fee is smaller than any price the user will see.

Activity

15 rules

Contacts

13 rules

Security

12 rules

Privacy

10 rules

Settings

13 rules

Automatic cloud backup

15 rules

Backup and recovery

4 rules

Don'tCosts moneyTell users "these words are your wallet" unless your wallet can restore everything from the words alone. A user who believes it will one day restore an empty-looking wallet and conclude the money is gone.
DoPut both items on one screen, each with its own state, so the user can see at a glance that one is done and the other is not.
Don'tCosts moneyCall the whole thing "backup" and show one tick. That is the error this page exists to prevent.
DoCosts moneyWalk the recovery path assuming the device is gone, not locked, and remove anything that only exists on it.

Manual backup

15 rules

Recovery

22 rules

Backups

5 rules

Don'tCosts moneyProtect a backup with a password manager or account that lived only on the lost phone. That is not a backup. See Cloud backup › The circular-dependency trap.
DoKeep wallet records on the device by default, and make remote storage a separate, explained opt-in.
DoEncrypt records on the device before they are sent anywhere.
DoBack up records automatically and show when the last backup ran.
DoCosts moneyNever tell users "these words are your wallet" unless that is true for your wallet. Say plainly what the backup covers and what it doesn't.

Transactions

4 rules

DoAbsorb the fee into your price where you can. If you show the network fee, put it in the payment's details as "less than 1p", not on the review screen.
DoCosts moneyMake the recipient and the amount unmistakable on the review screen. Once accepted, a payment cannot be cancelled.
DoCosts moneyWarn when a user pastes an address rather than choosing a handle or contact, and offer handles and contacts first everywhere you can. See Wrong-network payments.
DoCosts trustTreat confirmation as a risk setting, not a blanket rule. For coffee, articles, tips and most in-person sales, treat a payment as complete once the recipient's wallet has accepted it. For large amounts, show the payment as Settling until it is mined, and let businesses set their own threshold.

Coin selection

6 rules

DoSelect within a basket, and treat an output reserved by an app or a token as unavailable rather than as a cheap input.
Don'tMerge outputs from unrelated counterparties just because it makes a neater transaction. The saving is less than 1p, and the cost is linking two relationships that were separate.
DoCosts trustShow one spendable balance, and show separately anything that is not spendable because it is reserved, in a token, or in another basket. "2,400 sats, plus 1 token" is honest; a single number that silently excludes things is not.
Don'tBuild a manual coin-choice screen into a consumer wallet. Choosing well automatically protects privacy better than asking the user to.
Don'tUse the words "dust", "UTXO" or "coin selection" anywhere a normal user can see them.
DoNever show change in activity. Paying 500 sats from a 2,000-sat output is one payment of 500 sats, not a payment of 2,000 sats and a receipt of 1,500.

Payments

3 rules

DoShow "Paid" or "Received" as soon as the recipient's wallet replies "accepted". Do not wait for the payment to be mined.
DoDon't show derived payment addresses in the main interface. Show the person, handle or app the payment relates to. Keep raw transaction details in an advanced view.
DoCosts trustAlways show the user what they're paying for, and the running total against their allowance. Small, frequent payments add up, and users should never be surprised by them.

Wallet privacy

10 rules

Overview

7 rules

DoHave apps sign through the Wallet Application Interface, which uses a key derived for that purpose and never hands the app a private key.
Don'tCosts moneyLet the master identity key sign payments or messages directly, and never expose a child private key derived against anyone.
Don'tCosts trustDescribe a shared or custodial key as self-custody.
DoStart people on the simplest scheme that suits the amount they hold, and offer a clear upgrade when the balance grows past it. See Wallet setups.
DoName what each scheme protects against, in the user's terms: a lost phone, a stolen phone, a dishonest person, a forgotten password.
Don'tCosts trustOffer a choice of key scheme during onboarding. A person setting up their first wallet has no basis to answer, and the question is a good way to lose them before they hold anything.
Don'tDescribe a scheme as "secure" without saying against what. Every scheme here is secure against something and useless against something else.

Automatic cloud backup

8 rules

DoCosts moneyEncrypt on the device, before anything is sent. The service should only ever hold a blob it cannot read.
Don'tCosts moneyStore the root private key on a remote service in a form the service can decrypt. That is custody, and it should be described as custody.
DoCosts moneyWalk the recovery path assuming the device is gone, not locked, and remove every step that needs something only that device had.
Don'tCosts moneyDerive the encryption key from something the provider also holds. If the provider can decrypt it, the user is not self-custodying and the screen should not say they are.
DoLet users choose their provider, or run their own. A backup tied to one company is a backup with that company's lifespan.
DoSupport more than one location at once. Two independent copies is the point.
DoCosts moneyShow when the last backup ran, on a screen the user sees often. A backup that silently stopped three months ago fails exactly when it is needed.
Don'tCosts trustTurn remote storage on without saying so. It is a meaningful change in who can be compelled to hand over data, and it belongs to the user to decide.

Manual backup

9 rules

Don'tCosts moneyImply that recovery words move between wallet families. "Compatible with any bitcoin wallet" is false here, and a user who believes it will conclude their money is gone.
DoSay which kind of words these are on the screen that shows them, and again on the screen that asks for them.
DoOffer one method at setup, and let the user change it later.
DoExplain what the words are and where to keep them before showing them.
DoConfirm a few words at a position the user must read, and follow it with a plain prompt about where the paper will live.
Don'tBlock the wallet behind a full twenty-four-word re-entry. People copy and paste to get past it, usually from the clipboard, which is the least safe place for them.
DoOffer a recovery check the user can run at any time, which confirms the words match without moving money.
DoSuggest two locations in different buildings, in plain terms: "one at home, one somewhere else you can reach".
Don'tCosts moneyLet the words reach a screenshot, a cloud note, a password manager on the same device, or a chat message. Disable screenshots on that screen where the platform allows it, and say why.

All checklists