An everyday street scene in soft pastel light: a person at a coffee cart taps their phone to pay, a bus passing, a bakery window, ordinary life

Daily spending wallet

A reference design for a BSV wallet people use every day: what it is for, what it is deliberately not for, and the nine flows it is made of.

A worked example of a phone wallet for everyday money: paying people and shops, paying apps per use, being paid, and keeping it all recoverable. It is built for somebody paying for coffee, splitting bills and reading by the article, on their phone.

It is a reference design, not a product. Take the parts that fit, argue with the parts that do not, and read the reasoning rather than copying the screens.

About these screens

Every screen in this section is a proposed design. The screenshots and wireframes show one way to build it, and none describes a shipped product. Names are fictional, amounts are worked examples, and they convert at an illustrative 2,000 sats to £1.

What it is for, and what it is not

This wallet holds what a person can afford to lose. That is the design constraint, not a disclaimer, and it makes everything else coherent: the wallet connects to apps all day, approves payments quickly, and trades some protection for speed.

Savings belong in a different wallet, one that accepts no requests from apps. A product that tries to be both is too slow for coffee and too exposed for savings.

Recommendation

After the first money arrives, suggest a maximum balance by asking the question that answers it: "How much would you be comfortable losing if this phone were stolen?" See Wallet setups.

What shapes this design

Six facts about how BSV works shape every screen in this wallet:

A bitcoin coin A private key A mobile phone

Payments complete in the conversation, not on the chain. The sender hands the transaction to the recipient with its proofs, and the recipient's wallet verifies it and replies. You can show "Paid" then. See Payments.
There are no fee decisions. No picker, no estimate, no bumping, no stuck payment. A fee is a fraction of a penny and can be absorbed entirely.
There are no addresses to manage. A fresh key is derived for each payment. Show people and handles, never addresses.
Apps connect to the wallet through one standard interface, so any compatible app works without the wallet doing anything for it. See Connecting a wallet.
Paying a fraction of a penny is normal, so the activity list fills with small entries and has to keep them readable.
A backup has two parts. The recovery words restore the keys. The wallet backup restores the records: which money is the user's and how to spend it. Losing either can lose money. See Backups.

The flows

Nine, in the order a person meets them. The prompts this wallet shows when an app connects or asks for an allowance are drawn in the Pay-per-use reader and Connected web app designs, and specified in Permissions and allowances.

First use

Finding the app, creating a wallet, and getting the first money in without a wall of warnings.

Backup and recovery

Both parts of a backup, and restoring from them. The flow that is easiest to get wrong, and the one a user needs once, urgently.

Requesting

Asking to be paid, and being paid.

Sending

Paying a person, a shop or an app, and the review screen that is the last chance to catch a mistake.

Activity

What happened, including the many tiny app payments this wallet has to show.

Contacts

People and apps the user pays more than once, which is what stops them typing handles.

Security

Locking the app, approving payments, and managing what apps are allowed to do.

Privacy

What is public, what the wallet's own services learn, and what the user controls.

Settings

Units, appearance, services, and the things that belong here rather than in the main interface.

How to use this

Read the reasoning and adapt. A reference design that is copied screen for screen produces a product that is identical to everyone else's and fits nobody's users in particular.

Start from Connecting a wallet and Payments if you are building the real thing. Nearly every surprise traces back to one of those two.

Don't

Treat this as a specification. It is one defensible set of answers, and several of the questions are genuinely open. Most flow pages list their open questions.

Savings wallet: where the rest of the money goes
Multiple wallets: running both side by side
Pay-per-use reader and Connected web app: the app side of this wallet
Errors and failed payments
How it works

Written from: BRC-29, BRC-42, BRC-100, BRC-121, BRC-169.

Checklist

The rules on this page, in a form you can work through.

4 rules

DoRead the reasoning and adapt. A reference design that is copied screen for screen produces a product that is identical to everyone else's and fits nobody's users in particular.
DoStart from Connecting a wallet and Payments if you are building the real thing. Nearly every surprise traces back to one of those two.
Don'tTreat this as a specification. It is one defensible set of answers, and several of the questions are genuinely open. Most flow pages list their open questions.
DoAfter the first money arrives, suggest a maximum balance by asking the question that answers it: "How much would you be comfortable losing if this phone were stolen?" See Wallet setups.

Every rule for what you are building