# Write BSV amounts, units and interface copy: 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.
50 rules: 2 that can cost money, 9 that can cost trust, 39 standard.
## Start here
- **DON'T** _(Costs money)_ Show long decimal BSV amounts in a consumer interface. "0.00012500 BSV" asks the reader to count zeros, and they will get it wrong.
- **DON'T** _(Costs money)_ Shorten an address with an ellipsis where somebody is checking it. Middle elision is acceptable in a list row, never on a confirmation.
- **DO** _(Costs trust)_ Use Bitcoin SV or BSV on screen: "Send BSV", "Your BSV balance", "Bitcoin SV address". Use one of the two consistently within a screen.
- **DON'T** _(Costs trust)_ 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.
- **DO** _(Costs trust)_ 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.
- **DO** _(Costs trust)_ 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** _(Costs trust)_ Abbreviate amounts in a financial context. "12.5k sats" saves four characters and introduces a rounding question.
- **DON'T** _(Costs trust)_ Shorten a number with an ellipsis, ever. Reformat it or let it wrap.
- **DON'T** _(Costs trust)_ Keep a fee picker because the design system already has one. It asks the user a question with no wrong answer, which teaches them that your questions are decorative.
- **DO** _(Costs trust)_ Leave the fee off the review screen entirely for ordinary payments, and put it in the transaction details afterwards for anyone who looks.
- **DO** _(Costs trust)_ Validate as it is entered, and disable sending until it passes.
## Every rule, by page
### Amounts and units
https://www.bitcoinsv.design/guide/patterns/amounts-and-units/
- **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** _(Costs money)_ Show long decimal BSV amounts in a consumer interface. "0.00012500 BSV" asks the reader to count zeros, and they will get it wrong.
- **DON'T** Adopt a satoshi glyph. None renders reliably, none is in common fonts, and your users have not seen any of them.
- **DO** _(Costs trust)_ 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** _(Costs trust)_ 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.
- **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** _(Costs trust)_ 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.
- **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** _(Costs trust)_ 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** _(Costs trust)_ Abbreviate amounts in a financial context. "12.5k sats" saves four characters and introduces a rounding question.
- **DON'T** _(Costs trust)_ Shorten a number with an ellipsis, ever. Reformat it or let it wrap.
- **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".
- **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".
- **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.
### Send fees
https://www.bitcoinsv.design/guide/daily-spending-wallet/sending/send-fees/
- **DON'T** _(Costs trust)_ Keep a fee picker because the design system already has one. It asks the user a question with no wrong answer, which teaches them that your questions are decorative.
- **DO** _(Costs trust)_ Leave the fee off the review screen entirely for ordinary payments, and put it in the transaction details afterwards for anyone who looks.
- **DO** In the payment's details, show the fee in local currency as one small line: "Fee: less than 1p". A figure in satoshis invites arithmetic nobody wanted to do.
- **DON'T** Explain the fee model. A user who wanted to know about satoshis per byte will find it in the transaction details.
- **DO** Pay the fee on the user's behalf where the product can, and do not mention it. We suggest a shop absorb it as a cost of sale and an app fold it into its price. It is a real option because the fee is smaller than any price the user will see.
### Visual language
https://www.bitcoinsv.design/guide/getting-started/visual-language/
- **DO** Use the BSV mark, the upright B on gold, wherever a BSV product needs the symbol as a mark.
- **DON'T** Use the orange disc or a tilted B to stand for BSV. Both say a different network to anyone who knows the difference.
- **DO** Use the Unicode character ₿, not the logo, when you need the bitcoin symbol in text. It scales, reflows and can be read by a screen reader. For amounts and labels, use sats and BSV; see Amounts and units.
- **DON'T** Use the golden disc logo inside a sentence. It is a mark, not a letterform, and at text size it is a smudge.
- **DON'T** Put memes in a product. They read as a private joke to people inside and as unseriousness to people outside, and the second group is who you are trying to reach.
- **DO** Draw the thing that is happening. A payment is a person handing something to a person.
- **DO** Pick a point on the scale deliberately and hold it across the product. Drifting between the two is what produces an app that is baffling to newcomers and patronising to everyone else.
- **DON'T** Use a lightning bolt to mean speed in a BSV product. Show the thing itself: a payment confirmed while the customer is still at the till.
- **DON'T** Put advocacy in a product. Say what yours does and let it be judged on that.
- **DO** Reach for the gold metaphor on a savings surface and leave it off an everyday one. A payment app that looks like a vault tells people their coffee money is an investment.
### Address
https://www.bitcoinsv.design/guide/glossary/address/
- **DO** Make the handle the thing a user shares. Put the address behind a "Show address" control for the cases that need one.
- **DON'T** Lead a receive screen with an address. It is the least usable identifier you have and it is almost never the one the payer needs.
- **DON'T** Show change as a transaction, a second recipient, or a separate line in a balance. It is the most common way to make a wallet look wrong when it is right.
- **DO** Use a monospace face whose characters are clearly distinguishable, such as Source Code Pro or Fira Mono. Base58 excludes 0, O, I and l for this reason, so do not fight it with an ambiguous font.
- **DO** Group it into chunks of four characters, and offer a large, expanded view. People compare in chunks and cannot compare a 34-character run.
- **DON'T** _(Costs money)_ Shorten an address with an ellipsis where somebody is checking it. Middle elision is acceptable in a list row, never on a confirmation.
- **DO** _(Costs trust)_ Validate as it is entered, and disable sending until it passes.
- **DO** Derive a fresh output for every payment. The peer-to-peer flow does this without the user knowing, which is the right amount of knowing.
- **DO** Where a user deliberately publishes a fixed address, such as a donation page, say what it costs them in a sentence rather than preventing it.
### Wallet
https://www.bitcoinsv.design/guide/glossary/wallet/
- **DO** Decide which sense you mean before writing the screen. "Create a wallet" and "Connect your wallet" are different enough that a user who confuses them will do the wrong thing.
- **DO** Leave key derivation out of the interface. A user never needs the word "derivation"; they need to know that one backup covers everything.
- **DON'T** Call this "a BRC-100 wallet". The number names a document, not a product. In an interface the string is Connect wallet.
- **DO** Say which one you are, in plain words, before the user has anything to lose. "We cannot reset this for you" is the sentence that matters, not the word "non-custodial".
- **DON'T** Use "account" for the thing a user signs into. If your product has both, one of them needs a different word.