Common questions

BSV, short for Bitcoin SV, is a digital currency and a network for making payments and recording data. People use a wallet app to send and receive it. This guide explains how to design those wallets and the apps that connect to them.

Getting started has the whole answer.

You can pay another person or pay for something inside an app, such as an article or a download. Payments can be small enough to charge for each use. What you can do in practice depends on the wallet, app and recipient supporting that payment.

Payments has the whole answer.

A blockchain is a shared record of payments and other transactions. These records are collected into groups called blocks, with each block linked to the one before it. On BSV, this record is public and permanent, so personal information should never be written there unprotected.

Technology primer has the whole answer.

A wallet is an app that lets you receive, keep track of and send BSV. It manages private keys: the information used to approve payments. A connected app asks the wallet to do something, while the wallet keeps control of those keys.

Glossary has the whole answer.

No. One BSV divides into 100,000,000 smaller units called satoshis, often shortened to sats. You can send or receive these smaller amounts. An amount such as 500 sats is part of a coin, not 500 whole coins.

Amounts and units has the whole answer.

In a compatible wallet, choose a contact or enter their payment handle, enter an amount and confirm. A handle looks like an email address and helps the wallet find the recipient. To receive money, share the handle your wallet provides. The wallets exchange the payment and check it; the app should tell you whether it was accepted.

Payments has the whole answer.

A connection lets an app ask your wallet to do things. The wallet decides what to allow. A spending allowance can let an app make payments within limits you approve, without asking each time. Read those limits before agreeing, and use the wallet to review or revoke access.

Connecting a wallet has the whole answer.

It depends on the backup your wallet supports and what you have saved. Recovery words alone may not be enough: a complete backup for a modern BSV wallet has a way to recover your keys and the wallet records that identify your money. Follow the wallet’s backup instructions and test recovery before you need it.

Backups has the whole answer.

It asks the wallet to act on the user's behalf rather than holding keys itself. The app calls a method, such as creating a transaction or getting a public key. The wallet decides whether to allow it, does the work and returns the result. The standard interface is the Wallet Application Interface, specified as BRC-100, so an app built once works with any wallet that implements it. Every request carries the asking app's domain, which is how the wallet knows which permissions apply and who to name on the prompt. In an interface, the words to put on the button are Connect wallet.

Connecting a wallet has the whole answer.

Use Bitcoin SV or BSV, not bitcoin on its own. The unqualified word is an umbrella covering several chains, so on a screen where somebody is about to move money it is the one word that cannot tell them which network they are on. Pick one of the two and keep it: Send BSV, Your BSV balance, Bitcoin SV address. Say Bitcoin SV where there is room and the reader may be new, and BSV where space is tight or the term repeats.

Glossary has the whole answer.

Satoshis. One BSV divides into 100,000,000 satoshis, and because fees are less than a penny, everyday BSV amounts are hundreds or thousands of satoshis rather than fractions of a coin. Writing those as decimals produces numbers like 0.00012500 BSV, which asks the reader to count zeros and they will get it wrong. Write sats or satoshis in words and group the digits in threes: 12,500 sats.

Amounts and units has the whole answer.

Yes, and it is the one flow in the guide where the person is not present when money moves. So the design shifts from asking to setting limits and reporting: what the agent may do, and what it did. The first decision is architectural, not visual. Give the agent its own wallet, funded deliberately, so that its budget is a balance rather than a policy somebody has to enforce.

Letting an agent spend has the whole answer.

The app can ask your wallet to do things for it, like make a payment or show who you are. Your wallet asks you before it agrees, unless you gave the app an allowance. The app never gets your keys, and your wallet shows what each app is allowed to do so you can take it back.

Connecting a wallet has the whole answer.

An amount you let an app spend without asking you each time, up to a limit you choose. When it runs out, the app has to ask again. You can change or remove it in your wallet whenever you like.

Permissions and allowances has the whole answer.

