How it works

You do not need to implement any of this. You do need to know which parts reach the interface, and how.

The four differences that matter

If you read nothing else here, read these four.

Apps never hold keys. An app asks the user's wallet to pay, sign or prove something. The wallet decides and returns a result. Your connect flow is a conversation about permission, not a key handover. → Connecting a wallet

The sender hands the payment to the recipient. It is delivered directly, with the proof needed to check it, so the recipient knows at once. → Payments

A backup 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. → Backups

Identity is proved, not registered. A user can show that they are over 18 without handing over a name or a date of birth. → Identity

What this removes

Half of designing for BSV is noticing which screens you do not need. These are screens a BSV product does not need, and why:

The pages

Wallets and keys

• Wallet setups: everyday, savings and agent wallets, and why they must stay apart.
• Backups: what a complete backup contains and how to say so honestly.
• Private key management: who can sign and how the secret is backed up, from one key on a phone to an offline signer.

Payments and transactions

• Transactions: the lifecycle, the first-seen rule, and when a payment can be relied on.
• Payments: the peer-to-peer flow, handles, and paying inside a web request.
• Coin selection: which outputs get spent, and what spending them together reveals.

Identity and privacy

• Identity: identity keys, Passes, and proving one thing without revealing the rest.
• Wallet privacy: what key derivation hides by default and the four leaks that remain.

Network and compatibility

• Nodes and verification: why users do not run nodes, and what a wallet checks instead.
• Legacy compatibility: plain addresses, seed-only wallets and the older protocols products still meet.

Patterns these lead to

• Connecting a wallet: the Wallet Application Interface, permission prompts, spending allowances, and what never to ask for.
• Paying by handle: Paymail and handles, and the risk a readable name introduces.
• Holding tokens: a token is an output, how one reaches a wallet, and the four things to show before somebody can trust what they hold.
• Storing data on chain: what the chain is good for holding, and why permanence makes it a consent problem.
• Charging per use: charging a few satoshis many times, without a prompt each time or a wall of receipts.
• Letting an agent spend: software spending on somebody's behalf, bounded rather than asked.
• Spending conditions: timelocks and multi-key rules, and why CHECKLOCKTIMEVERIFY is not one of them.
• Wrong-network payments: the one error correct software cannot catch, and the four defences in order.

Where to start

What is still thin

The concepts with the least shipped practice behind them are tokens, agents, and the review screens that charging per use needs, all covered in Patterns. If you have built any of them, a case study is worth more than another page of reasoning.

Related

• Getting started: if BSV itself is new
• Designing BSV products: the method, rather than the technology
• Glossary