Savings, shared or inherited money

Money that moves rarely, that more than one person controls, or that has to outlive its owner.

What is in it

The savings and inheritance reference designs and the three wallet patterns, plus the key-management and spending-condition pages they are built on.

306 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

Amounts and units

21 rules

Wrong-network payments

13 rules

Spending conditions

12 rules

Savings wallet

14 rules

Time-based recovery

15 rules

Inheritance wallet

2 rules

Don'tOffer this to somebody setting up their first wallet. It is the most complex arrangement in this guide and the least forgiving of an abandoned setup. See Upgradeable wallet.
DoRead Succession before designing any of the others. Every decision in setup should be judged by whether it makes that flow survivable for somebody grieving, unfamiliar with the app, and possibly using it for the first time.

Overview

4 rules

DoChoose the threshold by asking which pairs of people should be able to act together, not by picking a number. "Any two of these four" is a sentence the owner can check against their own family.
Don'tBuild an arrangement where the owner alone cannot spend. It turns everyday access into a committee and the wallet stops being used, which is how it ends up abandoned and unmaintained.
DoShow this table in the app, filled in with the real names, and let anybody holding a key see it. A participant who does not know what they hold cannot act when it matters.
DoJudge every setup decision by what it costs to maintain. A four-key arrangement with a six-month period is more secure on paper and will be dead in two years, because nobody keeps up with it.

Wallet creation

14 rules

Onboarding cosigners

9 rules

DoTrack per person whether they have received it, imported it, and confirmed. Three states, because "sent" is not "working".
DoSay what they can do, what they cannot, and when that changes, in a sentence each: "You can't move this money on your own. You and Christina together can. If Bob doesn't use it for a year, Christina can on her own."
DoName who asked, and let them decline. Being added to somebody's inheritance arrangement is a real obligation.
Don'tPresent it as "a wallet has been shared with you". They are not getting money, and somebody who thinks they are will be confused twice: now, and much later.
DoHave the cosigner sign something harmless as part of setup, so both sides know the key works before it is relied on. A key that has never signed is an assumption.
DoGive each cosigner an export they hold themselves, containing the configuration, their key's recovery material and, where they are on the succession path, the current pre-signed transaction.
DoCosts moneyRe-send the pre-signed transaction every time it is rebuilt, which is after every payment in or out and every refresh. An out-of-date copy either spends money that has already moved, and fails, or misses money the wallet received since.
DoSend an occasional note to each cosigner confirming the arrangement is alive and their key still works. Once or twice a year is enough, and it doubles as a check that their contact details are current.
DoLet a cosigner see the arrangement at any time without the owner's involvement.

Backup

11 rules

Making changes

12 rules

Succession

13 rules

Multiple wallets

20 rules

Shared wallet

13 rules

Upgradeable wallet

8 rules

DoName the trigger in terms of the user's own money: "You're holding more than you said you wanted to keep on this phone. Want to add a second key?"
Don'tOffer the upgrade as an abstract security improvement. "Increase your security level" is a prompt nobody acts on, because nobody knows what level they are at.
DoKeep small payments one-tap at every stage. A multi-key wallet that asks for a second device to buy a coffee has become a savings wallet by accident. See Wallet setups.
DoShow the current arrangement in plain words, and what each option would protect against. "One key on this phone. If you lose it and have your recovery words, you're fine. If somebody unlocks it, they can spend."
DoLet a user rehearse the new arrangement with a small amount before moving everything.
Don'tCosts trustOffer downgrades without a hard confirmation naming what is lost. Going from three keys to one is a real reduction in protection and should feel like one.
DoThis is a path, not a feature. The upgrade should be prompted by the balance crossing something the user would mind losing, not discovered in settings by the people who least need it.
DoOffer the upgrade path for people who want one wallet, and the two-wallet arrangement for people holding enough to care. The second is the one this guide recommends once there is real money involved. See Multiple wallets.

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.

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.

External signers

8 rules

DoShow progress while an animated code is being scanned, as a proportion collected rather than a frame count. Users point a camera at a flickering screen for several seconds and need to know it is working.
DoPrompt the user to compare the signer's screen with the computer's before approving, and say which one to believe if they differ.
DoDesign the capability, and be honest in the product about what exists. "Use a signing device" is a promise; "works with devices that support air-gapped BEEF signing" is a fact the user can check.
Don'tBuild a savings or inheritance flow whose only safe path needs a device your users cannot obtain. Multi-key across phones and people is available today and is the better default until that changes.
DoCosts moneyTreat the signer as one key in a set rather than the only key, where the amount justifies it. A single signing device that is lost is a total loss. See Multi-key.
DoLet the wallet work read-only while the signer is away. Balances, history and receiving should all function without it, so the device is only needed to spend.
DoCosts moneySay what happens if the device breaks, during setup, not during recovery. The answer is the recovery material, and the user should have it before they need it.
Don'tRequire the signer for receiving. Nothing needs signing to receive, and a wallet that asks for it has made the device a daily chore for no gain.

Multi-key

9 rules

DoShow whose signature is still outstanding, and give a way to nudge them. Most of the time a shared payment is waiting on a person, not on the network.
DoWalk the setup one key at a time, and say for each one where it is going and what losing it would mean.
DoLet an unfinished setup be saved and resumed. Gathering three devices or three people rarely happens in one sitting.
Don'tFinish setup without the user having restored from it once. An untested multi-key wallet is a wallet with more ways to fail than a single-key one.
DoCosts moneyBack up the wallet configuration with the same care as a key. It names every key in the arrangement.
DoShow what is being signed in plain terms on every device that signs, and how many signatures are collected.
DoCosts trustLet a partly signed payment be abandoned cleanly, without leaving funds stuck.
Don'tSay "2-of-3 multisig". Say "Two of your three keys are needed to spend", and name the keys the way the user named them.
DoPick on the trust question, not the privacy one. If the parties need to be sure no one of them can ever reconstruct the whole key, that is bare multisig. If the goal is one person's key surviving a fire, shares are simpler and cheaper.

All checklists