
Amounts and units
How to show BSV amounts: satoshis as the unit, which figure leads, what to do about the missing symbol, and the rules that stop a number being misread.
Every screen with money on it has to show an amount nobody can misread. We recommend satoshis as the unit, local currency first for what a person chooses to buy, satoshis first for limits software enforces, and never long decimal BSV.
Getting an amount wrong by a factor of a hundred million is easy here, and it is a design bug more often than a code one. On BSV the amounts people deal in are small. A payment of 500 satoshis is ordinary, and "0.00000500 BSV" is not a number anybody can read.
Use satoshis
A bitcoin divides into 100,000,000 satoshis. On BSV, satoshis are the unit people meet.
Satoshis are the unit for the bitcoin figure. Which figure leads, local currency or satoshis, is covered in Lead with local currency.
Do
Default to satoshis, not BSV, for the bitcoin figure. Everyday amounts are hundreds or thousands of satoshis, and the decimal form is unreadable at that scale.
Do
Write "sats" or "satoshis" in words, and group digits in threes: 12,500 sats.
Don't
Show long decimal BSV amounts in a consumer interface. "0.00012500 BSV" asks the reader to count zeros, and they will get it wrong.
The symbol problem
Several satoshi symbols have been proposed and none is standardised, so there is no character to rely on. The bitcoin symbol ₿ (U+20BF) exists and is fine for the coin, but it is the wrong unit for an amount on screen.
Don't
Adopt a satoshi glyph. None renders reliably, none is in common fonts, and your users have not seen any of them.
Naming the network
The unit is satoshis. The network needs a name too, and the word to avoid is the unqualified one.
Do
Use Bitcoin SV or BSV on screen: "Send BSV", "Your BSV balance", "Bitcoin SV address". Use one of the two consistently within a screen.
Do
Prefer "Bitcoin SV" where there is room and the reader may be new to it, "BSV" where space is tight or the term repeats in a list.
Don't
Write "bitcoin" alone on a screen where somebody is about to move money. Used precisely it is an umbrella covering several chains, so it is the one word that cannot tell a user which network they are on. See Bitcoin.
Lead with local currency
People think in their own currency, and that is not a failure of education to design around. Which figure leads depends on who decided the amount.
Do
Lead with local currency for anything a person chooses to buy, with the satoshi amount beside it: "£12.00 (24,000 sats)".
Do
Lead with satoshis for figures software decides or enforces, such as allowance limits, what is left of an allowance and agent budgets, with local currency beside them.
Do
Let the two be swapped in one tap, and remember the choice.
Do
Say when a converted figure is an estimate, and roughly how fresh the rate is. A price that silently drifts is worse than one labelled approximate.
Rules that prevent misreading
Do
Use tabular figures (tabular-nums in CSS) everywhere a figure appears, so digits line up in a column and a changing balance does not shift the layout.
Do
Format for the reader's locale. 1,200 and 1.200 and 1 200 are the same number to three different people and three different numbers to one of them.
Do
Keep one bitcoin unit per screen. Mixing "0.0001 BSV" and "10,000 sats" in one view asks the user to do arithmetic to compare two things you wrote.
Don't
Abbreviate amounts in a financial context. "12.5k sats" saves four characters and introduces a rounding question.
Don't
Shorten a number with an ellipsis, ever. Reformat it or let it wrap.
Showing fees
Almost never. The review screen shows the total the person pays. A BSV network fee is less than 1p, and a line of noise on a review screen takes attention that belongs on the recipient.
Do
Leave the fee off the review screen and put it in the transaction details. If it is shown, show it in local currency: "Fee: less than 1p".
Showing the fee
- OK: in the transaction details, in local currency.
- Grey area: on the review screen, as one quiet line such as "Fee: less than 1p".
- Not OK: a fee figure the user is invited to adjust, or one shown in long decimal BSV.
See Send fees.
Very small amounts
Apps charging per request produce amounts of a few satoshis, hundreds of times a day.
Do
Show the individual amount where it happens and the aggregate where the user is deciding something. "About 1p (20 sats)" on the article, "940 sats (about 47p) today" in the allowance summary.
Do
Round aggregates to a sensible precision in local currency. "About 24p today" is more useful than "£0.2384".
See Activity.
Accessibility
Do
Make sure an amount reads correctly aloud. A screen reader should say "twelve thousand five hundred satoshis", which means the unit needs to be text rather than an image or an unlabelled glyph.
Do
Never rely on colour alone to show direction. Pair the colour with a sign or a word.
See Accessibility.
Open questions
- Does leading with local currency leave people unsure what they actually sent, when the rate moves between choosing an amount and paying it?
- Do newcomers read "sats" as a unit of money, or as jargon they have to look up?
- How fresh does a converted rate have to be before "about" stops being an honest word?
- What should the local figure say when a per-use amount is smaller than the smallest coin, a fraction of a penny?
- Is "Bitcoin SV" really clearer than "BSV" to somebody new, or only longer?
Related
- Pay-per-use reader: these rules on a real article page
- Charging per use: pricing amounts of a few satoshis
- Send fees: where the network fee goes in a send flow
- Activity: many small amounts in one list
- Visual language: type and figures across the guide's designs
- Glossary: satoshi, BSV and the other terms on this page
Written from: Unicode 10.0, BSV wiki, ts-stack docs.
Checklist
The rules on this page, in a form you can work through.
21 rules