No. Once the other person's wallet has accepted a payment, it is final. If you paid the wrong person, you have to ask them to send it back. That is why your wallet shows who you are paying before you confirm.

Transactions has the whole answer.

Sending BSV costs less than a penny, and the fee does not rise when the network is busy. There is nothing to choose and nothing to wait for, so your wallet may show the fee only in the payment's details.

Send fees has the whole answer.

A short name, like anna@example.com, that you can pay instead of a long address. Your wallet looks it up and shows you whose it is before you pay, so you can check you have the right person.

Paying by handle has the whole answer.

A list of words that can restore your wallet's keys if you lose your phone. Anyone who has them can take your money, so write them down, keep them somewhere safe, and never type them into anything except a wallet you are restoring.

Manual backup has the whole answer.

Your recovery words restore your keys. Your wallet backup restores your records: which money is yours and how to spend it. Keep both. Losing either one can mean losing money, so keep the backup up to date as well.

Backups has the whole answer.

A digital document that somebody vouches for, such as proof that you are over 18, kept in your wallet. An app can ask to see one thing from it, and you decide whether to share it. The app sees only what you agree to show.

Identity has the whole answer.

Usually not. A failed payment normally never leaves your wallet, and your wallet should say whether anything was sent. If you cancelled in your wallet, or there was not enough money, nothing was sent.

Sending has the whole answer.

No. BSV 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 small and roughly fixed, less than 1p for an ordinary payment. That makes the fee not a decision, which in turn removes the fee picker, the fee estimate, the high-fees warning, fee bumping and the stuck-transaction flow. For an ordinary payment, leave the fee off the review screen entirely and put it in the transaction details afterwards for anyone who looks.

Send fees has the whole answer.

For everyday amounts, yes, and that is a risk decision rather than a guarantee. BSV has no replace-by-fee: miners follow a first-seen rule, so the first valid version of a transaction is the one they keep and a later conflicting spend is rejected rather than swapped in. Waiting for confirmations therefore buys far less than it does on a chain where unconfirmed transactions can be replaced. Treat confirmation as a risk setting: complete on acceptance for coffee, articles, tips and most in-person sales, and show larger amounts as settling until mined.

Transactions has the whole answer.

Nothing in the address format, which is the uncomfortable part. A BSV address and a BTC legacy address are both base58, both start with a 1, and each passes the other's validation, because the format carries no network field at all. A checksum proves an address is well formed, not which chain it belongs to. The defence is design, in this order: use handles rather than addresses, because a handle resolves through its own infrastructure and cannot belong to another chain; name the network prominently at the point of paste; and after a first payment succeeds, save the recipient as a contact so later payments go through the contact.

Wrong-network payments has the whole answer.

Usually not. A complete backup has two parts: key recovery material, such as recovery words or key shares, and the wallet's own records of which outputs belong to the user and what is needed to spend them. A modern BSV wallet derives a fresh key for each payment from both parties' keys plus payment-specific details, and those details live in the records rather than on the chain. Words alone can restore signing authority to a wallet that cannot find the money. Never tell users that the words are their wallet unless that is true of yours.

Backups has the whole answer.

A token on BSV is an output the holder's wallet keeps, owned and moved the way a payment is. Its history runs back to its issue, and no contract can change who holds it. The practical effect on design is that if you have drawn a wallet, you already have most of the parts. The two widely used families are 1Sat Ordinals, with BSV-21 as its fungible side, and STAS, which puts more of the rules in the script itself.

Holding tokens has the whole answer.

No. Nodes are mining infrastructure on BSV, and users neither run them nor need to. A wallet checks that a payment is real using simplified payment verification: it keeps block headers, which are tens of megabytes for the whole chain, and verifies a merkle proof of a few hundred bytes against them. On BSV the proof usually arrives with the payment rather than being fetched, packaged as BEEF alongside the transaction and its ancestors.

Nodes and verification has the whole answer.