Send fees
Why a BSV wallet has no fee picker, what to show instead, and the one place a fee still deserves a line.
A BSV wallet has almost no fee interface. The useful content here is what to leave out, and the few places a fee still deserves a line.
Why
Blocks have no fixed protocol size limit and miners raise capacity as demand grows, so users are not bidding against each other for space. A fee is a fraction of a penny, set by a rate per byte rather than by an auction, so it depends on the size of the transaction, not on the amount sent.
The practical consequence: the fee is not a decision. Nobody needs to trade speed against cost, because there is no queue to jump.
What to remove
| Common wallet component | In this wallet |
|---|---|
| A fee picker: slow, medium, fast | None |
| A fee estimate, with a confidence range | None |
| A "fees are high right now" warning | None |
| Fee bumping, replace-by-fee, child-pays-for-parent | None. There is no replace-by-fee to bump with |
| A stuck-transaction state and its recovery flow | None |
| A dust threshold, and hiding outputs below it | None. A one-satoshi output is spendable |
Don't
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.
What to show instead
Usually nothing. A fee of a fraction of a penny on a payment of a few pounds is noise, and a line of noise on a review screen takes attention that belongs on the recipient. The review screen shows the total the user pays; the fee belongs in the payment's details.
Do
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.
Absorbing it
Because the amount is so small, a product can pay it.
Recommendation
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.
Where a fee still deserves a line
Three cases, all of them about scale rather than size:
Many small payments. An app paying per request makes hundreds of payments, and the fees add up into something a user should be able to see. Show the total in the allowance summary, not per payment. See Permissions and allowances.
Business accounting. A merchant needs the figure for their books, even though it is tiny. It belongs in an export, not in the till interface.
Sending to an exchange. The exchange's own deposit or withdrawal fees are usually far larger than the network fee, and the user will blame whichever one your screen showed them. Name whose fee it is.
What users should understand
One sentence, if anything:
Sending costs a fraction of a penny, however much you send.
That is the whole of it, and the easiest thing to say in this product.
Don't
Explain the fee model. A user who wanted to know about satoshis per byte will find it in the transaction details.
Related
- Sending
- Amounts and units: the local-currency fee line
- Transactions: why fees stay negligible
- Coin selection: why dust is not a category
Written from: ts-stack fee model docs, ARC documentation.
Checklist
The rules on this page, in a form you can work through.
5 rules