# Create, sign and report BSV actions: every rule
Every do and don't the guide states on the pages behind this skill. The costly ones come first; the full list follows, grouped by page. Quote them; do not paraphrase them.
24 rules: 2 that can cost money, 3 that can cost trust, 19 standard.
## Start here
- **DO** _(Costs money)_ Make the recipient and the amount unmistakable on the review screen. Once accepted, a payment cannot be cancelled.
- **DO** _(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.
- **DO** _(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.
- **DON'T** _(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.
- **DON'T** _(Costs trust)_ Trust a single service's word that a payment is confirmed. The merkle proof is the evidence; verify it against headers rather than displaying whatever the API returned.
## Every rule, by page
### Transactions
https://www.bitcoinsv.design/guide/how-it-works/transactions/
- **DO** 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.
- **DO** _(Costs money)_ Make the recipient and the amount unmistakable on the review screen. Once accepted, a payment cannot be cancelled.
- **DO** _(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.
- **DO** _(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.
### Activity
https://www.bitcoinsv.design/guide/daily-spending-wallet/activity/
- **DO** 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.
- **DON'T** 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.
- **DON'T** Show change returned to the wallet as a separate entry. One payment is one row.
- **DO** Group by source and period: "The Satoshi Vision, 47 articles, 940 sats today" as one row that expands.
- **DO** Make the expanded view genuinely useful: what each payment bought, not just a list of identical amounts.
- **DON'T** 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.
- **DON'T** Group payments from different apps together. The grouping is per relationship; merging them loses the only thing that made it readable.
- **DO** Show them, visibly distinct from payments: an app connected, a permission granted or revoked, a Pass presented, an allowance exhausted.
- **DO** 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.
- **DO** Search across names, handles, notes and amounts. People remember the café or the word "lunch", never a date range.
- **DO** Offer filters for direction, source and period, and show which are active. A filtered list that looks like an empty wallet is alarming.
- **DO** When a search finds nothing, name the term and offer to clear the filters.
- **DO** 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.
- **DO** 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.
- **DON'T** _(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.
### Nodes and verification
https://www.bitcoinsv.design/guide/how-it-works/nodes/
- **DO** Let a wallet point at a different service provider, and ideally more than one at a time. A wallet welded to one company's endpoint has that company's lifespan.
- **DON'T** _(Costs trust)_ Trust a single service's word that a payment is confirmed. The merkle proof is the evidence; verify it against headers rather than displaying whatever the API returned.
- **DO** Put the services a wallet uses in an advanced settings screen, with what each one is for in one line. Users who care should be able to see and change them.
- **DON'T** Put verification in front of ordinary users. Nobody should have to understand merkle proofs to be paid.
- **DO** Keep headers synced quietly in the background and never make it a user-facing task. If headers are stale, say what that means for the user ("can't confirm payments from the last 3 days") rather than showing a sync percentage they can do nothing about.