Glossary

The words BSV products and their documentation use. Each entry says what the thing is and, where it matters, whether it belongs anywhere a user can see it.

Most of these do not. A glossary is for the people building the product, and a product that puts "UTXO" on a screen has mistaken its documentation for its interface.

---

The word itself

Bitcoin

In this guide, bitcoin means BSV: the protocol as originally described, with the limits on block size and scripting removed. Where the network needs naming precisely, a page says BSV.

That is a vocabulary decision, and the guide does not restate it. See Getting started.

In the interface: use Bitcoin SV the first time on a screen where the reader may be new, and BSV after that or where space is tight. Never "bitcoin" alone: "Send BSV", "Your BSV balance", "Bitcoin SV address". Outside this guide the unqualified word is an umbrella covering several chains, so on a screen where someone is about to move money it cannot tell them which network they are on.

---

Money and amounts

Satoshi

The smallest unit, one hundred-millionth of a bitcoin. On BSV it is the unit people actually meet, because fees are small enough that everyday amounts are hundreds or thousands of satoshis.

In the interface: yes. Write "sats" or "satoshis" in words; no satoshi symbol is standardised. See Amounts and units.

Fiat

Government-issued currency: pounds, dollars, euros.

In the interface: no. Say "pounds" or "local currency". "Fiat" is ideological vocabulary, not a neutral word.

Dust

A name for outputs too small to be worth spending, which is not a category on BSV: fees are low enough that a one-satoshi output is spendable.

In the interface: never. Nothing should appear as dust. See Coin selection.

---

Transactions

Transaction

A record that spends existing outputs and creates new ones. The unit of everything on the chain.

In the interface: use "payment" where a payment is what happened.

Input

A reference to an output being spent, with the data proving the spender may spend it.

Output

An amount locked to a spending condition. Spending consumes an output entirely and creates new ones.

Unspent transaction output (UTXO)

An output not yet spent. A wallet's balance is the sum of the ones it can spend.

In the interface: never. Say "balance".

Change

The output a transaction sends back to the payer, because outputs are spent whole.

In the interface: never show it as a separate entry. One payment is one entry. See Activity.

Coin selection

Choosing which outputs to spend. On BSV this is a privacy decision rather than a fee optimisation. See Coin selection.

First-seen rule

BSV miners keep the first valid version of a transaction they see and reject conflicting later ones. This is why accepting an unconfirmed payment is reasonable for ordinary amounts. See Transactions.

Zero-confirmation

A payment accepted before it is mined. A risk decision scaled to the amount, not a guarantee.

nLockTime and nSequence

The fields that make a transaction invalid until a time or block height. On BSV these are how time conditions are built, because CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY no longer act as checks. See Spending conditions.

Script

The small program locking an output, stating what is needed to spend it.

---

Keys and derivation

Private key

The secret that signs. Whoever holds it controls what it locks.

In the interface: rarely. Prefer "recovery words" or "your keys".

Public key

Derived from a private key, and safe to share. Anyone can use it to check a signature.

Master key

The one private key a modern BSV wallet holds. Every other key is derived from it. See Private key management.

Key derivation scheme

How a wallet derives a key for a specific payment: from the holder's master key, the other party's public key, and an invoice number naming what the key is for. Both parties reach the same key from opposite directions and nobody else can. Specified as proposal BRC-42.

Invoice number

The string identifying what a derived key is for, formatted <security level>-<protocol>-<key id> (BRC-43). Not an invoice in the billing sense.

Counterparty

The other party in a derivation. One of three things: a specific key, self, or anyone. Keys derived for anyone can be linked to the holder by anybody, so they give no privacy.

Key linkage

The mathematical relationship between a master key and keys derived from it. Revealing it lets a third party confirm which activity was yours. Revealing linkage for a whole counterparty exposes every past and future payment with them, not just one. See Wallet privacy.

Recovery words

Twelve to twenty-four words encoding a master key (BRC-75). They use the BIP-39 wordlist and format, and produce different keys from a wallet built on BIP-32, so words from one do not restore the other.

In the interface: yes, and this is the term. Never "seed phrase" or "mnemonic".

Backup shares

A secret split so that any set number of pieces rebuild it and fewer reveal nothing (BRC-140). An alternative to recovery words, not an addition.

In the interface: yes, as "backup shares" or "pieces". Never "Shamir".

Wallet records

What the wallet knows about its own outputs: which are the user's, and the derivation details needed to spend them. Not on the chain, and therefore the part of a backup that keys cannot replace. See Backups.

In the interface: call the file the wallet backup. It holds the outputs, payment derivation details, baskets, labels, Passes and pending work. The wording to use: "Your recovery words restore your keys. Your wallet backup restores your records: which money is yours and how to spend it. Keep both."

Basket

A named group of outputs in a connected wallet, so an app's outputs, a token's outputs and spending money stay separate.

---

Payments and identity

Peer-to-peer payment

The recommended payment flow: the sender builds the transaction and hands it directly to the recipient with its proofs, rather than broadcasting and waiting. Specified as proposal BRC-29. See Payments.

In the interface: no. The user sees a payment.

BEEF

The package carrying a transaction, its ancestors and the merkle proofs that let a recipient verify it without a node (Background Evaluation Extended Format, BRC-62).

Address

An encoding of a public key, 26 to 35 characters, that funds can be sent to. On BSV a fresh one is derived per payment and users never see it; a plain address is a legacy route kept for exchanges and older wallets.

In the interface: no, except on the deliberate "send to external wallet" path. Read more.

Handle

