Patterns
What to design, by task: connecting and signing in, amounts and payments, errors, agents, tokens, stored data and spending conditions.
A pattern page answers one question: you are about to design this, so what should it do? Each one names a task a BSV product meets, recommends how to handle it, gives the rules you can check a design against, grades the choices that are contested, and says what nobody knows yet.
The reference designs put patterns together into whole products. How it works explains the technology underneath them. If you are drawing a screen this week, start here.
Connecting and finding people
Connecting a wallet: an app asks the user's wallet to act for it, and the permission prompt is the whole conversation. Ask for the minimum, say what it is for, and make it easy to take back.
Permissions and allowances: what an app holds after it connects. The prompt, the allowance, the dashboard where it is all undone, and what stays off by default.
Signing in: no accounts and no passwords. A key derived for your app, returning visits, signing out, and asking for one fact from a Pass.
Paying by handle: a readable name becomes a payment. What to resolve and show before the confirm button, and the risk a readable name brings with it.
Paying and charging
Amounts and units: satoshis as the unit, local currency beside them, and the rules that stop a number being misread by a factor of a hundred million.
Charging per use: payments of a few satoshis, many times a day. Allowances instead of prompts, and an activity list that does not make somebody anxious.
Wrong-network payments: an address that looks valid can belong to another network. The defences, in the order they are worth building.
Errors and failed payments: every failure in four parts: what happened, whether money moved, what to do next, and the code for support.
Delegating and holding
Letting an agent spend: software spending on somebody's behalf. What to grant, how to bound it, and the review screen for a decision the person did not make.
Holding tokens: a token is an output the user holds. The four things to show before somebody can trust what they have.
Spending conditions: rules written into money, such as two of three keys or not before a date, and how to explain a lock nobody can undo.
Storing data on chain: data that lives beside a payment, and what permanence means for the consent screen.
Which to read
| If you are designing | Read |
|---|---|
| A web app that needs a wallet | Connecting a wallet, Permissions and allowances, Signing in, then Charging per use |
| Sign-in, or proof of age or membership | Signing in |
| A wallet's permission prompts or permissions screen | Permissions and allowances |
| An app that charges small amounts often | Charging per use, then Amounts and units |
| Any screen with a number of satoshis on it | Amounts and units |
| A send flow | Sending in the daily spending wallet, plus Paying by handle and Wrong-network payments |
| Error messages, or anything that can fail | Errors and failed payments |
| Automation, assistants or AI agents | Letting an agent spend |
| Tickets, collectibles, credits or certificates | Holding tokens |
| Savings, inheritance or escrow | Spending conditions |
| Anything that writes data to the chain | Storing data on chain |
Related
- Daily spending wallet: the patterns assembled into a wallet
- Pay-per-use reader, Connected web app and Agent with a budget: the patterns assembled into apps
- How it works: the concepts underneath
- Checklists: the rules from these pages, to tick off
Written from: the pages listed here.