# An everyday spending wallet
The whole daily spending reference design, plus the pages its screens depend on: backups, handles, coin selection, privacy and key management.
The costly rules come first; the full list follows, grouped by page. Every line carries the address of the sentence it came from.
369 rules: 57 that can cost money, 58 that can cost trust, 254 standard.
## Start here
- **DON'T** _(Costs money)_ Build a product where the user's funds depend on your company continuing to exist. Every wallet should be recoverable without you. See Backups.
- **DO** _(Costs money)_ Make the irreversible step unmistakable. A payment cannot be recalled, so the review screen is the last line of defence.
- **DO** _(Costs money)_ Show the total a payment takes from the user, who it goes to, and that it cannot be undone, before they commit.
- **DO** _(Costs money)_ Name the limits. "This backup covers your keys but not your payment records" is the sentence that stops somebody losing money later.
- **DON'T** _(Costs money)_ Let the everyday wallet draw from savings on its own, or let an agent raise its own budget. Both turn a bridge into a leak.
- **DO** _(Costs money)_ Show 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.
- **DO** _(Costs money)_ Say 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.
- **DON'T** _(Costs money)_ Show long decimal BSV amounts in a consumer interface. "0.00012500 BSV" asks the reader to count zeros, and they will get it wrong.
- **DO** _(Costs money)_ Make the handle the default and the address the fallback. Every payment that uses a handle is a payment that cannot go to the wrong network.
- **DO** _(Costs money)_ Put the network name next to the address field, always, not only on error. "BSV address" is three words and it is the whole defence.
- **DO** _(Costs money)_ Warn on every pasted address rather than trying to detect a bad one. You cannot detect it, and a warning that only fires sometimes teaches people it means something specific.
- **DON'T** _(Costs money)_ Use "bitcoin address" as the field label. That is the word that cannot distinguish the networks, on the screen where the distinction is the whole point.
- **DO** _(Costs money)_ Put the network on the confirmation, beside the recipient, in the same weight as the amount.
- **DO** _(Costs money)_ Say plainly what cannot be undone, before the button: "Sent to the wrong network, this usually cannot be recovered."
- **DO** _(Costs money)_ Offer a test payment for a first-time address above a threshold you choose, and ask the user to check with the recipient that it arrived. It costs a fraction of a penny and it is the only defence that proves the address is right.
- **DO** _(Costs money)_ Make the network selection impossible to leave at a default, and restate the chosen network on the confirmation.
- **DON'T** _(Costs money)_ Offer "Try again" on a payment until you know the first attempt did not go out.
- **DO** _(Costs money)_ Tell 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."
- **DO** _(Costs money)_ Prompt for the key backup once there is money to protect, at the latest when the balance first crosses an amount the user would mind losing, and let the user do it then and there.
- **DON'T** _(Costs money)_ Show recovery words during onboarding. A user with nothing to lose photographs them, and the screenshot outlives the carelessness.
- **DO** _(Costs money)_ Say what the backup covers, because it is two things: "Your recovery words restore your keys. Your wallet backup restores your records: which money is yours and how to spend it. Keep both."
- **DO** _(Costs money)_ Resolve the handle and show the profile name and avatar before the confirm button. Paying "Anna Keller" is checkable; paying anna@example.com is only spellable. See Paying by handle.
- **DON'T** _(Costs money)_ Let a typed handle go straight to a confirm screen with no resolution step. The resolution is the check.
- **DO** _(Costs money)_ Warn on every pasted address that money sent to an address on another network is very hard to recover, and offer the user's contacts or a handle instead.
- **DO** _(Costs money)_ Warn before any payment to a contact whose key has changed, and require acknowledgement: "Anna's wallet key has changed since you last paid her. If you weren't expecting this, check with her another way first."
- **DON'T** _(Costs money)_ Offer an unlimited allowance. There is no amount of convenience that justifies it, and a product offering it will have users who accepted it without reading.
- **DON'T** _(Costs money)_ Accept a single tap. Require the balance to be acknowledged, and refuse outright if there is a balance and either part of the backup is missing, with a route to making it.
- **DON'T** _(Costs money)_ Make it a manual export the user has to remember. They will not, and the gap will be exactly the payments they most wanted back.
- **DO** _(Costs money)_ Encrypt the backup with a key derived from the recovery words, so the words and the backup restore everything with nothing else to remember.
- **DO** _(Costs money)_ Say on the setup screen that nobody else can open or reset this backup: "Only your recovery words can open this backup. Nobody can reset them, including us."
- **DON'T** _(Costs money)_ Derive the encryption key from anything the provider also holds. If they can decrypt it, this is custody and the screen should not say otherwise.
- **DO** _(Costs money)_ Test recovery by wiping a device, not by logging out.
- **DO** _(Costs money)_ Say on this screen that it does not back up the keys. A user who sets this up and sees a tick will reasonably conclude they are finished. "Your wallet backup restores your records. Your recovery words restore your keys, and you still need to write them down."
- **DON'T** _(Costs money)_ Tell 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.
- **DON'T** _(Costs money)_ Call the whole thing "backup" and show one tick. That is the error this page exists to prevent.
- **DO** _(Costs money)_ Walk the recovery path assuming the device is gone, not locked, and remove anything that only exists on it.
- **DO** _(Costs money)_ Explain first, in two sentences: what the words do, and that a photograph of them is a copy of the money. Then show them.
- **DO** _(Costs money)_ Disable screenshots on this screen where the platform allows it, and say why rather than failing silently.
- **DON'T** _(Costs money)_ Offer copy to clipboard. The clipboard is readable by other apps and syncs between devices.
- **DO** _(Costs money)_ Offer shares as an alternative, not an addition. Words and shares are two encodings of the same secret, so holding both makes two complete copies to protect rather than a safer arrangement.
- **DO** _(Costs money)_ When the keys are restored but no wallet backup is found, say so: "Your keys are restored. We could not find your wallet backup, so some payments may be missing. Anything you receive from now on will appear normally."
- **DON'T** _(Costs money)_ Report a balance of zero as though it were a fact. It is the balance of what the wallet currently knows about.
- **DO** _(Costs money)_ Re-establish the backup on the new device, and say so. A recovered wallet with no backup is one failure away from the same situation.
- **DO** _(Costs money)_ Run a full drill before the product holds real money: fund it, make payments across several counterparties, export, delete the installation, remove your own service from the path, and restore on a clean device with a different compatible wallet. See Backups.
- **DON'T** _(Costs money)_ Ship a recovery flow that has only been tested with the original app still installed. That is the one situation it will not be used in.
- **DON'T** _(Costs money)_ Protect 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.
- **DO** _(Costs money)_ Never 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.
- **DO** _(Costs money)_ Make the recipient and the amount unmistakable on the review screen. Once accepted, a payment cannot be cancelled.
- **DO** _(Costs money)_ Warn 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.
- **DON'T** _(Costs money)_ Let the master identity key sign payments or messages directly, and never expose a child private key derived against anyone.
- **DO** _(Costs money)_ Encrypt on the device, before anything is sent. The service should only ever hold a blob it cannot read.
- **DON'T** _(Costs money)_ Store 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.
- **DO** _(Costs money)_ Walk the recovery path assuming the device is gone, not locked, and remove every step that needs something only that device had.
- **DON'T** _(Costs money)_ Derive 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.
- **DO** _(Costs money)_ Show 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'T** _(Costs money)_ Imply 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.
- **DON'T** _(Costs money)_ Let 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.
- **DON'T** _(Costs trust)_ Require an identity document, an email address or a phone number to hold money. Where a regulation requires it for a particular feature, gate that feature, not the wallet.
- **DO** _(Costs trust)_ Give every wallet an export the user holds themselves, and a send to a plain address that works without your servers. See Legacy compatibility.
- **DO** _(Costs trust)_ Before revealing key linkage for a counterparty, tell the user it exposes every payment between them and that counterparty, past and future. See Wallet privacy.
- **DON'T** _(Costs trust)_ Put a savings total and a quick-pay action on the same screen. The total makes the payment feel smaller than it is.
- **DO** _(Costs trust)_ Let 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'T** _(Costs trust)_ Use one confirmation style for everything. People learn the shape of "confirm" within a week and stop reading what is inside it.
- **DO** _(Costs trust)_ Give every failure on the send and connect flows a message that says whether money moved: "Nothing left your wallet" or "The payment went through".
- **DO** _(Costs trust)_ Make a wallet's permission prompt readable in full by a screen reader: who is asking, what for, and for how long. A grant the person could not hear is not consent.
- **DO** _(Costs trust)_ Warn 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'T** _(Costs trust)_ Fall 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.
- **DO** _(Costs trust)_ Use Bitcoin SV or BSV on screen: "Send BSV", "Your BSV balance", "Bitcoin SV address". Use one of the two consistently within a screen.
- **DON'T** _(Costs trust)_ Write "bitcoin" alone on a screen where somebody is about to move money. Used precisely it is an umbrella covering several chains, so it is the one word that cannot tell a user which network they are on. See Bitcoin.
- **DO** _(Costs trust)_ Say when a converted figure is an estimate, and roughly how fresh the rate is. A price that silently drifts is worse than one labelled approximate.
- **DO** _(Costs trust)_ Keep one bitcoin unit per screen. Mixing "0.0001 BSV" and "10,000 sats" in one view asks the user to do arithmetic to compare two things you wrote.
- **DON'T** _(Costs trust)_ Abbreviate amounts in a financial context. "12.5k sats" saves four characters and introduces a rounding question.
- **DON'T** _(Costs trust)_ Shorten a number with an ellipsis, ever. Reformat it or let it wrap.
- **DO** _(Costs trust)_ Say what happened in plain words: which network it went to, that the money is not lost from the chain but is out of reach from here, and what recovery would require.
- **DON'T** _(Costs trust)_ Promise recovery you cannot deliver. If it needs the other party's cooperation, say that is what it needs.
- **DO** _(Costs trust)_ Say whether money moved in every message that follows a payment attempt, including when the answer is that nothing left the wallet.
- **DON'T** _(Costs trust)_ Ask for an email address, a phone number or an identity document to create a wallet. None is needed, and requiring one discards the main advantage the product has.
- **DON'T** _(Costs trust)_ Offer a choice of key scheme during onboarding. Somebody setting up their first wallet has no basis to answer. See Private key management.
- **DO** _(Costs trust)_ Offer automatic encrypted backup of the wallet's records during onboarding, with one line saying where it goes, and turn it on only if the user says yes. Never switch remote storage on silently. Records are the part that must be continuous anyway. See Backups.
- **DON'T** _(Costs trust)_ Put anything personal in a note by default. It is shared with the payer and may end up in their records. See Wallet privacy.
- **DO** _(Costs trust)_ A public donation handle is permanently linked to everything paid to it. Suggest a separate handle for it. A tag such as @maya+donations@example.com sorts the payments but still resolves to Maya. See Paying by handle.
- **DO** _(Costs trust)_ Show the running total against the allowance somewhere the user passes regularly, and make every agent or app payment visible in activity, marked as such. See Permissions and allowances.
- **DO** _(Costs trust)_ Require the device's authentication to confirm, above whatever threshold the user set.
- **DO** _(Costs trust)_ Say first whether money left the wallet.
- **DO** _(Costs trust)_ Make sure this works without your servers, any Pass, or any vendor service. It is the user's guaranteed way out if everything else in the stack fails. See Backups.
- **DON'T** _(Costs trust)_ Keep 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.
- **DO** _(Costs trust)_ Leave the fee off the review screen entirely for ordinary payments, and put it in the transaction details afterwards for anyone who looks.
- **DON'T** _(Costs trust)_ Make an explorer the answer to "where is my money". If a wallet cannot explain the state of its own payment, that is a gap in the wallet. See Nodes and verification.
- **DO** _(Costs trust)_ Name what is lost in the confirmation: the saved key, and therefore the warning if it changes. Payment history stays.
- **DO** _(Costs trust)_ Let the user set a threshold above which authentication is required per payment, and default it to something sensible rather than to every payment or to none. We suggest an amount around the price of a coffee.
- **DO** _(Costs trust)_ Make revoking immediate and obvious, and say what it will break: the app stops working until it asks again.
- **DO** _(Costs trust)_ Expire spending and sensitive permissions by default, and tell the user when one is about to lapse rather than renewing it silently.
- **DON'T** _(Costs trust)_ Bury this in settings. It is the control panel for everything that can spend the user's money without asking each time.
- **DO** _(Costs trust)_ Set allowances per app, with a per-payment cap as well as a total. A thousand payments of a satoshi and one payment of a thousand satoshis are different risks.
- **DO** _(Costs trust)_ Give it its own confirmation, outside any bundle, naming who is asking and what they will be able to see.
- **DON'T** _(Costs trust)_ Include it in a connect-time grant. Nothing legitimate needs it at connect time.
- **DON'T** _(Costs trust)_ Reveal the user's identity key or profile to an app for a routine payment unless the user chose to. It permanently links a name to spending. See Identity.
- **DO** _(Costs trust)_ Name what is lost and what is not. The money stays where it is; the recovery words and the wallet backup together restore it on another device. If either is missing, say that deleting may make the money unrecoverable, in those words.
- **DO** _(Costs trust)_ Explain it in one line that says where the backup goes and what opens it: "Back up your wallet to your cloud storage? It is encrypted on this phone, and only your recovery words can open it."
- **DON'T** _(Costs trust)_ Enable remote storage without saying so. It changes who can be compelled to hand over data, and that is the user's decision.
- **DON'T** _(Costs trust)_ Protect the backup with a separate PIN or password. A short PIN can be guessed by anyone holding the file, and a password is one more secret to forget at the worst moment.
- **DO** _(Costs trust)_ Say on the words screen which wallets can restore them: "These words restore your wallet in apps that support BSV recovery words. Other wallets may show an empty balance."
- **DO** _(Costs trust)_ End the flow by saying what it did not do, and show the state of the other part: "Your recovery words restore your keys. Your wallet backup restores your records: which money is yours and how to spend it. Keep both." See Backup and recovery.
- **DO** _(Costs trust)_ Recover what can be recovered without records, and be explicit that it may be partial.
- **DO** _(Costs trust)_ Name anything that did not, and say what it means. A token type the wallet does not support, records older than the backup, a Pass that needs reissuing.
- **DON'T** _(Costs trust)_ Show a success screen with no numbers on it. The user's question is "is my money there", and a tick does not answer it.
- **DO** _(Costs trust)_ Prompt the user to check whether the old device should be considered compromised, if it was stolen rather than lost. Moving to fresh keys is a real option and nobody will think of it unaided.
- **DO** _(Costs trust)_ Treat 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.
- **DO** _(Costs trust)_ Show 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.
- **DO** _(Costs trust)_ Always 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.
- **DON'T** _(Costs trust)_ Attach a user's identity key to routine payments because it makes your activity list prettier. It permanently links their name to their spending.
- **DON'T** _(Costs trust)_ Call payments "anonymous" or "private". Both are false.
- **DON'T** _(Costs trust)_ Describe a shared or custodial key as self-custody.
- **DON'T** _(Costs trust)_ Offer 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'T** _(Costs trust)_ Turn 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.
## Every rule, by page
### Design principles
https://www.bitcoinsv.design/guide/getting-started/principles/
- **DO** Let the user hold their own keys, and make the path to doing so the default rather than an advanced option.
- **DO** Say plainly when something is custodial. A service holding keys on a user's behalf is a legitimate product; describing it as self-custody is not.
- **DON'T** _(Costs money)_ Build a product where the user's funds depend on your company continuing to exist. Every wallet should be recoverable without you. See Backups.
- **DO** Match the protection to the amount. A wallet holding coffee money and a wallet holding savings are different products, and pretending otherwise produces one that is wrong for both. See Wallet setups.
- **DO** _(Costs money)_ Make the irreversible step unmistakable. A payment cannot be recalled, so the review screen is the last line of defence.
- **DO** Ask for as little as the product needs. The independent risk assessment of the wallet interface (BRC-151) warns how much a wallet can be asked for; the answer is to need less of it. See Connecting a wallet.
- **DON'T** Train people to tap approve. A prompt that appears constantly, is pre-ticked, or reappears until accepted teaches exactly the habit that gets someone robbed.
- **DO** Write for someone who has never heard of a UTXO and never needs to. Internal vocabulary belongs in advanced views and documentation.
- **DO** Meet WCAG 2.2 AA: contrast, touch targets, screen reader labels, and amounts that read aloud sensibly. See Accessibility.
- **DON'T** _(Costs trust)_ Require an identity document, an email address or a phone number to hold money. Where a regulation requires it for a particular feature, gate that feature, not the wallet.
- **DO** Support the standards rather than a bespoke integration. Design your connect flow around "your wallet", not a brand.
- **DO** _(Costs trust)_ Give every wallet an export the user holds themselves, and a send to a plain address that works without your servers. See Legacy compatibility.
- **DON'T** Invent a proprietary format for something a BRC already covers. A format only your product reads is a lock-in whether or not you meant it as one.
- **DO** _(Costs money)_ Show the total a payment takes from the user, who it goes to, and that it cannot be undone, before they commit.
- **DO** Say what your product can see and what it stores. A wallet that phones a service on every balance check should say which service and what it learns.
- **DO** _(Costs money)_ Name the limits. "This backup covers your keys but not your payment records" is the sentence that stops somebody losing money later.
- **DON'T** Describe a product as private, anonymous or instant without the qualifier that makes it true.
- **DO** Keep outputs from unrelated counterparties apart when selecting what to spend. Spending them together is the main remaining on-chain leak. See Coin selection.
- **DO** _(Costs trust)_ Before revealing key linkage for a counterparty, tell the user it exposes every payment between them and that counterparty, past and future. See Wallet privacy.
- **DON'T** Collect what you do not need, and never attach a user's identity to routine payments for convenience.
- **DON'T** Write personal data on chain in the clear. There is no delete.
- **DO** Let users choose or self-host the services your wallet depends on, and support more than one. See Nodes and verification.
- **DON'T** Weld a product to one provider's endpoint. That is your product's lifespan as well as theirs.
### Visual language
https://www.bitcoinsv.design/guide/getting-started/visual-language/
- **DO** Use the BSV mark, the upright B on gold, wherever a BSV product needs the symbol as a mark.
- **DON'T** Use the orange disc or a tilted B to stand for BSV. Both say a different network to anyone who knows the difference.
- **DO** Use the Unicode character ₿, not the logo, when you need the bitcoin symbol in text. It scales, reflows and can be read by a screen reader. For amounts and labels, use sats and BSV; see Amounts and units.
- **DON'T** Use the golden disc logo inside a sentence. It is a mark, not a letterform, and at text size it is a smudge.
- **DON'T** Put memes in a product. They read as a private joke to people inside and as unseriousness to people outside, and the second group is who you are trying to reach.
- **DO** Draw the thing that is happening. A payment is a person handing something to a person.
- **DO** Pick a point on the scale deliberately and hold it across the product. Drifting between the two is what produces an app that is baffling to newcomers and patronising to everyone else.
- **DON'T** Use a lightning bolt to mean speed in a BSV product. Show the thing itself: a payment confirmed while the customer is still at the till.
- **DON'T** Put advocacy in a product. Say what yours does and let it be judged on that.
- **DO** Reach for the gold metaphor on a savings surface and leave it off an everyday one. A payment app that looks like a vault tells people their coffee money is an investment.
### Spending, saving and delegating
https://www.bitcoinsv.design/guide/designing-products/spending-saving-delegating/
- **DO** Decide which state of mind each screen is for, and design that screen for it alone.
- **DON'T** _(Costs trust)_ Put a savings total and a quick-pay action on the same screen. The total makes the payment feel smaller than it is.
- **DO** Build 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.
- **DO** Make every move between states of mind a visible step the person takes, with its own confirmation.
- **DON'T** _(Costs money)_ Let the everyday wallet draw from savings on its own, or let an agent raise its own budget. Both turn a bridge into a leak.
- **DO** Pick 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
https://www.bitcoinsv.design/guide/designing-products/getting-to-know-your-users/
- **DO** Lead 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.
- **DO** Count 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'T** Treat speed as comprehension. Removing friction removes the reason to stop; it does not answer "what did I just do?"
- **DO** _(Costs trust)_ Let 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'T** _(Costs trust)_ Use one confirmation style for everything. People learn the shape of "confirm" within a week and stop reading what is inside it.
- **DO** Decide which of the three you are for, and say so. A product aimed at all three serves none well.
- **DON'T** Assume 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.
- **DO** Test 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
https://www.bitcoinsv.design/guide/designing-products/common-user-flows/
- **DON'T** Lead a store listing with self-custody or decentralisation. They are reasons to stay, not reasons to install.
- **DO** Use the device's own biometric with a passcode fallback, and require authentication for payments above a threshold the user can see.
- **DO** Make the wallet's own activity the place to find out whether something worked. See Activity.
- **DO** Offer a view-only mode for people who should see a balance but not spend it.
- **DO** _(Costs trust)_ Give 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
https://www.bitcoinsv.design/guide/designing-products/usage-life-cycle/
- **DON'T** Keep showing onboarding hints to somebody on their hundredth payment.
- **DO** Teach each of the four at the moment it first applies: ownership when money first arrives, irreversibility on the first review screen, the backup when the balance is worth protecting, the network name wherever somebody pastes an address.
- **DON'T** Teach what the product can take care of for them, such as fees or key schemes. Every concept taught before it is needed is a reason to stop.
- **DO** Make the first thing a new user does end with them holding real money: received from a person, or spent on something they wanted anyway.
- **DON'T** Build a practice wallet or a simulated payment in place of a real first receive. It teaches the user that the real thing is somewhere else.
- **DO** Design for the person doing the introducing: a handle they can share, a payment request they can send, and a first payment that says who it came from. See Contacts.
- **DO** Get a new user from opening the app to holding money in one sitting, without leaving the app except to ask somebody to pay them.
- **DO** Give every setup step a way back. A mistake during setup should cost a tap, not the wallet.
- **DO** Ask the person, after a test, to explain to a friend what they just did. What they cannot explain did not land.
- **DO** Measure where people stop, step by step, and work on the worst step first. A whole-funnel number tells you there is a problem and not where it is.
- **DO** Design the "frightening moment" explicitly. A payment that looks stuck, an unexpected balance, an app asking for something alarming. One clear explanation at that moment can keep somebody who would otherwise leave.
- **DO** We suggest two causes to check first: being asked to choose a key scheme, and having nowhere to get any BSV. The first is yours to fix. See First use.
### Accessibility
https://www.bitcoinsv.design/guide/designing-products/accessibility/
- **DON'T** Ship a control labelled "button". A QR code built as an unlabelled image is not selectable at all, so it does not exist for a screen reader user.
- **DO** Name the thing and its effect: "QR code, double tap to copy the payment handle".
- **DO** _(Costs trust)_ Make a wallet's permission prompt readable in full by a screen reader: who is asking, what for, and for how long. A grant the person could not hear is not consent.
- **DO** Put the recipient before the amount in the reading order of a review screen. It is the field most worth hearing first.
- **DO** Give every scan a typed or pasted equivalent. A user who cannot aim a camera still needs to pay.
- **DO** Pair colour with a word or a symbol, always. Sent and received, plus and minus, not just red and green.
- **DON'T** Put a countdown on a confirmation. Nothing here expires, so a timer is a difficulty you added. If a rate quote goes stale, refresh it rather than timing the person out.
- **DO** Make sure an amount reads aloud correctly. "12,500 sats" should be spoken as a number and a unit, which means it has to be text with a real unit beside it.
- **DO** Use fixed-width digits (tabular-nums), so a changing balance does not shift the layout under a magnified viewport.
- **DO** Offer at least one route that does not need handwriting: an encrypted file the user stores themselves, split shares held by people they trust, or a signing device.
- **DO** Let the words be read aloud in private, and let the confirmation step be completed with a screen reader. A test that only works by sight makes recovery impossible later.
- **DO** Write at a reading age of about twelve. Short sentences, common words, one idea each.
- **DO** Say what happened and what it means for the money. "The payment did not go through. Nothing left your wallet." beats an error code every time.
- **DO** Run the send and recovery flows with the screen reader on and the screen off. It takes an afternoon and finds problems an automated audit misses.
- **DO** Include people with disabilities in research, paid, rather than simulating them.
### Paying by handle
https://www.bitcoinsv.design/guide/patterns/paying-by-handle/
- **DO** Accept 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.
- **DO** _(Costs money)_ Show 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.
- **DO** _(Costs money)_ Say 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.
- **DO** Make saving a resolved handle as a contact the obvious next step. The second payment to someone should never involve typing.
- **DON'T** Show 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.
- **DO** Offer matches from saved contacts as the user types a handle, before accepting free text.
- **DON'T** Show a handle on the review screen without the profile name it resolved to. On its own, a one-character difference is invisible.
- **DO** _(Costs trust)_ Warn 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'T** _(Costs trust)_ Fall 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
https://www.bitcoinsv.design/guide/patterns/amounts-and-units/
- **DO** Default to satoshis, not BSV, for the bitcoin figure. Everyday amounts are hundreds or thousands of satoshis, and the decimal form is unreadable at that scale.
- **DO** Write "sats" or "satoshis" in words, and group digits in threes: 12,500 sats.
- **DON'T** _(Costs money)_ Show long decimal BSV amounts in a consumer interface. "0.00012500 BSV" asks the reader to count zeros, and they will get it wrong.
- **DON'T** Adopt a satoshi glyph. None renders reliably, none is in common fonts, and your users have not seen any of them.
- **DO** _(Costs trust)_ Use Bitcoin SV or BSV on screen: "Send BSV", "Your BSV balance", "Bitcoin SV address". Use one of the two consistently within a screen.
- **DO** Prefer "Bitcoin SV" where there is room and the reader may be new to it, "BSV" where space is tight or the term repeats in a list.
- **DON'T** _(Costs trust)_ Write "bitcoin" alone on a screen where somebody is about to move money. Used precisely it is an umbrella covering several chains, so it is the one word that cannot tell a user which network they are on. See Bitcoin.
- **DO** Lead with local currency for anything a person chooses to buy, with the satoshi amount beside it: "£12.00 (24,000 sats)".
- **DO** Lead with satoshis for figures software decides or enforces, such as allowance limits, what is left of an allowance and agent budgets, with local currency beside them.
- **DO** Let the two be swapped in one tap, and remember the choice.
- **DO** _(Costs trust)_ Say when a converted figure is an estimate, and roughly how fresh the rate is. A price that silently drifts is worse than one labelled approximate.
- **DO** Use tabular figures (tabular-nums in CSS) everywhere a figure appears, so digits line up in a column and a changing balance does not shift the layout.
- **DO** Format for the reader's locale. 1,200 and 1.200 and 1 200 are the same number to three different people and three different numbers to one of them.
- **DO** _(Costs trust)_ Keep one bitcoin unit per screen. Mixing "0.0001 BSV" and "10,000 sats" in one view asks the user to do arithmetic to compare two things you wrote.
- **DON'T** _(Costs trust)_ Abbreviate amounts in a financial context. "12.5k sats" saves four characters and introduces a rounding question.
- **DON'T** _(Costs trust)_ Shorten a number with an ellipsis, ever. Reformat it or let it wrap.
- **DO** Leave the fee off the review screen and put it in the transaction details. If it is shown, show it in local currency: "Fee: less than 1p".
- **DO** Show the individual amount where it happens and the aggregate where the user is deciding something. "About 1p (20 sats)" on the article, "940 sats (about 47p) today" in the allowance summary.
- **DO** Round aggregates to a sensible precision in local currency. "About 24p today" is more useful than "£0.2384".
- **DO** Make sure an amount reads correctly aloud. A screen reader should say "twelve thousand five hundred satoshis", which means the unit needs to be text rather than an image or an unlabelled glyph.
- **DO** Never rely on colour alone to show direction. Pair the colour with a sign or a word.
### Wrong-network payments
https://www.bitcoinsv.design/guide/patterns/wrong-network-payments/
- **DO** _(Costs money)_ Make the handle the default and the address the fallback. Every payment that uses a handle is a payment that cannot go to the wrong network.
- **DO** _(Costs money)_ Put the network name next to the address field, always, not only on error. "BSV address" is three words and it is the whole defence.
- **DO** _(Costs money)_ Warn on every pasted address rather than trying to detect a bad one. You cannot detect it, and a warning that only fires sometimes teaches people it means something specific.
- **DON'T** _(Costs money)_ Use "bitcoin address" as the field label. That is the word that cannot distinguish the networks, on the screen where the distinction is the whole point.
- **DO** _(Costs money)_ Put the network on the confirmation, beside the recipient, in the same weight as the amount.
- **DO** _(Costs money)_ Say plainly what cannot be undone, before the button: "Sent to the wrong network, this usually cannot be recovered."
- **DO** _(Costs money)_ Offer a test payment for a first-time address above a threshold you choose, and ask the user to check with the recipient that it arrived. It costs a fraction of a penny and it is the only defence that proves the address is right.
- **DO** _(Costs trust)_ Say what happened in plain words: which network it went to, that the money is not lost from the chain but is out of reach from here, and what recovery would require.
- **DO** Give them the transaction reference and the output, so somebody technical can help.
- **DON'T** Say "transaction failed". It did not fail. It succeeded somewhere else, and telling somebody it failed sends them looking for a refund that is not coming.
- **DON'T** _(Costs trust)_ Promise recovery you cannot deliver. If it needs the other party's cooperation, say that is what it needs.
- **DO** _(Costs money)_ Make the network selection impossible to leave at a default, and restate the chosen network on the confirmation.
- **DO** Treat a first withdrawal to a new address as a different flow from a repeat one.
### Errors and failed payments
https://www.bitcoinsv.design/guide/patterns/errors-and-failed-payments/
- **DO** _(Costs trust)_ Say whether money moved in every message that follows a payment attempt, including when the answer is that nothing left the wallet.
- **DO** End every error with one thing the user can do, as a button where there is one.
- **DO** Put the error code and technical detail in an expandable details area with a copy button, so support can ask for it.
- **DO** Keep what the user entered. Return them to where they were with the amount, recipient and note still filled in.
- **DON'T** Write "Something went wrong" on its own. If you truly do not know what happened, say what you do know and whether money moved.
- **DO** Explain 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'T** _(Costs money)_ Offer "Try again" on a payment until you know the first attempt did not go out.
- **DO** _(Costs money)_ Tell 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'T** Show 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
https://www.bitcoinsv.design/guide/daily-spending-wallet/
- **DO** Read 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.
- **DO** Start from Connecting a wallet and Payments if you are building the real thing. Nearly every surprise traces back to one of those two.
- **DON'T** Treat 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.
- **DO** After 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
https://www.bitcoinsv.design/guide/daily-spending-wallet/first-use/
- **DO** Say what it does in the first line, in the words of someone who does not know what BSV is. "Pay anyone in seconds, for less than a penny" works. "Non-custodial BSV wallet with a standard app interface" does not.
- **DON'T** Lead with self-custody, sovereignty or decentralisation. They are reasons to stay, not reasons to install.
- **DO** Create the wallet and show it. The user can have a working, empty wallet within seconds of opening the app.
- **DON'T** _(Costs trust)_ Ask for an email address, a phone number or an identity document to create a wallet. None is needed, and requiring one discards the main advantage the product has.
- **DON'T** _(Costs trust)_ Offer a choice of key scheme during onboarding. Somebody setting up their first wallet has no basis to answer. See Private key management.
- **DO** Say it once, in one sentence, when money first arrives rather than when the app opens, alongside the key-backup prompt: "This money is yours. There is no password reset, so back up your recovery words now."
- **DON'T** Put a scrolling legal text and a checkbox between a person and an empty wallet. It protects nobody and teaches them that your warnings are furniture.
- **DO** _(Costs trust)_ Offer automatic encrypted backup of the wallet's records during onboarding, with one line saying where it goes, and turn it on only if the user says yes. Never switch remote storage on silently. Records are the part that must be continuous anyway. See Backups.
- **DO** _(Costs money)_ Prompt for the key backup once there is money to protect, at the latest when the balance first crosses an amount the user would mind losing, and let the user do it then and there.
- **DON'T** _(Costs money)_ Show recovery words during onboarding. A user with nothing to lose photographs them, and the screenshot outlives the carelessness.
- **DO** Say what each route will ask for before the user goes there. Being surprised by a passport request is where people stop.
- **DO** Make "ask someone to pay you" a first-class option. It is free, instant and needs no account, and it is easy to bury under the buy button.
- **DO** Show the handle as the primary thing to share, with the QR code as the in-person version of the same thing.
- **DON'T** Show a derived address. It is a one-time internal value and putting it on screen invites comparison nobody can usefully perform.
- **DON'T** Show a fee breakdown on a first receive. See Send fees.
- **DO** Make the reminder persistent but quiet: a banner on the home screen that does not block anything and does not reappear as a modal.
- **DO** Say what is at risk in terms of the balance, not in the abstract. "Back up your wallet to protect the 4,200 sats you're holding" is a reason; "secure your wallet" is wallpaper.
- **DON'T** Nag on a schedule. One persistent, dismissible reminder beats a modal every third launch, which people learn to dismiss without reading.
- **DO** _(Costs money)_ Say what the backup covers, because it is two things: "Your recovery words restore your keys. Your wallet backup restores your records: which money is yours and how to spend it. Keep both."
### Requesting
https://www.bitcoinsv.design/guide/daily-spending-wallet/requesting/
- **DO** Make the handle the primary thing on the receive screen, and the amount optional. Most of the time the payer knows what they owe.
- **DON'T** Generate a new address for each request and show it. On BSV a fresh key is derived per payment automatically, so the privacy reason for showing a new address has already been handled. See Payments.
- **DON'T** Add an expiry to a request. Nothing in a handle and an amount goes stale, so an expiry is a deadline with nothing behind it.
- **DO** Let the amount be entered in local currency and converted, which is how people think about being owed money.
- **DO** Allow an empty amount. "Pay me what you like" is a real case: tips, donations, splitting a bill the payer can see.
- **DO** Prefill it where you can. A request made from a shared bill can say what the bill was.
- **DON'T** _(Costs trust)_ Put anything personal in a note by default. It is shared with the payer and may end up in their records. See Wallet privacy.
- **DO** Offer copy and share as distinct actions, and confirm in place rather than with a toast the user is not looking at.
- **DO** Show it immediately and clearly: who paid, how much, and the note. A received payment is a good moment and the interface can say so.
- **DO** _(Costs trust)_ A public donation handle is permanently linked to everything paid to it. Suggest a separate handle for it. A tag such as @maya+donations@example.com sorts the payments but still resolves to Maya. See Paying by handle.
### Receiving
https://www.bitcoinsv.design/guide/daily-spending-wallet/requesting/receiving/
- **DO** Show who paid, how much, and the note. When the payer's wallet shares a profile name and avatar, an entry can read "Anna Keller, for lunch"; otherwise show their handle.
- **DO** Make it noticeable. A received payment is one of the few genuinely good moments in a finance app, and a silent list entry wastes it.
- **DON'T** Show a confirmation counter. It was verified on arrival, and counting blocks afterwards tells the user that your "Received" was provisional. See Transactions.
- **DO** Collect anything waiting on launch, verify it, and show what arrived while the user was away as a group rather than a burst of separate notifications.
- **DO** Say on the receive screen's help, or in Settings › Services, that payments wait in a message box when the wallet is closed. It is the one real cost of the peer-to-peer model. See Payments.
- **DO** Reject it, and tell the user in plain words that a payment arrived and could not be verified, so it was not accepted. Do not add it to the balance.
- **DON'T** Show a cryptographic error. "Merkle proof invalid" tells the user nothing they can act on.
- **DO** Use a different state for these: "Incoming" until it is mined, then "Received". It is genuinely less certain than a peer-to-peer payment and the interface should not pretend otherwise. See Legacy compatibility.
- **DO** Show it with whatever the sender provided, and let the user add their own note. An unexplained entry is the one they will be puzzling over in six months.
- **DON'T** Build a returns flow into a consumer wallet. Sending it back is just a payment, and the sender's handle is already there to pay.
- **DO** Because step 4 happens, the payer can be shown "Paid" at the same moment the recipient is shown "Received". Design both ends of that: the two people are often standing next to each other.
### Sending
https://www.bitcoinsv.design/guide/daily-spending-wallet/sending/
- **DO** Autocomplete from contacts before accepting free text, and make saving a new recipient the obvious next step after a first payment. The second payment to someone should never involve typing.
- **DO** _(Costs money)_ Resolve the handle and show the profile name and avatar before the confirm button. Paying "Anna Keller" is checkable; paying anna@example.com is only spellable. See Paying by handle.
- **DON'T** _(Costs money)_ Let a typed handle go straight to a confirm screen with no resolution step. The resolution is the check.
- **DO** Default to the unit the user set, and let them switch between it and their local currency in one tap. See Amounts and units.
- **DO** Allow very small amounts without complaint. A payment of 50 satoshis is ordinary, and a minimum blocks it for no reason.
- **DON'T** Show a "max" button that empties the wallet without saying so. Label it with the resulting amount.
- **DO** _(Costs trust)_ Show the running total against the allowance somewhere the user passes regularly, and make every agent or app payment visible in activity, marked as such. See Permissions and allowances.
- **DON'T** Prompt for every per-use payment. An article that costs 20 satoshis cannot carry a confirmation dialog, and a wallet that insists makes the whole category unusable.
- **DO** Make the recipient the largest thing on the screen. The amount is usually right; the recipient is what gets checked too quickly.
- **DO** _(Costs trust)_ Require the device's authentication to confirm, above whatever threshold the user set.
- **DON'T** Put an "advanced" disclosure on the review screen. If something matters enough to show, show it; if it does not, it belongs in the transaction's details afterwards.
- **DO** Label every wait with the step and, where there is one, the person. "Handing payment to Anna's wallet…" tells the user what is happening and to whom.
- **DON'T** Show a spinner with no words, or a full-screen loader for a step that takes a second. Both make an ordinary pause look like a fault.
- **DO** _(Costs trust)_ Say first whether money left the wallet.
- **DON'T** Show an error code as the headline. Put it in the details for support, with plain words on top.
- **DO** _(Costs money)_ Warn on every pasted address that money sent to an address on another network is very hard to recover, and offer the user's contacts or a handle instead.
- **DO** _(Costs trust)_ Make sure this works without your servers, any Pass, or any vendor service. It is the user's guaranteed way out if everything else in the stack fails. See Backups.
- **DO** Show "Paid" on acceptance and stop there for everyday amounts. A spinner that waits for a block makes the user wait for nothing. See Transactions.
### Send fees
https://www.bitcoinsv.design/guide/daily-spending-wallet/sending/send-fees/
- **DON'T** _(Costs trust)_ Keep 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.
- **DO** _(Costs trust)_ Leave the fee off the review screen entirely for ordinary payments, and put it in the transaction details afterwards for anyone who looks.
- **DO** In 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'T** Explain the fee model. A user who wanted to know about satoshis per byte will find it in the transaction details.
- **DO** Pay 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
https://www.bitcoinsv.design/guide/daily-spending-wallet/activity/
- **DO** Lead with the person or the app. A user scanning for "that payment to the café" is looking for the café, not for an amount.
- **DON'T** Show a transaction id in the list. It identifies nothing a person recognises. Keep it in the details, for support, as in the example below.
- **DON'T** Show change returned to the wallet as a separate entry. One payment is one row.
- **DO** Group by source and period: "The Satoshi Vision, 47 articles, 940 sats today" as one row that expands.
- **DO** Make the expanded view genuinely useful: what each payment bought, not just a list of identical amounts.
- **DON'T** Hide small payments behind a filter that is off by default. The user agreed an allowance and is entitled to see where it went without hunting. See Permissions and allowances.
- **DON'T** Group payments from different apps together. The grouping is per relationship; merging them loses the only thing that made it readable.
- **DO** Show them, visibly distinct from payments: an app connected, a permission granted or revoked, a Pass presented, an allowance exhausted.
- **DO** Make a permission grant findable later. "When did I let that app spend?" is a question users ask after something goes wrong, and it needs an answer.
- **DO** Search across names, handles, notes and amounts. People remember the café or the word "lunch", never a date range.
- **DO** Offer filters for direction, source and period, and show which are active. A filtered list that looks like an empty wallet is alarming.
- **DO** When a search finds nothing, name the term and offer to clear the filters.
- **DO** Provide a CSV or JSON export with the fields an accountant needs: date, counterparty, amount, local-currency value at the time, note, and the transaction id. Small payments should export individually even where they are grouped in the interface.
- **DO** Put the technical facts one tap down: transaction id, the state, the fee, and a link to an explorer. Someone chasing a problem needs them and nobody else does.
- **DON'T** _(Costs trust)_ Make an explorer the answer to "where is my money". If a wallet cannot explain the state of its own payment, that is a gap in the wallet. See Nodes and verification.
### Contacts
https://www.bitcoinsv.design/guide/daily-spending-wallet/contacts/
- **DO** Let the user rename a contact to whatever they call that person. "Mum" beats the profile name the handle returned, and it is what they will search for.
- **DO** Offer "save as contact" in the success state of a first payment. One tap at the moment the information is in front of the user beats a form they have to go and find.
- **DON'T** Ask for a name before resolving the handle. The resolution usually supplies one, and asking first makes the user invent a label for someone the wallet is about to identify.
- **DO** _(Costs money)_ Warn before any payment to a contact whose key has changed, and require acknowledgement: "Anna's wallet key has changed since you last paid her. If you weren't expecting this, check with her another way first."
- **DO** Record when the key last changed on the contact, so a user who is unsure can see whether this is the third change this month.
- **DO** Show a Pass as what it proves and who vouched for it, not as a generic tick. "Business name verified by Example Registry" is checkable; a blue badge is not.
- **DON'T** Imply a Pass means the person is trustworthy. It means an issuer attested to one attribute, which is a much smaller claim.
- **DO** Search across the name, the handle and the note. Users search for how they think of someone, which is rarely the exact stored name.
- **DO** Order by recently paid rather than alphabetically. A wallet's contact list is short and heavily weighted to a handful of people.
- **DON'T** Import the phone's address book by default. It is a large privacy ask for a feature most users do not need on day one, and it takes names out of the wallet's control.
- **DO** _(Costs trust)_ Name what is lost in the confirmation: the saved key, and therefore the warning if it changes. Payment history stays.
- **DON'T** Remove payment history when a contact is deleted. The money moved; that is a fact about the user's finances, not about the contact.
- **DO** Keep them in separate lists but make them feel related. What a user does with a person is pay them; what they do with an app is review and revoke what it may do. Those are different enough that one combined list serves neither. See Security.
### Security
https://www.bitcoinsv.design/guide/daily-spending-wallet/security/
- **DO** Use the platform's authentication rather than inventing a second one. It is what people already use, already trust, and already have recovery for.
- **DO** _(Costs trust)_ Let the user set a threshold above which authentication is required per payment, and default it to something sensible rather than to every payment or to none. We suggest an amount around the price of a coffee.
- **DON'T** Require authentication to open the app and again for every payment under a pound. People turn off what gets in their way, including the parts that were protecting them.
- **DO** Show spending against the allowance as a number and a proportion, per app. "The Satoshi Vision: 1,240 of 5,000 sats this month" is what a user needs to judge whether to keep it.
- **DO** _(Costs trust)_ Make revoking immediate and obvious, and say what it will break: the app stops working until it asks again.
- **DO** _(Costs trust)_ Expire spending and sensitive permissions by default, and tell the user when one is about to lapse rather than renewing it silently.
- **DON'T** _(Costs trust)_ Bury this in settings. It is the control panel for everything that can spend the user's money without asking each time.
- **DO** _(Costs trust)_ Set allowances per app, with a per-payment cap as well as a total. A thousand payments of a satoshi and one payment of a thousand satoshis are different risks.
- **DON'T** _(Costs money)_ Offer an unlimited allowance. There is no amount of convenience that justifies it, and a product offering it will have users who accepted it without reading.
- **DO** _(Costs trust)_ Give it its own confirmation, outside any bundle, naming who is asking and what they will be able to see.
- **DON'T** _(Costs trust)_ Include it in a connect-time grant. Nothing legitimate needs it at connect time.
- **DON'T** Show a modal on launch. It is the most ignored component in software, and it trains people to dismiss your warnings as a reflex.
### Privacy
https://www.bitcoinsv.design/guide/daily-spending-wallet/privacy/
- **DON'T** Build an address-reuse warning or a "generate fresh address" control. Both solve a problem BSV already solved, and their presence implies the default is unsafe.
- **DO** Prefer selections that keep outputs from unrelated counterparties apart. The saving from combining them is a fraction of a penny; the cost is linking two relationships.
- **DON'T** Expose coin control to ordinary users as the answer. On BSV the fee argument for it is gone, and the privacy argument is better served by selecting well than by asking somebody to.
- **DO** Make hiding reachable in one gesture from the home screen, and make it stick until deliberately reversed.
- **DO** Hide amounts in activity too, not just the headline balance. A hidden total above a visible list of payments is not hiding anything.
- **DO** Let users change them, or run their own. See Nodes and verification.
- **DO** Show, per app, what it has been granted. See Security.
- **DON'T** _(Costs trust)_ Reveal the user's identity key or profile to an app for a routine payment unless the user chose to. It permanently links a name to spending. See Identity.
- **DON'T** Write personal data on chain in the clear. There is no delete. See Wallet privacy.
- **DO** Put that explanation where a user looking for privacy settings would find it, rather than in a help article. The honest answer is more reassuring than a toggle that does nothing.
### Settings
https://www.bitcoinsv.design/guide/daily-spending-wallet/settings/
- **DO** Put appearance and motion preferences here and nowhere else. A theme toggle in the top bar costs width on every screen for something almost nobody touches.
- **DO** Set the BSV unit to satoshis by default. "0.00001250 BSV" is unreadable. See Amounts and units.
- **DO** Let the local currency be the primary display, with the satoshi amount secondary. Most people think in pounds.
- **DON'T** Offer a choice of satoshi symbol. None is standardised, and the words "sats" work everywhere.
- **DO** Put the connected apps dashboard one tap from the settings root. It governs everything that can spend without asking, and it is the most consequential screen in here. See Security.
- **DO** Show both halves of the backup with their own state: when the records were last backed up, and whether the recovery words have been written down. See Backup and recovery.
- **DO** Offer the recovery check here. It is where a worried user will look.
- **DO** Offer an encrypted export the user keeps themselves, so recovery never depends on your company existing.
- **DO** _(Costs trust)_ Name what is lost and what is not. The money stays where it is; the recovery words and the wallet backup together restore it on another device. If either is missing, say that deleting may make the money unrecoverable, in those words.
- **DON'T** _(Costs money)_ Accept a single tap. Require the balance to be acknowledged, and refuse outright if there is a balance and either part of the backup is missing, with a route to making it.
- **DO** List the services the wallet uses, each with one line on what it does and what it learns, and let them be changed. See Privacy.
- **DO** Put the app version and a copyable diagnostic summary here. It is the first thing support will ask for.
- **DON'T** Add a settings section only because wallets usually have one. Each of these asks the user a question with no useful answer.
### Automatic cloud backup
https://www.bitcoinsv.design/guide/daily-spending-wallet/backup-and-recovery/cloud-backup/
- **DO** Run it continuously in the background, and show when it last succeeded somewhere the user passes regularly.
- **DON'T** _(Costs money)_ Make it a manual export the user has to remember. They will not, and the gap will be exactly the payments they most wanted back.
- **DO** _(Costs trust)_ Explain it in one line that says where the backup goes and what opens it: "Back up your wallet to your cloud storage? It is encrypted on this phone, and only your recovery words can open it."
- **DO** Let the user decline, and say what declining means in a sentence rather than a warning dialog.
- **DON'T** _(Costs trust)_ Enable remote storage without saying so. It changes who can be compelled to hand over data, and that is the user's decision.
- **DO** _(Costs money)_ Encrypt the backup with a key derived from the recovery words, so the words and the backup restore everything with nothing else to remember.
- **DON'T** _(Costs trust)_ Protect the backup with a separate PIN or password. A short PIN can be guessed by anyone holding the file, and a password is one more secret to forget at the worst moment.
- **DO** _(Costs money)_ Say on the setup screen that nobody else can open or reset this backup: "Only your recovery words can open this backup. Nobody can reset them, including us."
- **DON'T** _(Costs money)_ Derive the encryption key from anything the provider also holds. If they can decrypt it, this is custody and the screen should not say otherwise.
- **DO** _(Costs money)_ Test recovery by wiping a device, not by logging out.
- **DO** Let the user choose a provider, or run their own. A backup tied to one company has that company's lifespan.
- **DO** Support more than one destination at once. Two independent copies is the point of the exercise.
- **DO** Show the last successful backup as a time, not a tick. "Backed up 2 minutes ago" is information; a green check is decoration.
- **DO** Say something when it has not run for a while, and say why where you can: no network, the service rejected it, or the user needs to sign in to the service again.
- **DO** _(Costs money)_ Say on this screen that it does not back up the keys. A user who sets this up and sees a tick will reasonably conclude they are finished. "Your wallet backup restores your records. Your recovery words restore your keys, and you still need to write them down."
### Backup and recovery
https://www.bitcoinsv.design/guide/daily-spending-wallet/backup-and-recovery/landing-page/
- **DON'T** _(Costs money)_ Tell 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.
- **DO** Put 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'T** _(Costs money)_ Call the whole thing "backup" and show one tick. That is the error this page exists to prevent.
- **DO** _(Costs money)_ Walk the recovery path assuming the device is gone, not locked, and remove anything that only exists on it.
### Manual backup
https://www.bitcoinsv.design/guide/daily-spending-wallet/backup-and-recovery/manual-backup/
- **DO** _(Costs money)_ Explain first, in two sentences: what the words do, and that a photograph of them is a copy of the money. Then show them.
- **DON'T** Lead with a warning screen full of prohibitions. "Never screenshot, never email, never store in the cloud" is three nos before a person knows what the thing is.
- **DO** Number every word and show them in a fixed grid. Order matters and a reflowing list makes it ambiguous.
- **DO** _(Costs money)_ Disable screenshots on this screen where the platform allows it, and say why rather than failing silently.
- **DON'T** _(Costs money)_ Offer copy to clipboard. The clipboard is readable by other apps and syncs between devices.
- **DO** _(Costs trust)_ Say on the words screen which wallets can restore them: "These words restore your wallet in apps that support BSV recovery words. Other wallets may show an empty balance."
- **DO** Confirm a few words at positions the user must read, then follow it with the question that matters: where is this going to live?
- **DON'T** Require every word back. People copy and paste to get past it, usually from the clipboard you just told them not to use.
- **DO** Ask, concretely, and offer sensible answers to pick from: a drawer at home, a safe, with a family member, a bank box. A choice is easier to make than a blank.
- **DO** Suggest two locations in different buildings, in plain words: "one at home, one somewhere else you can reach".
- **DO** Record what the user chose, so the recovery screen can remind them where they said they put it. A year later that is genuinely useful. Keep it inside the encrypted wallet backup, never in plain text with a provider.
- **DO** _(Costs money)_ Offer shares as an alternative, not an addition. Words and shares are two encodings of the same secret, so holding both makes two complete copies to protect rather than a safer arrangement.
- **DON'T** Offer shares to someone who will keep all five in the same drawer. Ask where they would go before offering the option.
- **DO** Offer a recovery check at any time, which asks for the words and confirms they match without moving money. Put it where a worried user would look, which is settings and the backup screen, not a help article.
- **DO** _(Costs trust)_ End the flow by saying what it did not do, and show the state of the other part: "Your recovery words restore your keys. Your wallet backup restores your records: which money is yours and how to spend it. Keep both." See Backup and recovery.
### Recovery
https://www.bitcoinsv.design/guide/daily-spending-wallet/backup-and-recovery/recovery/
- **DO** Design for the unplanned case and let the planned one benefit. A flow that assumes the old device is available fails exactly when it is needed.
- **DO** Restore keys first, then records. The keys prove the wallet is the user's and open the wallet backup; the records tell it where the money is. Do not ask for any other password at the records step.
- **DO** Put "I already have a wallet" on the first screen of the app, as prominent as "create one". Somebody recovering should never have to go through onboarding to find it.
- **DON'T** Call it "import". The user is not importing anything, they are getting their own wallet back, and the word matters when they are panicking.
- **DO** Autocomplete from the wordlist as they type, and accept a word as soon as it is unambiguous. It is the single biggest reduction in effort available here.
- **DO** Validate the whole phrase and say what is wrong: a word not in the list, a word in the wrong position, or a checksum failure meaning one word is wrong somewhere.
- **DO** Offer the alternative if the user has shares rather than words, on the same screen rather than behind a separate menu.
- **DON'T** Clear the field on an error. Retyping twenty-four words because of one mistake is how people give up.
- **DO** Find it automatically where you can, and fall back to letting the user point at a file they kept themselves.
- **DO** Say what the backup contains before restoring it: when it was made, and roughly what is in it.
- **DO** _(Costs money)_ When the keys are restored but no wallet backup is found, say so: "Your keys are restored. We could not find your wallet backup, so some payments may be missing. Anything you receive from now on will appear normally."
- **DO** _(Costs trust)_ Recover what can be recovered without records, and be explicit that it may be partial.
- **DON'T** _(Costs money)_ Report a balance of zero as though it were a fact. It is the balance of what the wallet currently knows about.
- **DO** Say what is happening in words rather than a bare progress bar: restoring keys, finding your backup, checking payments.
- **DO** Make it interruptible and resumable. Recovery happens on unfamiliar networks and a dropped connection should not mean starting over.
- **DO** Show what came back: the balance, recent activity, contacts, and any tokens.
- **DO** _(Costs trust)_ Name anything that did not, and say what it means. A token type the wallet does not support, records older than the backup, a Pass that needs reissuing.
- **DON'T** _(Costs trust)_ Show a success screen with no numbers on it. The user's question is "is my money there", and a tick does not answer it.
- **DO** _(Costs money)_ Re-establish the backup on the new device, and say so. A recovered wallet with no backup is one failure away from the same situation.
- **DO** _(Costs trust)_ Prompt the user to check whether the old device should be considered compromised, if it was stolen rather than lost. Moving to fresh keys is a real option and nobody will think of it unaided.
- **DO** _(Costs money)_ Run a full drill before the product holds real money: fund it, make payments across several counterparties, export, delete the installation, remove your own service from the path, and restore on a clean device with a different compatible wallet. See Backups.
- **DON'T** _(Costs money)_ Ship a recovery flow that has only been tested with the original app still installed. That is the one situation it will not be used in.
### Backups
https://www.bitcoinsv.design/guide/how-it-works/backups/
- **DON'T** _(Costs money)_ Protect 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.
- **DO** Keep wallet records on the device by default, and make remote storage a separate, explained opt-in.
- **DO** Encrypt records on the device before they are sent anywhere.
- **DO** Back up records automatically and show when the last backup ran.
- **DO** _(Costs money)_ Never 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
https://www.bitcoinsv.design/guide/how-it-works/transactions/
- **DO** Absorb 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.
- **DO** _(Costs money)_ Make the recipient and the amount unmistakable on the review screen. Once accepted, a payment cannot be cancelled.
- **DO** _(Costs money)_ Warn 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.
- **DO** _(Costs trust)_ Treat 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
https://www.bitcoinsv.design/guide/how-it-works/coin-selection/
- **DO** Select within a basket, and treat an output reserved by an app or a token as unavailable rather than as a cheap input.
- **DON'T** Merge 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.
- **DO** _(Costs trust)_ Show 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'T** Build a manual coin-choice screen into a consumer wallet. Choosing well automatically protects privacy better than asking the user to.
- **DON'T** Use the words "dust", "UTXO" or "coin selection" anywhere a normal user can see them.
- **DO** Never 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
https://www.bitcoinsv.design/guide/how-it-works/payments/
- **DO** Show "Paid" or "Received" as soon as the recipient's wallet replies "accepted". Do not wait for the payment to be mined.
- **DO** Don'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.
- **DO** _(Costs trust)_ Always 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
https://www.bitcoinsv.design/guide/how-it-works/wallet-privacy/
- **DO** Prefer selections that keep outputs from unrelated counterparties apart, even though combining them would be marginally cheaper.
- **DO** Let users choose or self-host their services, and say in one line what each one learns. See Nodes and verification.
- **DON'T** Query a service once per output or once per balance refresh in a way that maps the user's whole wallet to that provider. Batch, and prefer services that do not need to know which outputs are yours.
- **DO** Name what is being revealed, to whom, and for how long it keeps working. "This lets Example Audit see every payment between you and Example Shop, including future ones" is the honest version.
- **DON'T** Offer counterparty-wide revelation where a specific one would answer the question. Never bundle either into a general permission grant at connect time.
- **DON'T** Let an agent wallet reveal key linkage at all. See Wallet setups.
- **DON'T** _(Costs trust)_ Attach a user's identity key to routine payments because it makes your activity list prettier. It permanently links their name to their spending.
- **DO** Encrypt anything personal before it is written, and say plainly that what goes on chain cannot be deleted.
- **DON'T** Write personal data on chain in the clear, even where it looks harmless. There is no delete, and context changes over decades.
- **DON'T** _(Costs trust)_ Call payments "anonymous" or "private". Both are false.
### Overview
https://www.bitcoinsv.design/guide/how-it-works/private-key-management/overview/
- **DO** Have apps sign through the Wallet Application Interface, which uses a key derived for that purpose and never hands the app a private key.
- **DON'T** _(Costs money)_ Let the master identity key sign payments or messages directly, and never expose a child private key derived against anyone.
- **DON'T** _(Costs trust)_ Describe a shared or custodial key as self-custody.
- **DO** Start 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.
- **DO** Name what each scheme protects against, in the user's terms: a lost phone, a stolen phone, a dishonest person, a forgotten password.
- **DON'T** _(Costs trust)_ Offer 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'T** Describe a scheme as "secure" without saying against what. Every scheme here is secure against something and useless against something else.
### Automatic cloud backup
https://www.bitcoinsv.design/guide/how-it-works/private-key-management/cloud-backup/
- **DO** _(Costs money)_ Encrypt on the device, before anything is sent. The service should only ever hold a blob it cannot read.
- **DON'T** _(Costs money)_ Store 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.
- **DO** _(Costs money)_ Walk the recovery path assuming the device is gone, not locked, and remove every step that needs something only that device had.
- **DON'T** _(Costs money)_ Derive 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.
- **DO** Let users choose their provider, or run their own. A backup tied to one company is a backup with that company's lifespan.
- **DO** Support more than one location at once. Two independent copies is the point.
- **DO** _(Costs money)_ Show 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'T** _(Costs trust)_ Turn 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
https://www.bitcoinsv.design/guide/how-it-works/private-key-management/manual-backup/
- **DON'T** _(Costs money)_ Imply 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.
- **DO** Say which kind of words these are on the screen that shows them, and again on the screen that asks for them.
- **DO** Offer one method at setup, and let the user change it later.
- **DO** Explain what the words are and where to keep them before showing them.
- **DO** Confirm a few words at a position the user must read, and follow it with a plain prompt about where the paper will live.
- **DON'T** Block 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.
- **DO** Offer a recovery check the user can run at any time, which confirms the words match without moving money.
- **DO** Suggest two locations in different buildings, in plain terms: "one at home, one somewhere else you can reach".
- **DON'T** _(Costs money)_ Let 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.