Why design for BSV
What the work is actually like, which problems are genuinely open, and who it suits.
The problems here are unsolved and the conventions are thin, so what you decide may well still be there in five years, because few others are deciding it.
That suits some designers and not others.
The problems are open
Most product design is refinement: a known pattern, applied better. Here, several questions do not have agreed answers yet: how a spending permission should read, what hundreds of tiny payments should feel like, how to explain a backup with two halves, and what an agent's spending should look like to its owner. The hard parts sets each one out, with what people ask and what you have to decide.
Recommendation
Pick one problem from The hard parts and attempt its exercise in Design challenges. A good attempt is a contribution to this guide.
The constraints are unusual
Three of them shape everything:
Irreversible. A payment cannot be recalled, so a confirmation screen is doing real work rather than ceremony. The review screen is the last chance to catch a mistake.
Unforgiving. Lose the key and the money is gone. Recovery design is not an edge case to handle after launch; it is a primary flow.
Public and permanent. Anything on chain can be read forever. Privacy is decided before a transaction exists, which makes it a design question rather than a settings page.
What you do not have to design
Several things you might expect to design are absent here:
- No fee pickers, fee estimates or stuck payments to explain.
- No "wait for confirmations" on everyday amounts.
- Payments small enough that charging per use is a real option, not a demo.
That is a lot of interface you do not have to design, and a lot of user confusion you do not have to apologise for.
Working in public
Most of this ecosystem's design work happens in the open: in repositories, in public discussions, in standards anyone can read. That is uncomfortable at first and useful quickly, because the people who will implement your work can argue with it before it ships. See Open design.
It also means your work is reusable. A pattern published here can end up in products you have never heard of, which is a kind of reach normal product design does not offer.
Who it suits
It suits you if you like problems without established answers, you are comfortable writing as much as drawing, and you would rather argue about a backup flow than a brand refresh.
It suits you less if you need a research budget and a user panel, want to work from an established design system, or need the reassurance that somebody has solved this before. The ecosystem is small, the budgets are smaller, and much of the research does not exist yet; Research has methods for running your own.
What to be honest with yourself about
- The ecosystem is small. Fewer products, fewer users and fewer colleagues to compare notes with than in mainstream product design.
- Debates between chains are loud. This guide stays out of them, and you can too, but you will meet them.
- Nobody is coming to validate your work. With few conventions and few peers, you are often the most informed person in the room about a decision, which is less flattering than it sounds.
Start here
- The hard parts
- Connecting a wallet
- The Daily spending wallet reference design
- Contribute, when you find something here that is wrong
Related
Written from: BRC-100, BRC-121, BRC-151.
Checklist
The rules on this page, in a form you can work through.
1 rules