A glossary with the caveats left in.
These definitions are deliberately operational. Each one includes the mistake the term is most often asked to conceal.
- BRC
A Bitcoin Request for Comments: a public specification or proposal in the BSV BRC corpus.
Caution: A BRC documents an interface or idea; it does not by itself prove implementation, interoperability, security, or adoption.
- BRC-100
The unified wallet-to-application interface covering wallet actions, signatures, encryption, certificates, permissions, baskets, and discovery.
Caution: A common interface enables independent implementation; compatible semantics, wallet policy and complete workflows still need versioned evidence.
BRC-100 — Unified wallet-to-application interface ↗Is BSV too complicated to build on?Is BRC-100 real interoperability or one vendor's interface?Can users actually leave a wallet, app, or overlay?Can miners, the chain, or an app sign as me or read my private data?Does Project Babbage depend too heavily on the BSV rail?- BEEF
A transaction-data format used to carry a transaction together with information needed to evaluate its ancestry and proofs.
Caution: Possessing a BEEF structure does not create absolute settlement or prove a real-world claim.
- SPV
Simplified Payment Verification: checking relevant transactions with block headers and Merkle evidence without maintaining the complete block database.
Caution: SPV reduces client burden; it does not remove chain-selection, data-availability, or reorganization risk.
- Merkle proof
A compact path showing that a transaction or item is committed by a particular Merkle root, such as one in a block header.
Caution: It proves inclusion relative to a root; it does not establish current accepted inclusion, finality, unspent status, availability or the truth of an off-chain statement.
- UTXO
An unspent transaction output: a spendable output governed by a locking script and the network's accepted rules.
Caution: Current unspent status needs current spend/conflict evidence; a proof of the creating transaction alone is insufficient. Key control and network acceptance remain distinct.
- NAR
The Network Access Rules published by the BSV Association for the relationship among the Association and participating nodes.
Caution: Read the operative parts and current version; summaries are not the agreement.
- DAR
Digital Asset Recovery: the ecosystem term for processes intended to support freezing and reassignment of disputed or recoverable BSV through node-enforced rules.
Caution: It is not the same technical mechanism as obtaining the former holder's private key or signature.
- Directive
A signed instruction contemplated by the Network Access Rules and delivered to nodes through the alert mechanism after specified events.
Caution: Authority, restrictions, legal basis, technical effect, notice, and challenge must be checked for the actual directive.
- Proof of work
The expenditure evidenced by finding a block hash below a target, used to make history costly to rewrite and to coordinate ordering among valid blocks.
Caution: More work is not a substitute for transaction and block validity, and security remains economic and probabilistic.
- Chainwork
The accumulated proof-of-work represented by a chain of block headers.
Caution: Applications still need a chain-selection and incident policy; the meaning of valid and accepted must be explicit.
- Reorganization
A change in the accepted chain tip that removes one or more previously accepted blocks and replaces them with another branch.
Caution: A reorg can be ordinary, accidental, or adversarial; describe the actual blocks, work, transactions, and rules.
- Wallet action
A BRC-100 request for a wallet to create, sign, internalize, list, or otherwise manage an application-related operation.
Caution: The wallet's permission and custody implementation determines the actual user boundary.
- Basket
A wallet-level organization mechanism for outputs associated with an application or purpose.
Caution: A basket label is not a universal data-export or cross-wallet migration guarantee.
- Identity key
A public-key identity used in BRC-103 authentication and related wallet-mediated interactions.
Caution: A key is an identifier and cryptographic control point; it is not automatically a civil identity or a proof that every attached claim is true.
- Certificate
A signed claim about a subject that can be selectively exchanged and verified in BRC-oriented identity flows.
Caution: Trust depends on issuer, claim semantics, expiry, revocation, disclosure, and verifier policy.
- Counterparty
The other party in a wallet key-derivation, payment, signature, encryption, or authenticated-message relationship.
Caution: Human-readable presentation and authentication are needed; a raw public key alone may not convey who the user is dealing with.
- Overlay
An application-specific service layer that admits, tracks, indexes, discovers, and synchronizes relevant UTXO-based state.
Caution: An overlay can decentralize application state while still depending on schemas, hosts, discovery, and the BSV rail.
- Topic manager
Overlay logic that decides which outputs are admissible for an application-defined topic.
Caution: Admission rules are application policy and should be inspectable, versioned, and consistently enforced.
- Lookup service
An overlay component that indexes admitted outputs and answers application-specific queries.
Caution: Query availability, meaning, completeness and freshness depend on the operator and index. A valid returned record does not prove that all relevant records were returned.
- SHIP
The overlay service-discovery mechanism used to advertise hosts that serve particular topics.
Caution: Discovery does not guarantee service honesty, uptime, completeness, or independent operation.
- SLAP
The overlay discovery mechanism used to locate services that answer particular lookup queries.
Caution: A discovered lookup provider remains a trust, availability, and consistency dependency.
- GASP
Graph Aware Sync Protocol: a mechanism for synchronizing relevant transaction-graph state between overlay services.
Caution: Synchronization protocol does not prove independent hosts exist or that an application's complete off-chain state is portable.
- Rail dependency
A product's dependence on the settlement network, token, proof semantics, node rules, services, or licenses specific to a blockchain.
Caution: Portable concepts or data do not make a complete running product rail-neutral.
- Conformance vector
A versioned test input and expected result used by multiple implementations to check compatible behavior.
Caution: Coverage, negative cases, runner independence, and published failures matter as much as the existence of vectors.
- Acceptance policy
The rules and evidence a participant uses to recognize a payment or history for a particular task.
Caution: Local refusal does not compel other participants or create replacement blocks.
- Economic acceptance
Recognition of a result by the businesses, services and users whose agreement makes an exchange useful.
Caution: Credible rejection can affect realizable payoff; outside incentives and failed coordination remain possible.
- Liveness
The ability of the relevant system to continue producing accepted results and serving its users.
Caution: Refusing a history does not itself provide continuing accepted production.
- Finality
The practical assurance, under stated assumptions, that a settlement result will remain accepted.
Caution: A retained inclusion proof is not absolute finality; identify history, policy and irreversible exposure.
- Availability
Whether authorized parties can obtain the records and service needed for their task.
Caution: Hashes and proofs cannot reconstruct missing bytes, schemas or keys.
- Stewardship
Responsibility for maintaining shared work, preserving competence and making decisions correctable within a defined scope.
Caution: This is an editorial framework, not proof that current authority is distributed or replaceable.
- Workflow compatibility
Successful completion of a named task using specified app, wallet and platform versions.
Caution: A passing interface check does not establish every policy or full user workflow.