Every rule about a product The whole guide, for a review with no particular product in front of it.
What is in it Every section except Contribute, whose rules are about writing this guide rather than about building anything, and Case studies, which has nothing in it yet.
Let the user hold their own keys, and make the path to doing so the default rather than an advanced option. 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. 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. 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. Costs money Make the irreversible step unmistakable. A payment cannot be recalled, so the review screen is the last line of defence. 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. 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. Write for someone who has never heard of a UTXO and never needs to. Internal vocabulary belongs in advanced views and documentation. Meet WCAG 2.2 AA: contrast, touch targets, screen reader labels, and amounts that read aloud sensibly. See Accessibility. 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. Support the standards rather than a bespoke integration. Design your connect flow around "your wallet", not a brand. 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. 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. Costs money Show the total a payment takes from the user, who it goes to, and that it cannot be undone, before they commit. 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. Costs money Name the limits. "This backup covers your keys but not your payment records" is the sentence that stops somebody losing money later. Describe a product as private, anonymous or instant without the qualifier that makes it true. Keep outputs from unrelated counterparties apart when selecting what to spend. Spending them together is the main remaining on-chain leak. See Coin selection. 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. Collect what you do not need, and never attach a user's identity to routine payments for convenience. Write personal data on chain in the clear. There is no delete. Let users choose or self-host the services your wallet depends on, and support more than one. See Nodes and verification. Weld a product to one provider's endpoint. That is your product's lifespan as well as theirs. Publish the reasoning with the design: what problem, what you ruled out, what you are unsure about. The last one gets the most useful replies. Share at the stage where the shape is clear and the details are not. Perfect work invites compliments; rough work invites help. Treat a repository as a portfolio. Something polished, final and unexplained gets no engagement, which is the one thing it needed. Record why, not just what, somewhere the next person will find it. A paragraph in a pull request is enough. State the licence on anything you publish, and keep the attribution on anything you reuse. A file with no licence is one nobody can safely build on. Reuse artwork without checking what its licence asks for. "It was on the internet" is not a licence, and CC BY costs you one line of credit. Pick a page you know something about, find one sentence that is wrong or unclear, and open an issue naming the page and the sentence. That is a complete, useful contribution and it takes ten minutes. Keep showing onboarding hints to somebody on their hundredth payment. 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. 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. 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. 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. 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. 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. Give every setup step a way back. A mistake during setup should cost a tap, not the wallet. Ask the person, after a test, to explain to a friend what they just did. What they cannot explain did not land. 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. 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. 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. Talk to the wallet through the connection standard rather than bundling one. The user keeps their keys where they already are, and your app works with wallets that did not exist when you shipped. Build a wallet inside your app because it is quicker. You inherit key custody, recovery and support, and the user now has one more set of keys to lose. Accept a pasted or scanned value without asking the user which kind it is. Detect it and say what you found. Support the peer-to-peer payment flow, where the payee's software supplies the output script and gets the transaction and its proof directly. It is the privacy-preserving default and it is how handles work. Costs trust Export the wallet backup in the wallet data format (BRC-38 and BRC-39), to a file the user holds. If your format is your own, say so plainly and publish it. Support restoring a backup written by other software, and report honestly what came across and what did not. Keep the only copy of a user's proofs on your server. That is custody by another name, whoever holds the keys. Verify Passes rather than issuing your own account. A person who has already proved who they are to somebody you trust should not have to do it again. Ask for the single field you need. A Pass can be shown selectively, and asking for all of it when you need one line is a design choice, not a protocol limit. Offer a plain export of contacts and labels, in a documented format, without a support request. Encode a handle rather than an address where you can. It is shorter, it survives being printed once, and it does not tie a person to one key forever. Support animated codes for anything that does not fit in one frame, such as a transaction with its proof going to an offline signer. Use upper case for codes made only of digits, capitals and $%+-./:. Those encode in a smaller, faster-scanning mode. Handles and addresses do not qualify. Use a transaction format that leaves out the input proofs. The receiver then has to ask a third party whether the transaction is real. Follow the fountain-coded air-gap transport (BRC-141) rather than a private encoding, so a user's existing signer works with your software. Exchange public keys and pending transactions in documented formats, and let a cosigner review and sign in whatever wallet they already use. List your dependencies somewhere a curious user can find them, and let the technical ones be changed. Let a user point at their own header source and their own broadcaster. Most will never touch the setting, and the option costs little. 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. Name the thing and its effect: "QR code, double tap to copy the payment handle". 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. Put the recipient before the amount in the reading order of a review screen. It is the field most worth hearing first. Give every scan a typed or pasted equivalent. A user who cannot aim a camera still needs to pay. Pair colour with a word or a symbol, always. Sent and received, plus and minus, not just red and green. 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. 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. Use fixed-width digits (tabular-nums), so a changing balance does not shift the layout under a magnified viewport. 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. 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. Write at a reading age of about twelve. Short sentences, common words, one idea each. 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. 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. Include people with disabilities in research, paid, rather than simulating them. Costs trust Preselect broad permissions, describe a permission as less than it is, or show a refused prompt again until the user gives in. All three teach people to tap Allow without reading. Costs trust Show the app's name from its manifest beside its verified domain in every prompt, and the domain alone when the app has no manifest. Write the description for each permission your app declares as what the user gets from it: "To save your reading position", not "Protocol access". Let the user approve some items in a grouped prompt and decline others, and let the app carry on with what was approved. Costs money Show an amount taken from the app's description text. Show the amount from the request itself, and warn if the two disagree. Show a waiting state in the app that tells the user their wallet is asking them something, and keep it until the wallet answers. Costs trust Cancel a wallet request because the user has not answered yet. A timeout turns a user who was reading into an error. Set an allowance to expire by default, and make a lasting allowance an explicit choice the user picks. Costs trust Cap an allowance per payment, per hour and per day as well as per month, where the wallet supports it, and show every cap in the same prompt. Costs trust Ask the user again when an amount is unusually high, the recipient is new, the payment pattern changes, an allowance that has ended would start again, or the app asks for a new protocol, basket, Pass field, the identity key or key linkage. Show the date a monthly allowance starts again beside what is left of it: "1,200 of 5,000 sats left, resets 1 December". After a refusal, say in one sentence what the app cannot do without the permission, and keep everything else working. Ask again only when the user next uses the feature that needs the permission, not on the next screen. Costs trust Make a revoke take effect at once, and say what stops working: "The Satoshi Vision can no longer charge you. It will ask again when you next open an article." Costs trust Ask for key linkage fresh each time, name who receives it and what they learn, and keep a local record of what was revealed to whom. Costs money Let an AI agent approve key linkage, share a Pass, or widen its own permissions. Use one button for a first visit and a return visit. There is no separate sign-up, because there is no account to create. Costs trust Ask for an email address or a password as part of signing in. If you need an email for receipts, ask for it afterwards, as its own optional step. Costs trust Sign users in with a key derived for your app. If your database leaks, the leaked keys can't be matched to the same person's activity elsewhere. Costs trust Use the root identity key as the account ID for a social network, game, shop or payment service. One breach then becomes a cross-app tracking event. Costs trust Request the wallet's root identity key without a reason you can state in the prompt. Approving a sign-in or a payment must never include it. Recognise a returning user without a wallet prompt where the wallet already holds your app's permission. Show a public key as the user's name. Use the name they gave you, or a plain label such as "Your account". Tell people before their first sign-in that the account belongs to their wallet: "Restore this wallet and your account comes back with it. A different wallet is a new account." Costs trust Say on sign-out that the app is still connected in the wallet, and where to disconnect it: "Signed out. Pixel Arcade is still listed in your wallet. Remove it there to stop it asking." Costs trust Call sign-out "Disconnect wallet". It does not touch the wallet's permissions, and the user will think it did. Ask for the narrowest field that answers the question: "over 18", not a date of birth. Say which Pass issuers you accept, and offer another way to qualify where the law allows. Make a Pass a condition of signing in when only one feature needs it. Ask at that feature. After the first sign-in, say in one line what your app received and what it cannot see: "Pixel Arcade can recognise you next time. It can't see your balance or your other apps." 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. Write "sats" or "satoshis" in words, and group digits in threes: 12,500 sats. 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. Adopt a satoshi glyph. None renders reliably, none is in common fonts, and your users have not seen any of them. 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. 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. 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. Lead with local currency for anything a person chooses to buy, with the satoshi amount beside it: "£12.00 (24,000 sats)". 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. Let the two be swapped in one tap, and remember the choice. 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. 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. 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. 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. Costs trust Abbreviate amounts in a financial context. "12.5k sats" saves four characters and introduces a rounding question. Costs trust Shorten a number with an ellipsis, ever. Reformat it or let it wrap. 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". 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. Round aggregates to a sensible precision in local currency. "About 24p today" is more useful than "£0.2384". 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. Never rely on colour alone to show direction. Pair the colour with a sign or a word. Costs trust Show the running total against the allowance wherever the spending is happening, not only in a settings screen. Costs trust Put a stop control next to that total. One action, no confirmation, effective immediately. Costs trust Renew an allowance that has ended without asking the user again. A limit that starts again each month within a live grant is normal, provided the reset date is shown beside what is left. Put the cost on the thing: "about 1p (20 sats)" on the article link, "5 sats per request" on the endpoint. Lead with local currency for anything a person chooses to buy, and with satoshis for anything software decides, with the other figure beside it. "About 1p" means something to a reader; "20 sats" means something to a developer. Round a per-use price up to something tidy because the real number looks odd. The real number is the product's best argument. Group by what the user was doing, not by transaction. "The Satoshi Vision, 14 articles, about 14p (280 sats)" is one row they understand. Let that row open into the individual payments, for the person who wants them and the accountant who needs them. Lead with the period total. "About 24p today" answers the question they actually have. Show a notification per payment. The first one is informative, the fortieth is why the feature gets switched off. Show the rate and the elapsed cost together, and update at a pace a person can read. A figure changing ten times a second is not information. Costs trust Make stopping obvious and instantaneous, and confirm that it stopped. "Stopped. You spent 340 sats." closes the loop. Costs trust Offer a ceiling before starting, not only an allowance. "Stop at 5,000 sats" is a different and more reassuring promise. Decide what happens when one payment in a hundred fails: retry, skip, or stop. Then tell the user which, once, rather than reporting each one. Costs trust Fail towards not charging. A user who got something free will forgive you; one charged twice will not. 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. 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. 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. 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. Costs money Put the network on the confirmation, beside the recipient, in the same weight as the amount. Costs money Say plainly what cannot be undone, before the button: "Sent to the wrong network, this usually cannot be recovered." 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. 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. Give them the transaction reference and the output, so somebody technical can help. 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. Costs trust Promise recovery you cannot deliver. If it needs the other party's cooperation, say that is what it needs. Costs money Make the network selection impossible to leave at a default, and restate the chosen network on the confirmation. Treat a first withdrawal to a new address as a different flow from a repeat one. Costs money Fund an agent by deliberate top-up, as a human action. A standing instruction to refill is the thing that turns a bounded loss into an unbounded one. Costs money Hand an agent the user's identity key or their Passes. It can have its own identity and act as itself; it should never be able to prove it is the person. Show all four on one screen, as current values rather than settings. "412 of 5,000 sats, 18 payments today, 3 services, 22 days left" is a status, and a settings form is not. Costs money Enforce limits outside the agent, in the wallet or the service holding its keys. A limit the agent checks itself is a limit an injected instruction can argue with. Costs trust Require a human for anything outside the scope: a new payee, a larger amount, a wider permission. Send the person a notification for it, rather than adding it to a list they have to check. Group by purpose, not by payment. "Research assistant: 6 sources, 240 sats" is reviewable; forty rows are not. Costs trust Record what each payment was for at the moment it happens. Intent cannot be reconstructed afterwards. Costs trust Surface the unusual rather than the complete. A payee it has never paid, or a payment larger than its usual, belongs at the top; the routine belongs in a total. Costs trust Report agent spending only in a log. A log is for after somebody already suspects something. Costs trust Put one control that stops everything, visible wherever the agent is, with no confirmation step. Confirmations are for actions you might regret, and stopping is not one of them. Say what stopping means: no further payments, work in progress abandoned, funds stay where they are. A user who is not sure what the button does will not press it. Costs trust Name the agent and its purpose wherever its spending appears. "Example Assistant, buying search results" is a thing a person can consent to; "automated payments" is not. Report on a human schedule. A daily summary a person reads beats a real-time feed nobody watches. Costs trust Ask for broad wallet access in order to read a token balance. Ask for the basket. An app that wants everything in order to show one number is the reason permission screens get ignored. Costs trust Show provenance as a short human sentence before a trade or a transfer: "Issued by Example Studio, 3 owners since, unbroken." The full chain belongs behind that line, not in front of it. Costs trust Resolve the real-or-fake question for the user rather than printing an ID and hoping. Match against issuers they already trust, and say plainly when you cannot. Costs trust Show a token's picture at the size of a decision without the provenance beside it. The picture is the part that is trivial to fake. Costs trust Say what is being written on chain, that it cannot be edited later, and what it costs. The cost is a fraction of a penny, which is worth saying out loud because people expect otherwise. Costs money Treat the supply decision as final in the interface, because it is. A field labelled "Supply" with no warning is a trap. Costs trust Name the issuer wherever the balance appears, not only at acquisition. "120 GBP, issued by Example Trust" is the honest form. Costs trust Draw a stablecoin balance in the same type as a BSV balance with no distinction. One is a bearer asset and the other is a claim on a company. Choose by what you need enforced on chain rather than by what is popular. A loyalty point and a regulated instrument are not the same design problem, and the stricter family exists for the second. Costs trust If you build a wallet, show a domain checked by the browser and a name an app gave itself differently, and say plainly when the name has not been checked. Costs money Let an installed app that claims a website's name inherit the permissions or allowances already granted to that website. Costs trust If you build a desktop or phone app, ask for less on the first connection than the website would: no standing allowance until the person has used the app and come back to it. When no wallet answers, say that the wallet may be closed as well as missing: "Open your BSV wallet, or install one, then try again." Detect the ordinary phone browser and say so before the person presses anything: "To pay here, open this page in your BSV wallet's browser." Offer to copy the link, and a way to install a wallet. Show a Connect button on a phone browser that cannot connect, or an error only after it is pressed. Show what the person is waiting for while the approval is in another app or on another device, and bring them back to the exact step they left. Treat leaving for the wallet as cancelling. A person who switches to approve and comes back should find the request still waiting, not a reset form. 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. Lead with self-custody, sovereignty or decentralisation. They are reasons to stay, not reasons to install. Create the wallet and show it. The user can have a working, empty wallet within seconds of opening the app. 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. 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. 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." 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. 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. 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. Costs money Show recovery words during onboarding. A user with nothing to lose photographs them, and the screenshot outlives the carelessness. Say what each route will ask for before the user goes there. Being surprised by a passport request is where people stop. 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. Show the handle as the primary thing to share, with the QR code as the in-person version of the same thing. Show a derived address. It is a one-time internal value and putting it on screen invites comparison nobody can usefully perform. Show a fee breakdown on a first receive. See Send fees. Make the reminder persistent but quiet: a banner on the home screen that does not block anything and does not reappear as a modal. 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. Nag on a schedule. One persistent, dismissible reminder beats a modal every third launch, which people learn to dismiss without reading. 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." 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. 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. Show a confirmation counter. It was verified on arrival, and counting blocks afterwards tells the user that your "Received" was provisional. See Transactions. 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. 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. 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. Show a cryptographic error. "Merkle proof invalid" tells the user nothing they can act on. 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. 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. 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. 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. 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. 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. Costs money Let a typed handle go straight to a confirm screen with no resolution step. The resolution is the check. Default to the unit the user set, and let them switch between it and their local currency in one tap. See Amounts and units. Allow very small amounts without complaint. A payment of 50 satoshis is ordinary, and a minimum blocks it for no reason. Show a "max" button that empties the wallet without saying so. Label it with the resulting amount. 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. 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. Make the recipient the largest thing on the screen. The amount is usually right; the recipient is what gets checked too quickly. Costs trust Require the device's authentication to confirm, above whatever threshold the user set. 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. 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. 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. Costs trust Say first whether money left the wallet. Show an error code as the headline. Put it in the details for support, with plain words on top. 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. 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. 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. 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. 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. Show change returned to the wallet as a separate entry. One payment is one row. Group by source and period: "The Satoshi Vision, 47 articles, 940 sats today" as one row that expands. Make the expanded view genuinely useful: what each payment bought, not just a list of identical amounts. 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. Group payments from different apps together. The grouping is per relationship; merging them loses the only thing that made it readable. Show them, visibly distinct from payments: an app connected, a permission granted or revoked, a Pass presented, an allowance exhausted. 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. Search across names, handles, notes and amounts. People remember the café or the word "lunch", never a date range. Offer filters for direction, source and period, and show which are active. A filtered list that looks like an empty wallet is alarming. When a search finds nothing, name the term and offer to clear the filters. 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. 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. 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. 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. 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. 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. 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." 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. 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. Imply a Pass means the person is trustworthy. It means an issuer attested to one attribute, which is a much smaller claim. Search across the name, the handle and the note. Users search for how they think of someone, which is rarely the exact stored name. Order by recently paid rather than alphabetically. A wallet's contact list is short and heavily weighted to a handful of people. 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. Costs trust Name what is lost in the confirmation: the saved key, and therefore the warning if it changes. Payment history stays. Remove payment history when a contact is deleted. The money moved; that is a fact about the user's finances, not about the contact. 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. Use the platform's authentication rather than inventing a second one. It is what people already use, already trust, and already have recovery for. 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. 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. 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. Costs trust Make revoking immediate and obvious, and say what it will break: the app stops working until it asks again. Costs trust Expire spending and sensitive permissions by default, and tell the user when one is about to lapse rather than renewing it silently. Costs trust Bury this in settings. It is the control panel for everything that can spend the user's money without asking each time. 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. 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. Costs trust Give it its own confirmation, outside any bundle, naming who is asking and what they will be able to see. Costs trust Include it in a connect-time grant. Nothing legitimate needs it at connect time. Show a modal on launch. It is the most ignored component in software, and it trains people to dismiss your warnings as a reflex. 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. Set the BSV unit to satoshis by default. "0.00001250 BSV" is unreadable. See Amounts and units. Let the local currency be the primary display, with the satoshi amount secondary. Most people think in pounds. Offer a choice of satoshi symbol. None is standardised, and the words "sats" work everywhere. 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. 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. Offer the recovery check here. It is where a worried user will look. Offer an encrypted export the user keeps themselves, so recovery never depends on your company existing. 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. 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. 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. Put the app version and a copyable diagnostic summary here. It is the first thing support will ask for. Add a settings section only because wallets usually have one. Each of these asks the user a question with no useful answer. Run it continuously in the background, and show when it last succeeded somewhere the user passes regularly. 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. 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." Let the user decline, and say what declining means in a sentence rather than a warning dialog. 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. 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. 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. 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." 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. Costs money Test recovery by wiping a device, not by logging out. Let the user choose a provider, or run their own. A backup tied to one company has that company's lifespan. Support more than one destination at once. Two independent copies is the point of the exercise. Show the last successful backup as a time, not a tick. "Backed up 2 minutes ago" is information; a green check is decoration. 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. 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." 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. 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. Number every word and show them in a fixed grid. Order matters and a reflowing list makes it ambiguous. Costs money Disable screenshots on this screen where the platform allows it, and say why rather than failing silently. Costs money Offer copy to clipboard. The clipboard is readable by other apps and syncs between devices. 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." Confirm a few words at positions the user must read, then follow it with the question that matters: where is this going to live? Require every word back. People copy and paste to get past it, usually from the clipboard you just told them not to use. 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. Suggest two locations in different buildings, in plain words: "one at home, one somewhere else you can reach". 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. 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. Offer shares to someone who will keep all five in the same drawer. Ask where they would go before offering the option. 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. 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. 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. 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. 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. Call it "import". The user is not importing anything, they are getting their own wallet back, and the word matters when they are panicking. 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. 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. Offer the alternative if the user has shares rather than words, on the same screen rather than behind a separate menu. Clear the field on an error. Retyping twenty-four words because of one mistake is how people give up. Find it automatically where you can, and fall back to letting the user point at a file they kept themselves. Say what the backup contains before restoring it: when it was made, and roughly what is in it. 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." Costs trust Recover what can be recovered without records, and be explicit that it may be partial. Costs money Report a balance of zero as though it were a fact. It is the balance of what the wallet currently knows about. Say what is happening in words rather than a bare progress bar: restoring keys, finding your backup, checking payments. Make it interruptible and resumable. Recovery happens on unfamiliar networks and a dropped connection should not mean starting over. Show what came back: the balance, recent activity, contacts, and any tokens. 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. 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. 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. 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. 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. 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. 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. 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. Walk setup one key at a time, saying for each where it is going and what losing it would mean. Let setup be saved and resumed. Gathering devices rarely happens in one sitting, and a setup that cannot be resumed tends to be abandoned. 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. 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. 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." Show progress through a multi-key signature as collected and outstanding, naming the device still needed. 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. Make the transfer a named action with the destination prefilled, so it is two taps from the savings home screen. 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. 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. 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. Prompt an occasional recovery check. A wallet opened twice a year is one whose backup has had a long time to go stale. 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." 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. Turn reminders on by default and say why: the path opening is the failure case, and a reminder is what prevents it. 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. 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." 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. Costs money Add somebody to a recovery path without telling them. The arrangement only works if they still have their key when it matters. 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. 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. Notify the recovery people when the path is refreshed, so they know the arrangement is alive. 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. 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. Costs money Let somebody be removed from a recovery path without the wallet confirming the replacement transaction actually reached everybody who needs it. Fold the path rebuild into device replacement automatically, and show it as a step so the owner knows it happened. 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. 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. Explain multi-key, thresholds or timelocks here. None of it helps somebody decide whether to start. 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. 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. 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. Show the owner who has responded and who has not, and let them nudge. Require everybody to be present at once. Coordinating three people in one sitting is the step most likely to stall. Show the schedule as dates with names against them: "From 14 March 2027, Christina can move this on her own." Default to a year. Shorter means more maintenance than anybody sustains; much longer means the beneficiaries wait at the worst time. 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. 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. 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. 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. Remind, gently, about an unfinished setup. It is the one nag worth having. Track per person whether they have received it, imported it, and confirmed. Three states, because "sent" is not "working". 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." Name who asked, and let them decline. Being added to somebody's inheritance arrangement is a real obligation. 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. 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. 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. 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. 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. Let a cosigner see the arrangement at any time without the owner's involvement. 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. Costs money Treat it as a one-time export during setup. It will be wrong after the first payment. 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. Regenerate it whenever the arrangement changes, and date it clearly so an old copy is recognisable as old. Costs money Put key material in it. It is a map, not a key. It should be safe to leave with a solicitor. 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." 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. Costs money Put the configuration and a quorum of key material in the same place. Together they are the money. 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. Repeat the drill when anything changes. An arrangement that worked at setup and has had two key replacements since has not been tested. 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. 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. Require the remaining quorum to authorise the replacement. One person should not be able to swap another out. 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. Show progress as named people rather than a count: "Signed by Bob. Waiting for Alice or Christina." 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. Let a pending payment be abandoned cleanly, and say so if it leaves outputs reserved. Present it as a migration: a new arrangement is created and the balance moves to it, in a payment the current quorum approves. Keep the old wallet's history after the move. The arrangement changed; the record of what was spent did not. 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. 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. Let an emptied arrangement be archived rather than deleted, keeping its history and its recovery document. Allow an arrangement with a balance to be deleted. Offer to move the funds first and say where they would go. 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." 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. 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". 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. 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. 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. Name the people, not the keys. "Waiting for David" is something a grieving person can act on. 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." 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. Let a beneficiary broadcast a transaction whose inputs are gone and watch it fail. Check first and explain. Offer to archive the arrangement once it is empty, keeping its history and its document. There may be an estate to account to. 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. 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. Give a savings wallet its own keys and its own recovery material. See Multi-key. 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. 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." 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. Show a combined total and the per-wallet breakdown together. People want to know what they have and where it is, in one glance. Let activity be filtered to one wallet or seen across all of them, and always label which wallet an entry belongs to. 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. Default to the everyday wallet for every payment, and make choosing another a deliberate step. Say which wallet is paying on the review screen, in words, not only as a colour. Show, per wallet, which apps are connected to it. See Security. 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. Show it as a transfer rather than a payment in activity: one entry, not an outgoing and an incoming. 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. Offer an automatic sweep from everyday into savings without the user setting it up explicitly, and never the other direction. When the user creates a payment request, ask which wallet should receive it, defaulting to everyday, and remember the choice per counterparty. Publish both handles in the same place. Doing so links the two wallets for anyone reading. See Wallet privacy. Let a wallet be archived rather than deleted: hidden from the main view, still able to receive, still restorable. Offer to delete a wallet with a balance. Offer to empty it first, and say where the money would go. 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. Rely on colour alone to distinguish wallets. Always pair it with the name. 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. Let an unfinished setup be saved and resumed. Getting three people to be available at once is the step most likely to stall. Show whose key is set up and whose is outstanding, and give a way to nudge the people who are missing. 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. 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. 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. Notify the people whose signature is outstanding, and let anyone in the group nudge them without leaving the app. Let a proposer cancel their own pending payment cleanly, without leaving funds reserved. Costs trust Show a pending shared payment as "Sending". Nothing has been sent, and the difference matters when somebody is waiting to be paid. 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. 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. Keep the old wallet's history visible after the move. The money changed arrangement; the record of what the group spent did not. 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. Mark free articles as plainly as paid ones on the front page, so the absence of a price is never mistaken for a missing label. Put a connect prompt, a sign-in button or a wallet logo on the front page. Nothing there costs money, so nothing there needs a wallet. Show enough of a paid article before the price for the reader to judge it: at least the headline, the standfirst and the opening paragraphs. Costs trust Name the price, in satoshis and local currency, on the same panel as the connect button. The reader should know what the first tap costs before the wallet opens. Costs trust Ask for a key made for this site only at connection, and nothing else: no identity key, no Pass, no spending grant. Treat "Not now" as an error. Keep the reader on the article they chose, with the free paragraphs still showing. Costs money Name the article being bought on the wallet's payment sheet, so the reader can see that the thing she tapped is the thing she is paying for. Open the rest of the article in place the moment the wallet reports the payment accepted, at the paragraph where the free part ended. Show the allowance offer before the reader has finished her first paid article, or on any free article. Treat "No thanks" as final for the visit. The reader goes on paying per article with a wallet prompt each time, and the card does not return until her next visit. Costs trust Give the allowance an end date in the request itself, and show that date on the wallet's sheet. When it ends, ask again and show what the last one was spent on. Show what the article just cost and what is left of today's allowance on the article itself, above the headline, every time the allowance pays for one. Mark articles the reader has already bought as read, without a price, so she never wonders whether opening one again will charge her. Costs money Charge for an article the reader has already bought, whether she returns to it on the same day or a month later. List what today's spending bought by article title, with the total first in local currency and the remaining allowance beneath it. Costs money Stop charging the moment the reader taps Stop, before any confirmation or animation, and say how much she spent today. Costs trust Say on the stopped state that the allowance still exists in the wallet, and where to remove it. Explain a used-up allowance on the article the reader was trying to open, with the free paragraphs still showing, and offer a one-time payment for that article. Raise the limit for the reader, or suggest a larger figure as the default. A new limit is a new request that she types or chooses. Costs money Show Try again on an article while the wallet reports its payment as still being sent. Let people browse every gig, date and price without connecting. Connecting is for buying and for seeing tickets already bought, not for looking. Name a wallet brand on the site's connect button or its explanation. The site works with any compatible wallet, and naming one tells everyone else they are in the wrong place. Costs trust Ask only for the sign-in key at this step. Payment, the age check and the ticket basket each wait for the screen where Anna first needs them. Treat "Not now" at this prompt as a failure. Put the Connect wallet button back, keep the gig page as it was, and say nothing louder than the button. Show the "what we can and can't see" line once, after the first sign-in only, on the page Anna was already on rather than a separate welcome screen. Costs trust Ask for a name or email straight after sign-in to make the header friendlier. "Your account" is enough until Anna chooses to add something. Try a silent sign-in on load when the site has seen this browser before, and fall back to the Connect wallet button only if the wallet does not answer without a prompt. Under the connect button, say in one line that the account follows the wallet, not the device: "Use the same wallet on any device to see your tickets. A different wallet starts a new account." Costs trust Offer to "find" Anna's account when a different wallet connects. The site cannot tell it is her, and guessing from anything else would link identities she kept apart. Show the age step only for gigs that have an age limit, and name the venue's rule as the reason: "The Corner Room is over 18 only", not "Verification required". Costs trust List on the site, before the wallet prompt opens, the one thing the site will receive and the things it will not, in the same words the wallet is about to use. Costs trust Ask for a date of birth and work out the age on the site. The site then holds a fact it never needed, and the wallet's field-level choice is wasted. Request the field with Example Tickets named as the verifier, and if the venue itself will receive the answer, name the venue in the request too, so the wallet's "Sent to" line is true. Costs trust Ask for the same single field, "over 18", at every age-restricted checkout, and never widen a later request because an earlier one was granted. Name the issuers the site accepts, and who chose them, on the screen that tells somebody they have no suitable Pass. Offer a way to buy that does not depend on a Pass where the venue allows one, so missing a Pass costs Anna a step at the door rather than the ticket. Send Anna to an issuer and empty her basket behind her. Keep the gig and the ticket she chose waiting for when she comes back. Word a refusal as Anna's decision and its one consequence for this gig, and leave every other part of the site, including other gigs, working as before. Reopen the wallet's Pass prompt automatically after a refusal, or on the next page load. The next request waits for Anna to press Ask my wallet again. Costs money Show on the review screen the same sats amount the wallet's prompt will show, and if the rate moves before Anna presses the button, update the figure on this screen first rather than letting the wallet show a different number. Name who receives the money and who the ticket is for in one line. Anna is paying the ticket site, for a venue, and both names belong on the screen. Say on the review screen what Anna can do with the ticket afterwards, give it away or not, refund it or not, before she pays rather than in the terms. Costs money Add a booking fee or any other charge after the review screen. If the product charges one, it is part of the price shown here. Ask for the tickets basket in the first purchase's prompt, as a separate item Anna can decline, and never at sign-in. Costs trust Ask for a spending allowance "to make the next purchase faster". A site people pay a few times a year should ask each time. Tell Anna where the ticket is, in her wallet, on the confirmation, so she does not wait for an email that is not coming. Write the gig name, venue, date and what the holder may do with the ticket into the token when it is issued, so any wallet can show it without asking the site. Let a picture of the ticket be enough to get in. The picture is the part anybody can copy; the door has to check that the person in front of it holds the ticket now. Label the site's own control Sign out, and put the one-line pointer to the wallet directly beneath it, so the two actions are read together. Costs trust Put a "Disconnect" button on the site that only clears the session. Anna would believe the site lost its access when the wallet still lists it. Say on sign-out that it applies to this device only, and that the ticket is unaffected, in one line on the page she lands on. Sign Anna straight back in on the next page load after she pressed Sign out. Wait until she presses Connect wallet again on this device. Treat a sign-in that suddenly prompts again as a returning user whose wallet was cleared or who removed the site, and show the ordinary connect flow without asking why. Costs trust Store the result of an age check, the gig and the date, and never the Pass or any field beyond the one asked for, and say so on the site's data page. Costs money Make a ticket valid at the door from the token alone, so it still works after Anna deletes her data or removes the site from her wallet. Costs trust Keep anything about Anna that this page does not list. If the site starts storing something new, the page changes the same day. Say on Scout's first screen, in one line, that the worst case is the amount Anna sends it. "Scout can't spend more than you give it" is the reassurance the whole design rests on. Costs trust Offer to connect Scout to Bitcoin SV Wallet with a spending permission as a quicker alternative. Two routes to the same task make the safer one look like the slow one. Show the services row as named services with their prices, never as a field where Anna types an address or a domain. Translate the budget into what it buys for this task: "10,000 sats is about 2,000 data requests, or 500 articles." The number only means something beside its use. Offer "no end date" as an option on this screen. A delegation with no end is the one nobody comes back to review. Request exactly the budget Anna set. If she changes the amount in Bitcoin SV Wallet, show the new figure as Scout's budget on the next screen rather than holding on to the old one. Costs trust Ask Anna to switch on a low-balance refill during funding. Topping up is a separate decision each time, made when she can see what the last budget bought. List on the review what will come to Anna for approval: "a new service", "anything over 100 sats", "going over 3,000 sats in a day". The approvals are part of the deal, not a surprise later. Name on the review the one device where approvals will arrive, and accept approvals only there. Say when and where the daily summary will arrive, and let Anna change the time on this screen. Disable Start Scout until the top-up has arrived, and say so beside the button: "Waiting for 10,000 sats from Bitcoin SV Wallet". Move the status strip into a settings page once setup is done. Anna checks on Scout from where its work is, and that is where the total and the pause belong. Show each purchase in the task view beside the step of the task it served, so "4 articles" reads as part of the research rather than a separate bill. Notify Anna's phone for payments inside the limits. She is not watching on purpose, and a buzz per article would teach her to silence Scout entirely. Costs money Show the amount and the payee from the payment Scout's wallet refused, and Scout's explanation separately, labelled as Scout's. If the explanation names a different amount, show both and say they disagree. Name every limit the request breaks: "New service" and "Over 100 sats a payment". Anna is deciding whether the limits were wrong or the request is. Costs money Put "Always allow" or "Add to Scout's services" on the approval screen. Widening Scout's scope from a notification is how one odd request becomes a standing permission. Costs money Let the assistant approve its own request, or accept an approval from anywhere other than Anna's own device. Show what the budget bought on the same screen that says it is spent. Anna decides whether to top up by judging the last budget, not by looking at a zero. Offer to finish the task with what Scout has already bought, as an equal choice beside topping up. Costs money Refuse a payment above the price shown on the limits screen, even when it is inside the per-payment limit, and send it to Anna like any other request outside scope. Costs trust Say plainly when a service kept the money: "Example Data was paid 15 sats and sent nothing back." Whether money moved is the first thing the errors pattern asks every failure to answer. Costs money Cap paid retries to one service at a fixed number per task, show that number on the limits screen, and stop using the service when it is reached. Each retry is another payment, and a loop of small failures is how an agent spends its budget on nothing. Put refused payments, approvals Anna gave, and any service that kept money without delivering at the top of the daily summary, above the total. Say "Nothing unusual today" when that is true. A summary that only ever lists problems leaves Anna unsure whether a quiet one means no problems or a missing section. Send a summary on a day Scout spent nothing and nothing changed. A daily message with no news is the fastest way to have the useful ones ignored. Mark every payment in the trail with the task it served. A payment that belongs to no task is itself something to flag. Show refused payments in the trail beside the ones that went through, marked "Refused, nothing sent". What Scout tried to buy is part of what it did. Costs trust Record Scout's reason with each payment at the moment it is made, and keep it unchangeable. A reason written afterwards is a story, not a record. Costs trust Present Scout's note in the same style as the amount and payee. The amount and payee come from the payment; the note comes from the agent, and the screen should show the difference. Put Pause Scout on any payment Anna has flagged, so she can stop it from the place she noticed the problem. Costs trust Offer "Get a refund" or "Dispute" on an agent payment. Scout cannot reverse a payment, and a button that implies it can will be pressed and will fail. Costs trust Show the exact time spending stopped, and whether a payment was already on its way at that moment: "The last payment, 20 sats to The Satoshi Vision at 14:32, went through before you paused." Costs money Make pausing take effect in Scout's wallet, not in the assistant. Spending stops even if the assistant is still running or has not noticed. Ask "Are you sure?" before pausing. Pausing costs nothing and can be undone; a question in front of it only slows down the person who is worried. Say how far the task got and what was already bought, so Anna can decide between resuming, finishing with what there is, and ending. Say what happened to any approval that was waiting: still waiting while paused, cancelled when revoked. Costs trust Let Scout's stop message argue for resuming. "I was nearly there" turns a safety control into a negotiation with the thing being stopped. Costs trust Say on the revoke screen that the money left in Scout's wallet stays there until Anna sends it back, and show the amount. Bundle revoking with deleting Scout's activity. Anna may end the job precisely because she wants to look at what happened. Costs money Offer only the wallet that funded Scout as the destination for what is left. A payee chosen at the end of a delegation is a payee nobody vetted. Close the job with the three numbers Anna will want to reconcile: what she sent, what Scout spent, and what came back. Write recruiting criteria about what people do and what they have, never about what they think of bitcoin. Set a quota for newcomers in every study of a flow a newcomer will meet, and fill it before you fill the others. Recruit only through the ecosystem's own forums, groups and channels. Use a general recruiting panel, local community groups, or the customers of the business you are designing for. Screen on behaviour within a recent, stated period ("in the last three months"), not on habits ("do you usually"). Costs trust Ask how much somebody holds or earns on a screener. You do not need it to recruit, and you are now storing it. Offer the incentive in local currency, and in satoshis only if the participant asks for it or agrees to it after you have explained what receiving it involves. Pay the full incentive to anybody who turns up, including somebody who stops halfway or cannot complete a task. Make any part of the incentive depend on completing a task, finishing a flow, or keeping the test money. A participant paid for success will find a way to succeed. Store screener answers separately from session notes, linked by a participant code, and delete the screener data when the study is written up. Costs trust Record a participant's real handle, address or transaction in your notes. If one appears on screen, stop the recording and remove it. Costs trust Give every participant test money in a test wallet you created, and never ask them to use their own wallet. Tell the participant, before the first task, that the money is not real and that nothing they do can cost them anything. Reset the test device and wallet between participants, so nobody inherits the last person's permissions, contacts or history. Write the tasks as goals in the participant's words, and read them out exactly as written in every session. Name the button, the menu or the term in a task. "Connect your wallet" tests whether they can find the word you just said. After each task, ask "what do you think just happened?" before asking anything else, and write down the answer word for word. Collect and destroy every printed recovery card at the end of each session, and retire the test wallet it belonged to. Step in during the recovery drill until the participant has clearly given up. Note when and why you helped, and count the task as assisted. State each finding as what was observed, with a count, before stating what you think it means. Report the number of participants and how they were recruited beside every finding, however small the study. Say how confident you are and why, including what result would change your mind. Report a percentage from a small study without the counts behind it. "4 of 7" is honest; "57%" suggests a precision you do not have. Leave out a result because it contradicts the guide or your design. A contradicted rule is the most useful thing a study can report. Cite the rule a finding tests by its permanent link, copied from the checklist, rather than by page title or a paraphrase. Replace every participant's name with a code, and keep the key that links codes to people separately from the write-up, then delete it when the study closes. Costs trust Include a handle, address, transaction or balance from any participant's real wallet in a write-up, even partly masked. Generalise details that could identify somebody in combination: "a shop owner in a small town", not the town and the trade. Publish a screenshot or recording frame without checking it for real names, notifications, and other apps' content in the background. Submit a finding from a small study rather than waiting for a large one. Say how small it was; the template already asks you to. Charge for the unit the user already thinks in: an article, a song, a search. A price per kilobyte or per token is a price nobody can predict. Choose metering only when the value genuinely accrues over time. If the user would describe what they bought as one thing, charge for one thing. Costs trust Build a prepaid balance that your app holds in place of an allowance in the user's wallet. Money sitting with you is a custody decision, and the allowance does the same job without it. See Custody as a product decision. Put the tip where the value was felt, at the end of the article or the stream, and send it to the creator's handle, saying if the platform keeps any of it. Offer a cap that matches what the subscription used to cost, so a heavy user never pays more than they would have. "Never more than the monthly price" is a promise people understand. Remove the flat price and leave only per-use pricing for a product people use daily. The ones who used it most are the ones the change punishes. Say on the paid page what the payment replaces: "No ads on this article, you paid about 1p (20 sats) for it." The connection between paying and the absence of ads is the product. Charge per use and show advertising on the same page. The user paid to remove the thing you are still showing them. Pick one model as the default and add others as options. A product offering per-use, metered and tipping on the same screen has asked the user to choose a business model. Decide which currency each price is set in, and write it down. A price set in local currency moves in satoshis as the rate moves; a price set in satoshis moves in local currency. Both are fine, and mixing them by accident is not. Costs trust Fix the satoshi amount when you show the price, and hold it until the user pays or leaves the screen. A figure that changes between the quote and the payment reads as a bait and switch. Put the price on the button or link that spends it: "Read for about 1p (20 sats)". The user should never need to open a pricing page to know what one tap costs. Tell the user what their allowance buys in your units: "500 sats a day is about 25 articles." An allowance in satoshis alone leaves them to do the division. Costs trust Round the local-currency figure up, never down, and say it is approximate: "about 1p", "less than 1p". The user should never pay more than the figure suggested. Round totals, not each item. Twenty articles at "about 1p" each should add up to the true total, not to twenty rounded pennies. Announce a price rise before it applies, in the product, to people with an active allowance, and say what their allowance now buys. Costs trust Raise a price on users mid-allowance without telling them. They granted the budget against the old price, and spending it faster is a change to what they agreed to. Make the step from free to paid one small payment, not a plan. "This article is about 1p (20 sats)" converts a reader; "Upgrade to Pro" asks them to commit before they know. Ask for a wallet connection to use the free tier. Ask when the user first reaches something that costs money, as the permission advice says for every capability. Leave the network fee out of your price list. The payer's wallet adds it; when you pay out, for a refund or a reward, pay it yourself and do not deduct it from the amount. Costs trust Keep what you need to pay a customer back with each payment you take: their handle, or a way to reach their wallet, and what the payment was for. Keep it in your order records, not your analytics, and delete it when the refund window closes. Show a refund in the user's activity as a payment from you that names the original purchase: "Refund for 3 articles, 60 sats". Costs trust Promise to "reverse" or "cancel" a payment in support copy. The word teaches users something false about every other payment they make. Define activation as a first payment made or received, and measure the time from first opening the product to it. Count a created wallet as an activated user. Creating a wallet takes no input and no time, so the number grows whether or not anybody uses the product. Measure grants and refusals per permission, not per prompt. A prompt that asks for three things and is refused does not tell you which of the three caused it. Treat a rising refusal rate after adding a permission as a finding about that permission, and test asking for it later, at the feature that needs it. Track what happens when an allowance is used up: topped up, left empty, or revoked. Those are your renewal, your dormant users and your churn. Measure repeat payments per user over a period you choose in advance, such as a second payment within a week of the first. A single payment is curiosity; a second is a habit starting. If you make a wallet, measure the share of users holding money who have both parts of a backup in place, and report it next to active users. Every user without both is one lost phone away from losing money. Count a backup as in place only once the user has finished it. We suggest treating a wallet backup as missing if it has not run since the user's last payment. Measure how much of each agent budget is used, how often the agent asks a person to approve something outside its scope, and how often the stop control is pressed. Report payment counts as growth for a per-use product. Count people who paid, and how often they came back. Measure inside your own product, against your own events, and keep identities out of the analytics. What a user paid for in your app is yours to count; what else they did on chain is not. Costs trust Attach a user's identity key or handle to payment records in your analytics. Joined with the public ledger, that table names their spending to anyone who gets a copy. Costs trust Run chain analysis on your own users to fill gaps in your analytics. If a number can only be found by tracing payments, decide you do not need it. Pay the referral when the new user does the thing you value, such as their first payment, and pay it at once. A reward that arrives days later has lost most of its point. Say in the payment who it is for: "Referral reward: Anna joined using your link." A payment with no memo looks like a mistake; a memo that reports what a friend bought tells the referrer too much. Pay for a contribution after you have judged it, and say what was accepted. Paying on submission rewards volume, and volume is what fake accounts produce. Publish the rate before people contribute: "50 sats for each accepted translation." A reward people can predict is one they can decide to work for. Costs trust Send credit to try after a first action you value, never on wallet creation or connection alone. Send credit to try as a real payment to the user's wallet, not as a balance inside your app. A real payment teaches them how the wallet works; an in-app balance teaches them how your app works and leaves you holding the money. Restrict credit to try so it can only be spent with you, then call it a gift. Either give money, or give a free trial, and name it accurately. Make the user's handle and a payment request one tap away from wherever they would want to share them, with your product's name on the landing page the recipient sees. Design the page a payment link opens for somebody without a wallet: what it is, who sent it, and the shortest route to receiving. The sender has already done your marketing. Tie every reward to something that costs a fake account real effort or real money: a purchase, an accepted contribution, a payment received from somebody else. Cap rewards per referrer and per period, and watch for clusters: many new users paid by the same referrer, or rewards forwarded straight to one wallet. Pay a reward for creating a wallet or connecting one. Both are free to repeat, so the reward pays for the repetition. Write down which arrangement your product uses, in one sentence a user could understand, and put that sentence in the product before the user holds money with you. Costs trust Call an arrangement self-custody if your service can move the user's money or decrypt their key. Say what it is. Costs money Make sure users can move their funds out without your service, and say how in your exposure statement. See Disclose what you use. Costs money Plan what happens to users' money if your company stops, before launch. The plan is part of the product, and users of a service holding a share need it as much as users of a custodial one. Costs money Run a recovery drill on a wiped device before launch, whichever arrangement you choose, and repeat it after any change to backup or key handling. Costs money Train support on the one thing they cannot do. If you do not hold the keys, support must never imply it can recover funds, because that sentence is what impersonators say next. Costs trust Keep a balance on users' behalf just to make many small payments smoother. An allowance in the user's own wallet does that job without the custody. Start from the user's own wallet and move along the scale only for a reason you can name, such as a user group that will not keep a backup. Each step towards holding funds buys easier onboarding with a responsibility you cannot hand back. Choose your product's point on the expression scale before writing the store listing, the landing page or the onboarding, and check all three against that point before release. Place the product by who it is for. If your primary user would describe the product without the word bitcoin, keep the network in the background. Costs money Name the network as "Bitcoin SV" or "BSV" wherever a user adds money, takes it out, or pastes an address, even in a product that names it nowhere else. Name the network on screens where it changes nothing the user does. On a "Read for about 1p (20 sats)" button, the network is plumbing. Costs trust In interface strings, write "Bitcoin SV" or "BSV". Never write "bitcoin" alone on a screen, a button or a store listing, where a user can read it as another network. Open the landing page with what the user gets, in one sentence they could repeat: "Read any article for about a penny, without an account." Include an honest line about what the product is not good for, such as holding savings in a connected wallet. It answers the catch the reader is looking for. Put the network name and how payment works in a short section below the fold, for the readers who want it, rather than in the headline. Write each value statement as an outcome with a number or a concrete detail: "Paid while the customer is still at the till", "No account, no card, no email address". Describe the product with words the user has to look up: on-chain, non-custodial, peer-to-peer, the Metanet. If a term needs the glossary, it does not belong in a headline. Campaign for the network in product copy. Users came for the product, and advocacy beside their balance makes their money feel political. Costs trust Mention the price of BSV, past gains or future value anywhere in marketing for a product that is not about investing. Copy that reads as a promise of returns attracts the wrong users and alarms the right ones. Sell the product by comparing it with another network. Say what yours does and let it be judged on that. 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. Costs money Make the recipient and the amount unmistakable on the review screen. Once accepted, a payment cannot be cancelled. 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. 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. Select within a basket, and treat an output reserved by an app or a token as unavailable rather than as a cheap input. 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. 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. Build a manual coin-choice screen into a consumer wallet. Choosing well automatically protects privacy better than asking the user to. Use the words "dust", "UTXO" or "coin selection" anywhere a normal user can see them. 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. 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. Say which kind of words these are on the screen that shows them, and again on the screen that asks for them. Offer one method at setup, and let the user change it later. Explain what the words are and where to keep them before showing them. Confirm a few words at a position the user must read, and follow it with a plain prompt about where the paper will live. 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. Offer a recovery check the user can run at any time, which confirms the words match without moving money. Suggest two locations in different buildings, in plain terms: "one at home, one somewhere else you can reach". 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. 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. Prompt the user to compare the signer's screen with the computer's before approving, and say which one to believe if they differ. 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. 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. 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. 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. 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. 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. Make the handle the thing a user shares. Put the address behind a "Show address" control for the cases that need one. Lead a receive screen with an address. It is the least usable identifier you have and it is almost never the one the payer needs. Show change as a transaction, a second recipient, or a separate line in a balance. It is the most common way to make a wallet look wrong when it is right. Use a monospace face whose characters are clearly distinguishable, such as Source Code Pro or Fira Mono. Base58 excludes 0, O, I and l for this reason, so do not fight it with an ambiguous font. Group it into chunks of four characters, and offer a large, expanded view. People compare in chunks and cannot compare a 34-character run. Costs money Shorten an address with an ellipsis where somebody is checking it. Middle elision is acceptable in a list row, never on a confirmation. Costs trust Validate as it is entered, and disable sending until it passes. Derive a fresh output for every payment. The peer-to-peer flow does this without the user knowing, which is the right amount of knowing. Where a user deliberately publishes a fixed address, such as a donation page, say what it costs them in a sentence rather than preventing it.
