# Savings, shared or inherited money The savings and inheritance reference designs and the three wallet patterns, plus the key-management and spending-condition pages they are built on. The costly rules come first; the full list follows, grouped by page. Every line carries the address of the sentence it came from. 306 rules: 57 that can cost money, 24 that can cost trust, 225 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. - **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. - **DO** _(Costs money)_ Build time conditions with nLockTime and nSequence, and test that an early spend fails. A test that only proves the late spend succeeds proves nothing. - **DO** _(Costs money)_ State where a pre-signed future transaction lives, who holds it, and what happens if the inputs are spent before its date. That is a backup requirement, not an implementation detail. - **DO** _(Costs money)_ Warn before a condition becomes unmeetable, not after. "One more lost key and this is unrecoverable" is useful; the same message afterwards is not. - **DON'T** _(Costs money)_ Let a user create a condition they have not demonstrably tested. Require a small-value rehearsal of the unlock path before real money goes in. - **DO** _(Costs money)_ Back up the wallet configuration alongside the key material, and include it in the recovery drill. A condition nobody can reconstruct is money nobody can move. See Backups. - **DON'T** _(Costs money)_ Finish setup without the user having restored from it once, with a small amount. An untested multi-key wallet has more ways to fail than a single-key one. - **DON'T** _(Costs money)_ Let the limit be raised with a single key. Raising the threshold for spending is itself a high-value action and needs the quorum. - **DON'T** _(Costs money)_ Let the everyday wallet pull from savings on its own. A compromised app would drain both, which defeats the whole arrangement. See Multiple wallets. - **DO** _(Costs money)_ Move the funds to a new arrangement when a key is lost, and say why: the old key still works on every output it is part of until the money moves. - **DO** _(Costs money)_ Back up the wallet configuration alongside the keys, and include it in the recovery drill. A quorum of signers with no record of the arrangement cannot spend. See Backups. - **DON'T** _(Costs money)_ Offer a period shorter than a few months. A path that opens while somebody is on a long trip is a theft risk dressed as a feature. - **DO** _(Costs money)_ Make sure they keep the pre-signed transaction, since without it the path is theoretical. The wallet should hold it and the backup should include it. - **DON'T** _(Costs money)_ Add somebody to a recovery path without telling them. The arrangement only works if they still have their key when it matters. - **DO** _(Costs money)_ Send the new recovery transaction to the recovery people as part of every refresh, and show on the home screen anyone who has not received it. - **DO** _(Costs money)_ Treat it as a change with consequences: move the money to new outputs first, so the removed person's copy stops working, then say who was removed and send the new transaction to the people who remain. - **DON'T** _(Costs money)_ Let somebody be removed from a recovery path without the wallet confirming the replacement transaction actually reached everybody who needs it. - **DO** _(Costs money)_ The pre-signed transaction is the part other backup designs have no slot for, and the part that makes this arrangement real. Back it up with the configuration, re-export it every time it is rebuilt, and include it in the recovery drill. See Backups. - **DON'T** _(Costs money)_ Let the wallet hold more than the rehearsal amount until the recovery path is built and every beneficiary has a copy. When the real money arrives, rebuild the path against it: money received after signing is not covered until the next refresh. - **DO** _(Costs money)_ Require a rehearsal with a small amount before the wallet holds anything real: fund it, spend from it with two keys, then build the recovery path and confirm every beneficiary has it. - **DO** _(Costs money)_ Re-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. - **DO** _(Costs money)_ Rebuild and redistribute it automatically after every payment in or out, and show on the home screen when a beneficiary is holding an out-of-date copy. - **DON'T** _(Costs money)_ Treat it as a one-time export during setup. It will be wrong after the first payment. - **DON'T** _(Costs money)_ Put key material in it. It is a map, not a key. It should be safe to leave with a solicitor. - **DO** _(Costs money)_ Check the recovery path assumes the owner's devices are gone. Every step that needs something only on their phone fails at exactly the moment it is needed. - **DON'T** _(Costs money)_ Put the configuration and a quorum of key material in the same place. Together they are the money. - **DO** _(Costs money)_ Run a full drill before the wallet holds anything real: fund it, export everything, delete the owner's installation, and have a beneficiary recover using only the document and their own key. - **DO** _(Costs money)_ Make sure every beneficiary gets the new transaction, and tell them the old one stopped working when the money moved. Two valid-looking copies with different dates is the worst state for somebody using this in an emergency. - **DO** _(Costs money)_ Make the new wallet's backup part of its creation, not a later prompt. A second wallet with no backup is a second way to lose money. - **DON'T** _(Costs money)_ Offer to connect an app to the savings wallet. A savings wallet that accepts app requests is an everyday wallet with a misleading name. - **DON'T** _(Costs money)_ Let a recovery key spend alone. It should be one of a quorum, not a back door, or the arrangement is not shared control. - **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. - **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. - **DO** _(Costs money)_ Treat 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. - **DO** _(Costs money)_ Say 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. - **DO** _(Costs money)_ Back up the wallet configuration with the same care as a key. It names every key in the arrangement. - **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)_ 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)_ Treat the condition as public when you design it. A recovery path that only works because nobody knows it exists is not a security property. - **DON'T** _(Costs trust)_ Build savings features into the everyday wallet. A wallet that is both ends up too slow for a coffee and too exposed for savings. - **DON'T** _(Costs trust)_ Show a pending shared payment as "Sending". Nothing has been sent, and the difference matters when somebody is waiting to be paid. - **DON'T** _(Costs trust)_ Offer 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. - **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. - **DO** _(Costs trust)_ Let a partly signed payment be abandoned cleanly, without leaving funds stuck. ## 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. ### 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. ### Spending conditions https://www.bitcoinsv.design/guide/patterns/spending-conditions/ - **DO** _(Costs money)_ Build time conditions with nLockTime and nSequence, and test that an early spend fails. A test that only proves the late spend succeeds proves nothing. - **DO** _(Costs money)_ State where a pre-signed future transaction lives, who holds it, and what happens if the inputs are spent before its date. That is a backup requirement, not an implementation detail. - **DO** State the minimum transaction version any script you document requires. A script that works in one version and silently fails in another is the worst kind of documentation error. - **DON'T** Assume every wallet or service in the chain of custody emits the version your script needs. Check before you depend on it. - **DO** _(Costs trust)_ Treat the condition as public when you design it. A recovery path that only works because nobody knows it exists is not a security property. - **DO** Describe a condition by its consequence: "Locked until 1 March 2027. Nobody can move this, including you." - **DO** Show the whole schedule on one screen, including the rules that have not taken effect yet. - **DO** _(Costs money)_ Warn before a condition becomes unmeetable, not after. "One more lost key and this is unrecoverable" is useful; the same message afterwards is not. - **DO** Let an unfinished setup be saved and resumed. These arrangements need several devices or several people and rarely come together in one sitting. - **DON'T** _(Costs money)_ Let a user create a condition they have not demonstrably tested. Require a small-value rehearsal of the unlock path before real money goes in. - **DON'T** Offer a condition builder to ordinary users. Offer two or three worked arrangements with names and plain descriptions, and let the complexity live in the templates rather than in the user's head. - **DO** _(Costs money)_ Back up the wallet configuration alongside the key material, and include it in the recovery drill. A condition nobody can reconstruct is money nobody can move. See Backups. ### Savings wallet https://www.bitcoinsv.design/guide/savings-wallet/ - **DO** Size it by what the everyday wallet should not hold. "How much would you be uncomfortable keeping on your phone?" is the question that produces a sensible split. - **DON'T** _(Costs trust)_ Build savings features into the everyday wallet. A wallet that is both ends up too slow for a coffee and too exposed for savings. - **DO** Walk setup one key at a time, saying for each where it is going and what losing it would mean. - **DO** Let setup be saved and resumed. Gathering devices rarely happens in one sitting, and a setup that cannot be resumed tends to be abandoned. - **DON'T** _(Costs money)_ Finish setup without the user having restored from it once, with a small amount. An untested multi-key wallet has more ways to fail than a single-key one. - **DO** Design on the assumption that the rule is readable. A recovery path that works only because nobody knows it exists is not a security property. See Multi-key. - **DO** Say which path a payment is taking before the user starts, not after. "This is above your limit, so it needs your signing device too." - **DO** Show progress through a multi-key signature as collected and outstanding, naming the device still needed. - **DON'T** _(Costs money)_ Let the limit be raised with a single key. Raising the threshold for spending is itself a high-value action and needs the quorum. - **DO** Make the transfer a named action with the destination prefilled, so it is two taps from the savings home screen. - **DON'T** _(Costs money)_ Let the everyday wallet pull from savings on its own. A compromised app would drain both, which defeats the whole arrangement. See Multiple wallets. - **DO** _(Costs money)_ Move the funds to a new arrangement when a key is lost, and say why: the old key still works on every output it is part of until the money moves. - **DO** _(Costs money)_ Back up the wallet configuration alongside the keys, and include it in the recovery drill. A quorum of signers with no record of the arrangement cannot spend. See Backups. - **DO** Prompt an occasional recovery check. A wallet opened twice a year is one whose backup has had a long time to go stale. ### Time-based recovery https://www.bitcoinsv.design/guide/savings-wallet/time-based-recovery/ - **DO** Explain the arrangement before any key is created, in terms of what happens rather than what it is made of: "You can always spend this. If you don't use it for a year, the people you choose can." - **DO** Name each key by where it is, not by its number. "This phone", "Signing device", "Anna's phone" is what the owner will need to recognise in two years. - **DO** Turn reminders on by default and say why: the path opening is the failure case, and a reminder is what prevents it. - **DON'T** _(Costs money)_ Offer a period shorter than a few months. A path that opens while somebody is on a long trip is a theft risk dressed as a feature. - **DO** Tell them what they have been given, in a message they can understand without the app: "Maya has named you on her savings wallet. You can't spend anything. If she doesn't use it for a year, you and one other person can move it on her behalf." - **DO** _(Costs money)_ Make sure they keep the pre-signed transaction, since without it the path is theoretical. The wallet should hold it and the backup should include it. - **DON'T** _(Costs money)_ Add somebody to a recovery path without telling them. The arrangement only works if they still have their key when it matters. - **DO** Show the date plainly on the home screen, as a date rather than a countdown. "Recovery opens 14 March 2027" is checkable; "in 237 days" is anxiety. - **DO** Remind well in advance, more than once, and through a channel that is not the app. Somebody who has stopped opening the app is exactly the person who needs reminding. - **DO** Notify the recovery people when the path is refreshed, so they know the arrangement is alive. - **DO** _(Costs money)_ Send the new recovery transaction to the recovery people as part of every refresh, and show on the home screen anyone who has not received it. - **DO** _(Costs money)_ Treat it as a change with consequences: move the money to new outputs first, so the removed person's copy stops working, then say who was removed and send the new transaction to the people who remain. - **DON'T** _(Costs money)_ Let somebody be removed from a recovery path without the wallet confirming the replacement transaction actually reached everybody who needs it. - **DO** Fold the path rebuild into device replacement automatically, and show it as a step so the owner knows it happened. - **DO** _(Costs money)_ The pre-signed transaction is the part other backup designs have no slot for, and the part that makes this arrangement real. Back it up with the configuration, re-export it every time it is rebuilt, and include it in the recovery drill. See Backups. ### Inheritance wallet https://www.bitcoinsv.design/guide/inheritance-wallet/ - **DON'T** Offer 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. - **DO** Read 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 https://www.bitcoinsv.design/guide/inheritance-wallet/overview/ - **DO** Choose 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'T** Build 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. - **DO** Show 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. - **DO** Judge 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 https://www.bitcoinsv.design/guide/inheritance-wallet/wallet-creation/ - **DO** Say how long it takes and what is needed before starting. Somebody who begins without their signing device and without telling their partner will not finish. - **DON'T** Explain multi-key, thresholds or timelocks here. None of it helps somebody decide whether to start. - **DO** Offer two or three named arrangements rather than a builder. "You and your partner, with your daughter inheriting" is a choice somebody can make; "2-of-4 with a 365-day recovery path" is not. - **DO** Name each key by where it lives rather than by number. In two years "Signing device in the study" is recognisable and "Key 2" is not. - **DO** Send a request the other person can act on without explanation from the owner. It should say who is asking, what it is for, and that they are not being asked for money. - **DO** Show the owner who has responded and who has not, and let them nudge. - **DON'T** Require everybody to be present at once. Coordinating three people in one sitting is the step most likely to stall. - **DO** Show the schedule as dates with names against them: "From 14 March 2027, Christina can move this on her own." - **DO** Default to a year. Shorter means more maintenance than anybody sustains; much longer means the beneficiaries wait at the worst time. - **DON'T** _(Costs money)_ Let the wallet hold more than the rehearsal amount until the recovery path is built and every beneficiary has a copy. When the real money arrives, rebuild the path against it: money received after signing is not covered until the next refresh. - **DO** End with the table from Overview, filled in with real names: who can spend alone, who can spend together, and who can act after the period. It is the last chance to catch an arrangement that does not match what the owner meant. - **DO** _(Costs money)_ Require a rehearsal with a small amount before the wallet holds anything real: fund it, spend from it with two keys, then build the recovery path and confirm every beneficiary has it. - **DO** Save after every step and make the unfinished wallet visible on the home screen with what is still needed. "Waiting for Christina's key" is a state the owner can act on a week later. - **DO** Remind, gently, about an unfinished setup. It is the one nag worth having. ### Onboarding cosigners https://www.bitcoinsv.design/guide/inheritance-wallet/onboarding-cosigners/ - **DO** Track per person whether they have received it, imported it, and confirmed. Three states, because "sent" is not "working". - **DO** Say 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." - **DO** Name who asked, and let them decline. Being added to somebody's inheritance arrangement is a real obligation. - **DON'T** Present 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. - **DO** Have 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. - **DO** Give 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. - **DO** _(Costs money)_ Re-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. - **DO** Send 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. - **DO** Let a cosigner see the arrangement at any time without the owner's involvement. ### Backup https://www.bitcoinsv.design/guide/inheritance-wallet/backup/ - **DO** _(Costs money)_ Rebuild and redistribute it automatically after every payment in or out, and show on the home screen when a beneficiary is holding an out-of-date copy. - **DON'T** _(Costs money)_ Treat it as a one-time export during setup. It will be wrong after the first payment. - **DO** Write it for somebody who will read it once, under stress, possibly years from now. No jargon, no screenshots of an app version that will not exist. - **DO** Regenerate it whenever the arrangement changes, and date it clearly so an old copy is recognisable as old. - **DON'T** _(Costs money)_ Put key material in it. It is a map, not a key. It should be safe to leave with a solicitor. - **DO** Walk the owner through it as places rather than categories: "Your words at home. A copy of the document with your solicitor. Christina has her own key and a copy of the document." - **DO** _(Costs money)_ Check the recovery path assumes the owner's devices are gone. Every step that needs something only on their phone fails at exactly the moment it is needed. - **DON'T** _(Costs money)_ Put the configuration and a quorum of key material in the same place. Together they are the money. - **DO** _(Costs money)_ Run a full drill before the wallet holds anything real: fund it, export everything, delete the owner's installation, and have a beneficiary recover using only the document and their own key. - **DO** Repeat the drill when anything changes. An arrangement that worked at setup and has had two key replacements since has not been tested. - **DO** If the drill cannot be completed by somebody who was not involved in setup, the arrangement has not achieved what it exists for, however correct the cryptography is. ### Making changes https://www.bitcoinsv.design/guide/inheritance-wallet/making-changes/ - **DO** Distinguish a planned replacement, where the old key still exists, from a lost one. They need different confirmations and the second is a security event. - **DO** Require the remaining quorum to authorise the replacement. One person should not be able to swap another out. - **DO** End the flow by confirming three things happened: the new configuration reached everybody, the succession transaction was rebuilt, and the recovery document was regenerated. Each is a separate failure if it is skipped. - **DO** Show progress as named people rather than a count: "Signed by Bob. Waiting for Alice or Christina." - **DO** Let the second signer see what they are approving, including the recipient and the amount, on their own device. That screen is the only independent check in the flow. - **DO** Let a pending payment be abandoned cleanly, and say so if it leaves outputs reserved. - **DO** Present it as a migration: a new arrangement is created and the balance moves to it, in a payment the current quorum approves. - **DO** Keep the old wallet's history after the move. The arrangement changed; the record of what was spent did not. - **DON'T** Imply somebody can be removed without the funds moving. They keep their key, and a key that still works on the old outputs is a key that still works. - **DO** _(Costs money)_ Make sure every beneficiary gets the new transaction, and tell them the old one stopped working when the money moved. Two valid-looking copies with different dates is the worst state for somebody using this in an emergency. - **DO** Let an emptied arrangement be archived rather than deleted, keeping its history and its recovery document. - **DON'T** Allow an arrangement with a balance to be deleted. Offer to move the funds first and say where they would go. ### Succession https://www.bitcoinsv.design/guide/inheritance-wallet/succession/ - **DO** Say which route is available, and when the other becomes available, on the first screen a beneficiary sees. "You and Alice can do this together now. On your own, from 14 March 2027." - **DO** Accept the configuration from a printed code as readily as from a file. Paper is the medium most likely to survive a decade and an estate. - **DO** Show the balance and what can be done with it immediately after import, before asking for anything else. The first question is "is it still there". - **DO** Offer "move everything to my own wallet" as the default action, not a generic send screen. It is what more or less everybody is here to do. - **DO** Let it be done in parts. Somebody may want to move a little first to be sure it works, and that instinct should be supported rather than treated as an error. - **DO** Make sharing the part-signed transaction work over whatever people already use: a message, email, a code on a screen. Do not require both parties to be in the same place, or to install anything beyond the wallet that holds their key. - **DO** Name the people, not the keys. "Waiting for David" is something a grieving person can act on. - **DO** Show the lock date plainly and whether it has passed. "This becomes valid on 14 March 2027" and, after that, "This can be sent now." - **DO** Check the inputs are still unspent before offering it, and say clearly if they are not: "This route is out of date because the wallet was used after it was prepared. Use the two-signature route instead." That is the single most likely failure and it must not present as a cryptic error. - **DON'T** Let a beneficiary broadcast a transaction whose inputs are gone and watch it fail. Check first and explain. - **DO** Offer to archive the arrangement once it is empty, keeping its history and its document. There may be an estate to account to. - **DO** Tell the other participants it was used, and when. Somebody holding a key should learn that the arrangement has been executed from the app rather than from a relative. - **DO** Design this flow first and work backwards. A setup flow that produces an elegant arrangement nobody can execute has failed at the only thing it was for. ### Multiple wallets https://www.bitcoinsv.design/guide/wallet-patterns/multiple-wallets/ - **DO** Give a savings wallet its own keys and its own recovery material. See Multi-key. - **DO** Offer two or three named arrangements rather than a wallet builder. "Everyday and savings" is a choice somebody can make; "configure a key scheme" is not. - **DO** Recommend a scheme from those answers and explain it in one line. "Two of three keys, because you said this is most of your savings and you want to be able to lose a phone." - **DO** _(Costs money)_ Make the new wallet's backup part of its creation, not a later prompt. A second wallet with no backup is a second way to lose money. - **DO** Show a combined total and the per-wallet breakdown together. People want to know what they have and where it is, in one glance. - **DO** Let activity be filtered to one wallet or seen across all of them, and always label which wallet an entry belongs to. - **DON'T** Make switching wallets a mode the user can forget they are in. A wallet-coloured header and the wallet's name on the send screen are cheap and prevent the worst mistake in this whole design. - **DO** Default to the everyday wallet for every payment, and make choosing another a deliberate step. - **DO** Say which wallet is paying on the review screen, in words, not only as a colour. - **DO** Show, per wallet, which apps are connected to it. See Security. - **DON'T** _(Costs money)_ Offer to connect an app to the savings wallet. A savings wallet that accepts app requests is an everyday wallet with a misleading name. - **DO** Show it as a transfer rather than a payment in activity: one entry, not an outgoing and an incoming. - **DO** Require the savings wallet's own authorisation for anything leaving it, on its own device where that applies. Topping up should always be a deliberate human action. - **DON'T** Offer an automatic sweep from everyday into savings without the user setting it up explicitly, and never the other direction. - **DO** When the user creates a payment request, ask which wallet should receive it, defaulting to everyday, and remember the choice per counterparty. - **DON'T** Publish both handles in the same place. Doing so links the two wallets for anyone reading. See Wallet privacy. - **DO** Let a wallet be archived rather than deleted: hidden from the main view, still able to receive, still restorable. - **DON'T** Offer to delete a wallet with a balance. Offer to empty it first, and say where the money would go. - **DO** Let users name and colour their wallets. "Rent" and "Holiday" are how people think, and a distinct colour is the fastest check that they are about to pay from the right one. - **DON'T** Rely on colour alone to distinguish wallets. Always pair it with the name. ### Shared wallet https://www.bitcoinsv.design/guide/wallet-patterns/shared-wallet/ - **DO** Ask what the group is protecting against before offering a rule. "One of us loses a phone" and "one of us might take the money" need different answers, and only the second needs a threshold above one. - **DO** Let an unfinished setup be saved and resumed. Getting three people to be available at once is the step most likely to stall. - **DO** Show whose key is set up and whose is outstanding, and give a way to nudge the people who are missing. - **DO** Include a recovery key held outside the group, or by the group's least active member, and say plainly what it can and cannot do on its own. - **DON'T** _(Costs money)_ Let a recovery key spend alone. It should be one of a quorum, not a back door, or the arrangement is not shared control. - **DO** Show who has signed, who has not, and how long it has been waiting. Most of the time a shared payment is blocked on a person, not on the network. - **DO** Notify the people whose signature is outstanding, and let anyone in the group nudge them without leaving the app. - **DO** Let a proposer cancel their own pending payment cleanly, without leaving funds reserved. - **DON'T** _(Costs trust)_ Show a pending shared payment as "Sending". Nothing has been sent, and the difference matters when somebody is waiting to be paid. - **DO** Attribute every payment to the member who proposed it and the members who approved it, and keep the note field prominent. "Who bought this and why" is the question a shared account gets asked most. - **DO** Design it as a migration with a clear explanation: a new wallet is created with the new members, and the balance is moved to it in a payment the current quorum approves. - **DO** Keep the old wallet's history visible after the move. The money changed arrangement; the record of what the group spent did not. - **DON'T** Imply a member can be removed without the remaining members acting. Anybody holding a key keeps it, and the only remedy is to move the funds somewhere their key does not work. ### Upgradeable wallet https://www.bitcoinsv.design/guide/wallet-patterns/upgradeable-wallet/ - **DO** Name 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'T** Offer 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. - **DO** Keep 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. - **DO** Show 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." - **DO** Let a user rehearse the new arrangement with a small amount before moving everything. - **DON'T** _(Costs trust)_ Offer 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. - **DO** This 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. - **DO** Offer 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 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. ### 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. ### External signers https://www.bitcoinsv.design/guide/how-it-works/private-key-management/external-signers/ - **DO** Show 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. - **DO** Prompt the user to compare the signer's screen with the computer's before approving, and say which one to believe if they differ. - **DO** Design 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'T** Build 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. - **DO** _(Costs money)_ Treat 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. - **DO** Let 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. - **DO** _(Costs money)_ Say 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'T** Require 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 https://www.bitcoinsv.design/guide/how-it-works/private-key-management/multi-key/ - **DO** Show 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. - **DO** Walk the setup one key at a time, and say for each one where it is going and what losing it would mean. - **DO** Let an unfinished setup be saved and resumed. Gathering three devices or three people rarely happens in one sitting. - **DON'T** Finish 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. - **DO** _(Costs money)_ Back up the wallet configuration with the same care as a key. It names every key in the arrangement. - **DO** Show what is being signed in plain terms on every device that signs, and how many signatures are collected. - **DO** _(Costs trust)_ Let a partly signed payment be abandoned cleanly, without leaving funds stuck. - **DON'T** Say "2-of-3 multisig". Say "Two of your three keys are needed to spend", and name the keys the way the user named them. - **DO** Pick 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.