Activity
What happened, including the hundreds of tiny app payments a BSV wallet has to show, grouped so the list stays readable.
Most of this is an ordinary transaction list. The design problem is that this wallet generates a lot of entries.
When paying per article, per request or per second is practical, a user can build up four hundred payments in an afternoon. A list that gives each its own row is unreadable by Tuesday.
What an entry should say
Four things, in this order of importance:
- Who, as a name and avatar where the other party shared a profile, and their handle where they did not.
- How much, in local currency with sats beside it. Payments an app made within an allowance lead with sats, because software decided them. See Amounts and units.
- Why, from the note either party attached.
- When.
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.
Never show change as a payment
A payment of 500 sats from a 2,000-sat output produces an output of change back to the user. That is one payment, not a payment and a receipt. Block explorers show both; an activity list that copies them is showing its plumbing. See Coin selection.
Don't
Show change returned to the wallet as a separate entry. One payment is one row.
Grouping the small ones
This is the problem specific to this wallet. An app charging 20 satoshis per request, a reader paying per article, an agent buying data: each produces many small entries from one source.
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.
States
Short, because acceptance is the main event:
| State | Means | Label |
|---|---|---|
| Accepted by the recipient | Their wallet verified and accepted it | Paid or Received |
| Broadcast, not yet mined | Miners have it, first-seen applies | Settling, only for large amounts |
| Mined | In a block with a merkle proof | Complete, quietly |
| Incoming, plain address | Watching the chain, no handover | Incoming until mined |
| Failed | Rejected, or a conflicting spend seen first | Failed, with a plain reason |
Do not show a confirmation counter in the list: for everyday amounts the payment is done when it is accepted. See Receiving.
Things that are not payments
A connected wallet does more than pay. It connects to apps, grants permissions, presents Passes and signs messages. Those are events in the user's financial life, and some matter more than a small payment does.
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.
Search and filter
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.
Export
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.
Details
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
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.
Open questions
- What amount should show Settling, and who sets it?
- Do people want grouping by day, or by session with an app?
- Does a grouped row hide a payment the user would have disputed?
Related
Written from: BRC-29, BRC-100, BRC-121, ts-stack docs.
Checklist
The rules on this page, in a form you can work through.
15 rules