
Why BSV is different
The properties BSV shares with all bitcoin, the ones that come from its own choices, and the honest limits of both.
Read this if somebody asks why your product looks different from other wallets, or before you copy a pattern from one.
Two sets of properties matter here, and conflating them is how products end up promising things they cannot deliver. Some come from bitcoin itself and are true of every chain descended from it. Some come from BSV's particular choices, and those are the ones that change what you can build.
What all bitcoin gives you
Money that is digital without being someone's record of money
A bank balance is an entry in a company's database. Bitcoin is not: the coins are the record, and holding the key is holding the money. No company's permission, no account to be closed.
The cost of that is real and should never be hidden: there is nobody to call. See Design principles.
A supply nobody can add to
21 million coins, on a schedule set in 2009. New coins are paid out with each block and the payout halves roughly every four years, so the total converges just under 21 million. About 95% already exists.
One coin divides into 100 million satoshis, which is what makes payments of a fraction of a penny meaningful rather than theoretical.
Global and indifferent
The network does not know what country a payment is from, and applies the same rules to every transaction regardless of size or sender. A payment to the next street and a payment across the world are the same operation at the same cost.
Open source
The software is public and anyone can read it, run it or fork it. For a designer this means the thing you are designing for can be inspected rather than taken on trust, and that your own work can be too. See Open design.
What BSV chose differently
Bitcoin split in 2017 and again in 2018. BSV's position is that the protocol should be restored to its original form and then left alone. Three consequences reach your work.
Capacity grows, so fees stay negligible
There is no fixed protocol limit on block size; miners raise capacity as demand grows. Fees are a small fraction of a penny and users do not compete for space.
Design consequences: no fee picker, no fee estimates, no "high fees" warning, no fee bumping. A product can absorb the fee and never show it. See Transactions.
Unconfirmed payments can be relied on for ordinary amounts
BSV miners follow a first-seen rule: the first valid version of a transaction wins, and a later conflicting one is rejected rather than swapped in. There is no replace-by-fee.
That makes accepting a payment before it is mined a reasonable risk decision for a coffee or an article, rather than the bad idea it is on a chain where unconfirmed transactions can be replaced. It is still a risk decision, not a guarantee.
The protocol is meant to stop changing
The Chronicle upgrade went live on 7 April 2026, at block 943,816. It restored the remaining original opcodes and removed most limit-based rules, and the stated intention is that the rules now stay put.
Design consequence: a script you write is expected to keep working. The flip side is that anything you want fixed in the protocol probably will not be. Chronicle opcodes also run only in transactions marked with the Chronicle version, which matters when you publish a script.
What follows for products
Those three choices, plus the BRC standards built on them, are why BSV products look different:
- Payments pass directly between wallets with their proofs attached, so the recipient knows immediately. See Payments.
- Small payments are ordinary. Pay-per-article, pay-per-request and in-game payments work without batching or credit systems.
- Data belongs on the chain too. Receipts, invoices and proofs can live alongside the payment, because space is not scarce.
- Apps connect to wallets instead of holding keys, through one standard interface. See Connecting a wallet.
Underneath those four is a specific combination this ecosystem calls the Metanet: proof of work settles the order, the set of unspent outputs is the database, and restored script lets an output carry its own conditions. Data, contracts and payments end up on one ledger instead of three systems wired together. It is the protocol's side of what the guide calls Web 3 Native. See the glossary.
What follows for a screen
Do
Say "Received" as soon as the wallet has verified the payment. A spinner waiting for a block is a wait you added.
Do
Absorb the fee and leave it off the review screen. A fee of less than 1p does not deserve a line competing with the recipient.
Do
State the minimum protocol version any script you publish depends on. Chronicle restored opcodes that older transactions do not get. See Spending conditions.
Don't
Offer to speed up, bump or cancel a payment. There is no replace-by-fee, so none of those controls can do anything, and offering them implies the payment is still yours to change.
The honest limits
A guide that only lists upsides is not believed, so:
- The price moves, in both directions. Nothing here is a claim about it. If a user needs stability, that is a stablecoin or a dollar balance, not BSV held.
- Mining is concentrated, as it is on every proof-of-work chain. "Decentralised" is a property with degrees, not a boolean.
- The ecosystem is smaller than BTC's. Fewer wallets, fewer exchanges, fewer libraries, and a real chance that a service you depend on is the only one doing that job.
- Capacity claims deserve care. Teranode sustained very high throughput in testing on a distributed test network. That is a test result, not live traffic, and a product should say which it is quoting.
- Everything on chain is permanent and public. There is no delete. See Wallet privacy.
Related
- Technology primer: the mechanics underneath
- Design principles
- How it works
- The hard parts
Written from: BSV wiki, Bitcoin whitepaper, Chronicle upgrade notes, BRC-29, BRC-100.
Checklist
The rules on this page, in a form you can work through.
4 rules
