Transactions
What happens to a BSV transaction from signing to settlement, and what that means for status, fees and confirmation design.
A transaction moves value by spending earlier outputs and creating new ones. BSV uses the unspent-output model (UTXO): each payment spends earlier outputs whole and creates new ones. What matters for your screens is how transactions travel, how fast they can be relied on, and what they cost.
The lifecycle
- Created and signed. The user's wallet picks which outputs to spend and signs the transaction. The app never handles keys. See Connecting a wallet.
- Handed to the recipient. In the recommended payment flow, the sender passes the transaction directly to the recipient with its proofs. See Payments.
- Broadcast. The transaction is submitted to miners, usually through a miner-facing broadcast service called ARC rather than through a node the user runs.
- Accepted by miners. Miners follow a first-seen rule: the first valid version of a transaction they see is the one they keep. A later conflicting transaction that tries to spend the same coins is rejected, not swapped in.
- Mined. The transaction is included in a block, typically within about ten minutes, and its merkle proof becomes available.
First-seen and zero-confirmation payments
Commonly misunderstood: waiting for confirmations
On BTC, replace-by-fee means a transaction you have seen can still be swapped for a conflicting one, so a merchant waits for a block. Designers carry that habit across without checking it, and it makes a BSV product feel slower than it is.
BSV has no replace-by-fee. The first-seen rule means the first valid version is the one miners keep, so the wait buys far less than it does there.
BSV miners do not replace transactions. With the first-seen rule, plus double-spend notifications from broadcast services, accepting a payment before it is mined is a reasonable choice for everyday amounts. It is still a risk decision, not a guarantee.
Recommendation
Treat confirmation as a risk setting, not a blanket rule. For coffee, articles, tips and most in-person sales, treat a payment as complete once the recipient's wallet has accepted it. For large amounts, show the payment as Settling until it is mined, and let businesses set their own threshold.
Suggested status language:
| State | What it means | Label |
|---|---|---|
| Accepted by recipient | The recipient's wallet verified and accepted it | Paid / Received |
| Broadcast, not yet mined | Miners have it and will keep the first-seen version | Settling (only show for large amounts) |
| Mined | In a block, with a merkle proof | Complete |
| Rejected | Invalid, or a conflicting spend was seen first | Failed, with a plain reason |
Fees
BSV blocks have no fixed size cap, and fees have stayed below 1p. Users do not compete for space in a block.
So there is no fee picker, no fee estimate and nothing to bump. See Send fees.
Because fees are so small, a product can pay them on the user's behalf: a shop can absorb the fee, or an app can build it into its price.
Do
Absorb the fee into your price where you can. If you show the network fee, put it in the payment's details as "less than 1p", not on the review screen.
Small amounts are normal
BSV allows outputs as small as one satoshi. Payments of a few sats are practical, so pay-per-article, pay-per-request and in-game payments work without batching or credit systems. Design amounts and activity lists to handle many small entries. See Amounts and units.
Chains of unconfirmed transactions
An app can spend the output of a transaction that has not been mined yet, and keep doing so many times in a row. Long chains of unconfirmed transactions are allowed, so users do not need to "wait for funds to confirm" before spending money they just received.
Irreversibility
Once accepted, a BSV payment is final. The sender cannot cancel it, so the review screen is the last chance to catch a mistake.
Do
Make the recipient and the amount unmistakable on the review screen. Once accepted, a payment cannot be cancelled.
Commonly misunderstood: an address that starts with 1
A BSV address and a BTC legacy address share a format and both start with "1", so neither a person nor your validation can tell them apart. Money sent to the wrong network is very hard to recover.
Do
Warn when a user pastes an address rather than choosing a handle or contact, and offer handles and contacts first everywhere you can. See Wrong-network payments.
If you document scripts
- Transactions use ECDSA signatures with the SIGHASH_FORKID flag.
- The Chronicle upgrade (block 943,816, 7 April 2026) restored the remaining original opcodes, but only for transactions marked with the Chronicle version. When you document a script, state the minimum transaction version it needs.
- New pay-to-script-hash (P2SH) outputs are not allowed, and CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY no longer act as checks. Use nLockTime/nSequence or custom scripts instead. See Spending conditions.
Open questions
- Above what amount should a recipient wait for a block, and should a wallet suggest a default?
- Do users read "Settling" as safe or as pending?
Related
Written from: BSV protocol, BSV Academy (Infrastructure), ts-stack ARC broadcast spec.
Checklist
The rules on this page, in a form you can work through.
4 rules