A readable name that resolves to someone's public key and where to pay them. Paymail is anna@example.com (BRC-28); the newer scheme is @anna@example.com with optional +tag (BRC-169).

In the interface: yes. "Handle" is the word. For which form to display, see Paying by handle.

Paymail

The established handle scheme, where the domain is the authority and answers resolution requests.

In the interface: no. Say handle.

Pass

A certificate proving one attribute about someone, such as being over 18 or being a registered business (BRC-52). The user chooses what to present.

In the interface: yes. Never "credential" or "verifiable credential".

Identity key

The key representing a person or organisation, used for authentication and Passes rather than for signing payments directly.

HTTP 402

The status code a server returns to ask for payment, letting an app charge per request without an account (BRC-121). See Payments.

---

Verification and the network

Simplified payment verification (SPV)

Checking that a transaction is in a block using block headers and a merkle proof, without holding the whole chain. How BSV wallets verify. See Nodes and verification.

Block header

A fixed-size record summarising a block, including its merkle root. A wallet holds headers rather than transactions.

Merkle proof

The short list of hashes connecting a transaction to a block's merkle root. A few hundred bytes.

BUMP

BSV Unified Merkle Path (BRC-74), the format merkle proofs travel in.

Block

A set of transactions added to the chain together, about every ten minutes.

Proof of work

The computation a miner must do to add a block. What makes rewriting history expensive.

Node

Software that validates transactions and builds blocks. On BSV this is mining infrastructure.

In the interface: never, in a consumer product. Users do not run nodes.

Teranode

Node software built for very high transaction volumes. A miner and enterprise concern.

ARC

A broadcast service: a wallet submits a transaction, ARC propagates it and returns the merkle proof once mined.

Overlay service

A service indexing outputs relevant to a particular application or token type. It indexes; it does not hold funds.

---

Wallets and apps

Wallet

Where keys live and payments are made. On BSV also the thing apps talk to. The word is used for several different things, which is worth being precise about internally. Read more.

In the interface: yes, though "your money" is often better.

Wallet Application Interface

How an app asks a wallet to pay, sign or prove something. The app never holds keys; the wallet decides and returns a result, and an app built once works with any compatible wallet. Specified as proposal BRC-100.

In the interface: the string users see is Connect wallet. Never the proposal number. See Connecting a wallet.

Connected wallet

A wallet an app can ask for a payment, a signature or a Pass, through the Wallet Application Interface. The app never sees a key, and the wallet decides every request.

In the interface: say "your wallet". Never "BRC-100 wallet". Read more.

Metanet

The application layer BSV is for: data, contracts and payments on one public ledger, rather than a payment rail with applications built alongside it. The name comes from a 2018 proposal for structuring on-chain data as a linked graph, and is now used more broadly for the whole capability set.

What separates it from the looser Web 3 Native is that it names three specific things in combination, rather than an aspiration: proof of work settling order and finality, the set of unspent outputs serving as the database, and the original script restored so an output can carry its own conditions. Remove any one and the other two stop being able to do this.

In the interface: no. It is ecosystem vocabulary, for prose and developer documentation. A wallet never says "Metanet" to a user.

Web 3 Native

The user-facing benefit of the Wallet Application Interface: an app a person connects their own wallet to, which never holds their keys or their data.

Used interchangeably with Metanet in conversation, and the broader of the two. Web 3 Native describes the shape of the app, from the user's side. Metanet names what makes that shape possible here, from the protocol's side.

In the interface: only where the product must name the category, such as a store listing, and then in this exact form, spaced and capitalised. Never the lower-case "web3", which reads as marketing and claims nothing in particular.

Token

An output that represents something other than money: a ticket, a share, a collectible, a stablecoin. Owned and moved the way a payment is, with its whole history attached. See Holding tokens.

In the interface: yes, though the specific thing is usually the better word. "Your ticket" beats "your token".

Inscription

Content written into the script that locks an output, so the data and the ownership are the same thing. How 1Sat Ordinals carry what a token is.

In the interface: no. The user owns an item, not an inscription.

Micropayment

A payment small enough to make many times without its cost mattering. On BSV this means a few satoshis. See Charging per use.

In the interface: no. Show the price and the total, never the category.

Agent

Software that spends on a person's behalf within limits they set, rather than asking each time. See Letting an agent spend.

In the interface: name it for what it does, such as "Research assistant", rather than "agent".

Spending allowance

A budget a user grants an app, so small payments can go without a prompt each time. See Spending allowances.

In the interface: yes. "Allowance" is the word.

Everyday wallet

The wallet a person connects to apps and spends from, holding only what they could stand to lose. See Wallet setups and Daily spending wallet.

Savings wallet

A wallet for larger amounts that does not accept requests from apps at all. See Wallet setups and Savings wallet.

Agent wallet

A wallet for software spending on a person's behalf, with its own keys and hard limits. See Wallet setups.

External signer

A device holding a key offline, that signs transactions carried to it. See External signers.

Multi-key

A spending condition requiring several keys. On BSV this is bare multisig, visible in the output, because new P2SH outputs are not allowed. See Multi-key.

Custodial

Someone else holds the keys. A legitimate product, and not self-custody. Say which one yours is.

In the interface: say what it means, as on Wallet.

---

Terms from other chains

These appear in older documentation and in BTC tooling. They do not apply here, and a tool asking for one is a BTC tool.

Several are still relevant when supporting older BSV wallets or exchanges. See Legacy compatibility.

---

Related

• The BSV wiki, for protocol detail
• The BRC standards, for the interfaces products are built on
• How it works, for what each of these means for a design