327 terms
Glossary
#
- 1Sat tip
A 1Sat tip is the current unspent output of a token or inscription that follows the one-satoshi-per-output convention, representing the latest state of that token or inscription in its chain of transfers. Following the chain of 1Sat outputs back to their origin lets a wallet find the tip that currently holds the asset.
Used inBRC-158
A
- Account association
An Account association is a recorded link between an identity or key and a specific account, establishing that the account belongs to or is controlled by that identity. It allows systems to confirm which identity is responsible for actions taken on the account.
Used inBRC-201- account-based system
An account-based system is a model for tracking balances where each participant has an account with a running balance that is directly updated by transactions, rather than tracking discrete spendable outputs. Ethereum is a well-known example of a blockchain using this model.
Used inBRC-20- account-label
A human-readable name or identifier assigned to an account, used to distinguish it from other accounts within a system. It serves as a friendly reference rather than a technical identifier like a key or address.
Used inBRC-205- acquisitionId
An acquisitionId is a unique identifier assigned to a specific act of acquiring or obtaining something, such as a purchased item, license, or data set. It allows that particular acquisition to be referenced, tracked, or looked up later.
Used inBRC-195- Action
A transaction as the wallet interface talks about it: the transaction itself plus the description, labels and output metadata a wallet keeps alongside it.
Used inBRC-65BRC-100BRC-114See alsoWallet interfaceBasket- action plan
An action plan is a structured description of a sequence of operations, such as transaction inputs, outputs, and signing steps, that must be carried out to accomplish a desired outcome. It serves as an intermediate representation between a high-level request and the final signed transaction.
Used inBRC-207- admission attestation
An admission attestation is a signed statement confirming that a party or action has been accepted or approved according to defined rules. It serves as verifiable proof that an admission decision was made, which other parties can check without redoing the original evaluation.
Used inBRC-175- advertiser
A party that publishes a signed record announcing the existence and location of a service, such as an overlay node offering lookup or topic support. The advertisement lets other participants discover and verify who provides a given service.
Used inBRC-23- air gap
An air gap is a physical isolation between a device holding sensitive data, such as private keys, and any network-connected system. Data crosses an air gap only through manual or offline means, such as QR codes or removable media, reducing exposure to remote attacks.
Used inBRC-225- allowance output
An allowance output is a transaction output that sets aside or earmarks funds for a specific permitted purpose or spending limit, rather than leaving them freely spendable. It allows a system to enforce budget-like constraints on how those funds can later be used.
Used inBRC-204- allowanceId
An allowanceId is a unique identifier assigned to a spending allowance, a pre-authorized budget or permission that limits how much value or how many operations an application or counterparty can use. It lets a wallet or service track, reference, and manage that specific allowance separately from others.
Used inBRC-204- anchor
A fixed reference point, often a transaction or piece of data, that other records point back to in order to establish order, origin, or connection. It gives later data a stable base from which relationships can be verified.
Used inBRC-145- anchor transaction
A transaction that serves as a fixed, on-chain reference point that other data or transactions can be tied to for verification purposes. It provides a trusted anchor in the blockchain against which related off-chain or auxiliary information can be checked.
Used inBRC-134- anyone-derivation
Anyone-derivation is a key derivation method where a new key is computed from a base key using a publicly known rule, so that anyone can produce the same derived key without needing secret input. It is used when parties need to independently arrive at matching keys without exchanging additional secret material.
Used inBRC-43- ASM
ASM stands for Assembly, referring to a human-readable text representation of Bitcoin script opcodes and data, written as space-separated mnemonics. It allows developers to read and write scripts without working directly in raw hexadecimal bytecode.
- asset ID
An asset ID is a unique identifier assigned to a specific digital asset, typically derived from the transaction or output that created it. It allows that asset to be unambiguously tracked and referenced across the system, separate from any other asset.
Used inBRC-209- assetId
An assetId is a unique identifier assigned to a specific token or digital asset, distinguishing it from all other assets within a system. It allows wallets and applications to reference and track a particular asset across transactions.
Used inBRC-207- Atomic BEEFBEEFBRC-95
A BEEF bundle restricted to exactly one subject transaction and its ancestry, for cases where a general bundle of several transactions would be ambiguous about which one matters.
- AtomicBEEF
A data format that packages a single Bitcoin transaction together with all the supporting information, such as merkle proofs and ancestor transactions, needed to independently verify it. The BEEF part stands for Background Evaluation Extended Format, and 'Atomic' indicates it is scoped to one specific transaction.
Used inBRC-150- AuditRecord
A structured record that documents an action, transaction, or event for the purpose of later verification or review. It provides evidence that can be checked against expected rules or outcomes.
Used inBRC-122- authentication proof
An authentication proof is data, typically a digital signature, that demonstrates a party controls a specific private key without revealing that key. It is presented to verify identity or authorize an action in a protocol exchange.
Used inBRC-138
B
- backup service
A third-party or self-hosted system that stores encrypted backup data on behalf of a user so it can be retrieved later if local data is lost. It typically holds pieces of a split secret rather than the whole secret, so no single backup service alone can reconstruct sensitive key material.
Used inBRC-154- base58btc
Base58btc is a scheme for encoding binary data as text using 58 characters, omitting symbols like 0, O, I, and l that are easy to misread. It is commonly used to represent keys and addresses in a form that is short, copy-pasteable, and resistant to transcription errors.
Used inBRC-202- Basketoutput basketbasket IDBRC-46 basketwallet basket
A named grouping a wallet uses to track the outputs belonging to one application or purpose. An application can list what is in its basket, and spending an output removes it from the basket.
- BasketMap
A BasketMap is a data structure that associates named baskets, which are logical groupings of outputs or tokens held by a wallet, with the specific outputs or identifiers belonging to each basket. It allows software to organize and retrieve related outputs by category rather than treating them as an undifferentiated list.
- BEEFBackground Evaluation Extended FormatAtomic BEEF
A format that bundles a transaction together with the ancestor transactions and merkle proofs needed to check it. The recipient can verify it against block headers alone, without asking a node or an indexer for anything.
- bit mask
A bit mask is a fixed pattern of bits used to select, set, clear, or test specific bits within a binary value through operations like AND, OR, or XOR. It lets a program isolate or manipulate individual flags packed together inside a single number.
Used inBRC-212- Bitcoin Signed Message
A Bitcoin Signed Message is a text message signed using a Bitcoin private key in a standard format, producing a signature that anyone can verify against the corresponding Bitcoin address or public key. It proves control of a key without requiring an on-chain transaction.
Used inBRC-217- BKDSBSV Key Derivation Schemetype 42Type-42
The key derivation scheme underneath most of the corpus. Two parties compute an ECDH shared secret and combine it with an invoice number, which lets a sender derive a public key for a recipient without knowing the recipient's private key, and lets the recipient later derive the matching private key.
- block header
A block header is the fixed-size piece of data at the start of a block that summarizes its contents, containing fields such as the previous block's hash, a timestamp, difficulty target, nonce, and the Merkle root of the block's transactions. It is what gets hashed to prove proof of work and is what other nodes check to verify a block without needing every transaction.
Used inBRC-144- BlockHash
A BlockHash is the cryptographic hash computed over a block's header, serving as that block's unique identifier on the blockchain. It is used to reference, verify, and link blocks together in the chain.
Used inBRC-135- bloom filter
A space-efficient data structure that allows quick testing of whether an item is possibly a member of a set, with a small chance of false positives but no false negatives. It is used to let a client request potentially relevant transactions from a node without revealing exactly which ones it is interested in.
Used inBRC-76- BRC-192 signed object
A BRC-192 signed object is a data structure formatted according to the BRC-192 standard that includes a digital signature verifying its authenticity and integrity. It allows a recipient to confirm who created the object and that its contents have not been altered since signing.
Used inBRC-194- BRC-31 identity key
A public key used under the BRC-31 (Authrite) standard to identify a party in an authenticated request or response. It lets the recipient verify who sent a message by checking an accompanying signature against this key.
Used inBRC-25- BRC-98 permission modulep protocol modulep protocol
The BRC-98 permission module is a defined component described in Bitcoin specification BRC-98 that manages whether a given action, such as accessing a key or protocol, is authorized. It checks and enforces permission rules before allowing an operation to proceed.
- bstr
bstr is a data type representing a byte string, meaning a sequence of raw bytes without a specified text encoding. It is commonly used in binary data formats to hold arbitrary binary content such as keys, hashes, or signatures.
Used inBRC-231- BUMPBSV Unified Merkle Path
A compact binary format for a merkle path, carrying the hashes needed to prove a transaction is in a block. It is the proof format BEEF carries.
- bundle
A bundle is a grouped set of related data items, such as transactions or files, packaged together so they can be transmitted, stored, or verified as a single unit rather than individually. The exact contents depend on the protocol using it, but the purpose is always to reduce overhead by handling many items in one structure.
Used inBRC-142
C
- candidate set
A candidate set is the collection of possible options or items being considered before one is selected through some evaluation or choice process. It represents all valid possibilities at a given point, prior to filtering or final selection.
Used inBRC-221- canonical derivation
Canonical derivation is a standardized, repeatable way of generating a key or identifier from given inputs so that any party following the same rules arrives at exactly the same result. This consistency allows different implementations to independently compute matching keys without needing to exchange them directly.
Used inBRC-229- canonical encoding
Canonical encoding is a single, well-defined way of serializing a piece of data so that the same logical value always produces exactly the same byte sequence. This uniqueness is important for signatures and hashes, where differing encodings of equivalent data would otherwise produce different results.
Used inBRC-138- canonical proof bytescanonicalBytesproofHash
Canonical proof bytes are the exact, standardized byte-for-byte serialization of a proof, ensuring that the same logical proof always produces identical binary data regardless of who generates it. This consistency is needed so that hashes or signatures computed over the proof match reliably between different implementations.
Used inBRC-220- certificate level
Certificate level refers to a designation indicating the degree of trust, verification, or authority associated with a given certificate. It helps a relying party understand how much assurance to place in the claims the certificate makes.
Used inBRC-108- Certifier
The party that issues an identity certificate. Anyone relying on the certificate is trusting the certifier, not the site showing it.
Used inBRC-52BRC-103See alsoIdentity certificate- CertMap
A CertMap is a mapping structure that associates certificate types or identifiers with the fields or handlers relevant to processing them. It allows a system to determine which certificate related rules or data to apply based on the certificate's type.
Used inBRC-184- Chaintracks
Chaintracks is a service or component responsible for tracking block headers and chain state so that other software can verify proofs and determine block confirmations without running a full node. It provides the chain context needed to validate things like Merkle proofs.
Used inBRC-11- ChainView
ChainView is an interface or service abstraction that provides read access to blockchain state, such as transaction and block data, without specifying how that data is sourced internally. Applications use it to query chain information in a consistent way regardless of the underlying node or data provider.
Used inBRC-192- CHIP
CHIP stands for a Change or Cash Improvement Proposal, referring to a formal document that proposes a change, enhancement, or new standard for the network or its protocol. It typically describes the motivation, specification, and rationale for the proposed change.
Used inBRC-23- chooser
A chooser is a component or function that selects one item from a set of available options according to defined rules or criteria. In protocol contexts it determines which candidate, among several possibilities, should be used next.
- CLAP
CLAP stands for Chain Lookup Availability Protocol, a protocol used to advertise which lookup services a given overlay node provides. It helps clients find nodes that can answer queries for a particular lookup service.
Used inBRC-25- coinbase
The coinbase is the first transaction in a block, which creates new bitcoins and collects transaction fees as a reward for the miner who found the block. It has no real inputs, instead using a special input field that miners can fill with arbitrary data.
Used inBRC-144- coinbase transaction
A coinbase transaction is the first transaction in a block, created by the miner who mined that block, which has no real inputs and instead creates new bitcoins as a reward plus any collected transaction fees. It is the mechanism by which new bitcoin enters circulation.
- collection grant
A collection grant is a permission record that authorizes access to or use of a defined collection of items, such as data or content, under specific conditions. It specifies what the grant covers and who or what is allowed to exercise it.
Used inBRC-178- collectionRef
A collectionRef is a reference identifier that points to a specific collection of related items, such as tokens or assets, rather than to a single item itself. It allows data or transactions to link back to the group they belong to without duplicating the collection's full details.
Used inBRC-227- Collector
A Collector is a component or service responsible for gathering data, such as transaction inputs, proofs, or records, from one or more sources and assembling them for further processing. It centralizes retrieval so that other parts of a system do not need to query each source directly.
Used inBRC-225- commitment
A commitment is a piece of data that binds someone to a specific value or statement without revealing that value, in a way that can later be checked for consistency. It is typically created using a cryptographic hash so that any attempt to change the underlying value after the fact would be detectable.
- commutative masking
Commutative masking is a technique where a masking operation, usually XOR, is applied to data such that the order in which multiple masks are applied or removed does not affect the final result. This property allows masks to be layered or stripped independently by different parties without needing to coordinate the exact sequence.
Used inBRC-229- compliance rules
Compliance rules are the specific conditions or checks that data, transactions, or entities must satisfy in order to be considered valid or acceptable under a given standard or policy. They are typically enforced programmatically to ensure consistent behavior across implementations.
Used inBRC-108- Conforming Application
A Conforming Application is software that correctly implements all the required rules and behaviors defined by a given specification. Meeting this status means other systems can interoperate with it with the expectation that it behaves as the standard describes.
Used inBRC-232- conforming certifier
A conforming certifier is an entity that issues certificates while following a specific set of rules or standards required for its certificates to be accepted as valid within a given system. Being conforming means its practices and outputs meet the criteria that relying parties expect.
Used inBRC-200- Connect Decision Flow
Connect Decision Flow is the sequence of steps and choices a wallet and an application go through when establishing a connection, such as verifying permissions, confirming identity, and approving requested access. It defines what prompts or checks occur before a wallet agrees to link with an application.
Used inBRC-137- conservation
Conservation is the rule that the total quantity of a token, or the total value of bitcoin, going into a transaction must equal the total quantity or value coming out, aside from any explicitly allowed issuance or burning. It ensures that value cannot be created or destroyed except through rules the protocol explicitly permits.
Used inBRC-176- content hash
A content hash is a fixed-length digest produced by running a piece of data through a cryptographic hash function. It uniquely represents the content so that any change to the data produces a different hash, allowing integrity checks without storing the full content.
Used inBRC-178- ContentID
A unique identifier for a specific piece of content, typically derived from a hash of the content itself so that it changes if the content changes. It allows content to be referenced and verified without relying on its storage location.
- contextual identity
A contextual identity is an identity representation that is specific to a particular relationship, application, or situation rather than a single fixed identity used everywhere. The same underlying entity can present different contextual identities to different counterparties to limit what each one can learn or link together.
Used inBRC-191- Controllercoordinator
The party that holds the private key controlling a given key-value token or similar on-chain record, giving it the authority to update or delete that record. Only the controller can produce a valid signature to change the record's state.
- Counterparty
The other party a key is derived with respect to. Because derivation uses a shared secret between two identity keys, a key derived for one counterparty is meaningless to anyone else.
- counterparty-level revelation
Counterparty-level revelation is the practice of disclosing information, such as a key or identity detail, only to a specific other party involved in a transaction rather than publicly. It allows selective sharing so that only the intended recipient can link or verify the disclosed data.
Used inBRC-97- covenant
A covenant is a restriction placed on a bitcoin output that constrains how the coins can be spent in the future, for example by limiting valid recipients or enforcing conditions on the spending transaction. It is enforced by script logic rather than by any external authority, so the restriction is checked automatically when someone tries to spend the output.
Used inBRC-174- coverage
Coverage refers to the extent to which a set of tests, rules, or data exercises or accounts for all relevant cases in a system. Higher coverage means fewer untested paths or unhandled scenarios remain.
Used inBRC-325- createAction
createAction is a wallet function call that builds and signs a new Bitcoin transaction based on a set of requested outputs, inputs, and metadata. It returns the resulting transaction along with details needed for tracking or broadcasting it.
- custom verb
A custom verb is an action keyword defined by a specific application or user rather than by the core standard, allowing it to represent behavior not covered by the predefined set of actions. Its meaning is only guaranteed within the context that defined it.
Used inBRC-218
D
- DAG-CBORCBOR
DAG-CBOR is a deterministic, restricted encoding of CBOR (Concise Binary Object Representation), a binary data serialization format, designed so that any given data structure always produces exactly one canonical byte encoding. This determinism allows encoded data to be content-addressed, meaning it can be linked and referenced by a hash of its bytes, as used in Merkle DAG (directed acyclic…
- declarationTx
A declarationTx is a transaction whose purpose is to publicly declare or register some piece of information, such as an identity, asset, or commitment, on the blockchain. Other data or protocol steps can then reference this transaction as the authoritative starting point for that declaration.
Used inBRC-209- deferred admission
Deferred admission is a process where a decision to admit or accept something, such as a transaction or user, is postponed rather than made immediately. This allows additional checks, evidence, or conditions to be satisfied before final acceptance occurs.
Used inBRC-175- delivery record
A delivery record is a stored entry that documents the successful transfer of an item, message, or data to its intended recipient. It provides evidence of when and how the delivery occurred, distinct from the record of the original submission.
Used inBRC-149- deploy output
A deploy output is the transaction output created when a new token type is first defined, establishing its initial rules and parameters. Its location (transaction id and output index) becomes the reference point used to identify that token going forward.
Used inBRC-162- DER format
Distinguished Encoding Rules format, a standardized binary encoding used to represent data structures like digital signatures in a compact, unambiguous way. Bitcoin transactions commonly encode ECDSA signatures using DER format so that software can reliably parse them.
- derivation prefixnonce
A derivation prefix is a value combined with other derivation inputs, such as a key ID, to compute a child key from a parent key in a structured key derivation scheme. It helps organize and distinguish groups of derived keys within a larger key hierarchy.
- Derivation Suffix
A derivation suffix is a piece of extra data appended to a base key derivation path or invoice number to produce a unique child key deterministically. It allows the same root key to generate many distinct, unlinkable keys for different purposes or transactions.
- derivationPrefix
A value used as the starting segment in a key derivation process, allowing a specific child key to be generated from a parent key in a deterministic and reproducible way. It helps identify or reconstruct which derived key was used without exposing the parent private key.
- Descriptor
A descriptor is a structured piece of metadata that describes properties of an object, such as a key, output, or script, including information needed to interpret or reconstruct it. It allows software to understand how to use or derive something without needing the underlying raw data directly.
Used inBRC-369- deterministic spend reconciliation
Deterministic spend reconciliation is a process for matching spent outputs to their corresponding inputs using fixed, repeatable rules so that the same result is produced every time given the same data. This ensures different parties or systems independently arrive at identical conclusions about which outputs were consumed by which transactions.
Used inBRC-192- did:keyDID
did:key is a specific type of Decentralized Identifier that encodes a public key directly into the identifier string itself, rather than pointing to an external document. This means the DID can be resolved offline, since the key material needed to verify it is already contained in the identifier.
Used inBRC-202- Disabled sentinel outpoint
A Disabled sentinel outpoint is a specific transaction output that has been deliberately marked or spent in a way that signals a related feature, token, or process is no longer active. Other parties watching the blockchain can detect this outpoint's state to know that the sentinel condition has been disabled.
Used inBRC-201
E
- ECDHelliptic curve Diffie-Hellman
A way for two parties to compute the same shared secret from their own private key and the other party's public key, without either private key being sent anywhere.
- ECDSA
ECDSA stands for Elliptic Curve Digital Signature Algorithm, a method for creating a digital signature using elliptic curve cryptography. It lets someone prove they hold a private key by signing a message, while anyone with the matching public key can verify the signature without learning the private key.
Used inBRC-3- Ecosystem
An ecosystem refers to the broader collection of software, services, standards, and participants that interact around a particular blockchain network or protocol. It encompasses wallets, applications, infrastructure providers, and users who together rely on shared standards to interoperate.
Used inBRC-169- Ecosystem host
An entity or service that provides infrastructure or a platform on which other applications, wallets, or services operate within a broader network. It supports the surrounding participants without necessarily being the originator of the data or transactions they process.
Used inBRC-169- ECPM
ECPM stands for Elliptic Curve Point Multiplication, the mathematical operation of adding an elliptic curve point to itself a given number of times. It is the core operation behind elliptic curve cryptography, used for deriving public keys and shared secrets from private keys in Bitcoin.
Used inBRC-229- EF marker
The EF marker is a fixed byte sequence placed in a serialized transaction to signal that it is encoded in Extended Format rather than the standard format. Software reading the data checks for this marker to decide how to parse the fields that follow.
Used inBRC-128- eliciting request
An eliciting request is a message sent specifically to prompt a required response or action from the receiving party before a process can continue. It signals that further interaction, such as providing missing information or granting permission, is needed.
Used inBRC-325- emitter
An emitter is a network node or process responsible for generating and sending out messages or data, such as block or transaction announcements, to other participants. It acts as the originating source in a publish-style data distribution system.
Used inBRC-135- enumerator
An enumerator is a component or function that produces a list or sequence of available items, such as candidates or identifiers, one at a time. It is typically used to generate the full set of options that another process, such as a chooser, will act on.
Used inBRC-221- envelope
An envelope is a data structure that wraps a message or payload together with metadata such as signatures, identifiers, or routing information needed to process it. The wrapping lets a recipient verify or interpret the contents without altering the original payload itself.
Used inBRC-222- Epoch
A defined period of time or range of blocks over which a particular set of rules, data, or state is considered valid. Epochs are used to segment ongoing processes into discrete, bounded intervals.
- EPOCH_CLOSE
A marker or event indicating the end of an epoch, signalling that the interval has concluded and no further data for it should be accepted. It is used to delimit where one epoch's scope ends.
Used inBRC-122- EPOCH_OPEN
A marker or event indicating the start of a new epoch, signalling that a new interval has begun and subsequent data or transactions belong to it. It is used to delimit where one epoch's scope begins.
Used inBRC-122- equivocation
Equivocation is the act of making two or more conflicting statements or commitments about the same fact, such as signing two different transactions that spend the same funds. It is treated as a detectable form of dishonest or faulty behavior because the conflicting records can be compared to prove inconsistency.
Used inBRC-192- ERC-20
ERC-20 is a technical standard used on the Ethereum blockchain that defines a common set of rules and functions for creating fungible tokens. It is referenced here as an example of a token standard from a different blockchain ecosystem.
Used inBRC-20
F
- fault party
The fault party is whichever participant in a transaction or protocol is determined to be responsible for a failure or error that occurred. Identifying the fault party matters for deciding who bears the consequences, such as retrying an action or forfeiting a deposit.
Used inBRC-326- Federated Overlay
A Federated Overlay is an overlay network service run cooperatively by a defined group of participating nodes rather than a single operator. These nodes share responsibility for validating and propagating data for a given topic according to agreed rules.
Used inBRC-183- field revelation keyK_f
A cryptographic key that decrypts one specific field of an encrypted certificate. Sharing this key with a verifier reveals only that field's contents without exposing any other data in the certificate.
Used inBRC-52- first-seen ingress position
First-seen ingress position refers to the order in which a piece of data, such as a transaction, was first observed entering a node or system relative to other data. It is used to establish a consistent local ordering when multiple items arrive close together in time.
Used inBRC-192- flag registry
A flag registry is a maintained list that assigns specific meanings to flag values, such as bits or codes, so that different implementations can interpret them consistently. It acts as a shared reference so a numeric or bit-based flag always maps to the same defined behavior or feature across systems.
Used inBRC-212- flowIdx
An index value that identifies a particular flow, such as a stream of data or transactions, within a system that manages multiple concurrent flows. It allows individual flows to be tracked and referenced separately.
Used inBRC-131- fragDataSize
fragDataSize is a field specifying the size, in bytes, of the data payload carried within a single fragment of a larger message. Receivers use it to know how much data to read from each fragment during reassembly.
Used inBRC-130- frame set
A frame set is a collection of individual frames grouped together as a single logical unit for transmission or processing. Each frame within the set typically carries part of a larger message that must be reassembled by the receiver.
Used inBRC-225- Frame Version
Frame Version is a field in a message or packet header that identifies which version of the framing structure is being used. Receivers read it first so they know how to interpret the rest of the frame's layout.
Used inBRC-128
G
- GEDCOM
Genealogical Data Communication, a file format standard used to store and exchange genealogical information such as family trees and ancestry records. It defines a structured way to represent individuals, relationships, and events across different genealogy software.
Used inBRC-63- GenerationID
A GenerationID is an identifier that marks a particular version or iteration of a data set or process, allowing participants to distinguish it from earlier or later generations. It helps receivers confirm they are working with matching or up-to-date data.
Used inBRC-139- genesisRef
A genesisRef is a reference pointing back to the originating or first item in a chain of related data, such as the initial transaction or token creation event that subsequent items derive from. It lets later items be traced back to their original source for verification or lineage purposes.
Used inBRC-226- getVersionBRC-100 version call
A method or function call that returns the version number or identifier of a software component, protocol implementation, or API. It allows a caller to determine which version they are interacting with before proceeding.
- global verb
A global verb is an action keyword that is recognized and given a fixed, standard meaning across the entire system, rather than being defined locally by an individual application. Any participant can rely on a global verb having the same behavior wherever it appears.
Used inBRC-218- grandfathering
Grandfathering is the practice of allowing existing data, transactions, or participants that were valid under older rules to remain valid even after new rules are introduced. It prevents retroactive invalidation of things created before a protocol or policy change.
Used inBRC-234- GroupAnchorFlow
A process for establishing a shared anchor point that links a group of related transactions or data records together. It allows multiple items to be verified as belonging to the same logical set by tracing them back to a common starting reference.
Used inBRC-134- GroupBlockBroadcast0xFFFEFF0E::B:FFFE
A message used to broadcast information about a block to a group of network participants, such as those subscribed to a related multicast group. It disseminates block data to multiple recipients efficiently in a single transmission.
- GroupID
A unique identifier assigned to a group of related items so they can be referenced and managed collectively. It distinguishes one group from another within a system.
Used inBRC-127
H
- Handle@handle@ecosystemBRC-169 handle
A human readable name or label used to identify a user, account, or resource in place of a raw technical identifier like a key or address. It makes referencing an entity more convenient for people while still mapping to the underlying technical identity.
- hash chain
A sequence of data items where each item includes a hash of the previous item, creating a linked structure that makes tampering with earlier entries detectable. Verifying the chain confirms that no item in the sequence has been altered or reordered.
Used inBRC-60- HASH160
HASH160 is a cryptographic hashing operation that applies SHA-256 followed by RIPEMD-160 to input data, producing a 160-bit hash. It is commonly used to create shortened representations of public keys, such as in addresses.
Used inBRC-17- HashKey
A key value derived from or used with a cryptographic hash function, often used to identify, index, or authenticate data. It ensures that the associated data can be uniquely referenced or verified based on its hash.
- hashOutputs
hashOutputs is a single hash computed over all the outputs of a transaction, used within signature algorithms so that a signer commits to exactly what the transaction pays out without needing to sign each output separately. Changing any output invalidates a signature that depended on this hash.
Used inBRC-226- History chain
A sequence of linked past states or transactions that shows how a record or token evolved over time. Following the chain from the current state back to its origin lets a party verify the full provenance of the data.
Used inBRC-35- HMAC
Hash based Message Authentication Code, a method for producing a fixed size code from a message and a secret key that proves both the message's integrity and that it came from someone holding the key. It is computed by combining a cryptographic hash function with the secret key in a specific construction.
- holding gate
A holding gate is a checkpoint that temporarily withholds data, funds, or a process from proceeding until some condition or verification step is satisfied. It acts as a controlled pause point rather than a permanent block.
Used inBRC-190- Host
A Host is a computer or server participating in a network that sends, receives, or relays data, such as joining a multicast group to exchange blockchain messages. It represents an addressable endpoint identified typically by a network address.
Used inBRC-178
I
- identity binding
Identity binding is the cryptographic linking of a real-world or persistent identity to a specific key or credential. It allows a verifier to trust that actions performed with that key or credential can be attributed to the bound identity.
Used inBRC-174- identity certificateBRC-52 certificateBRC-52
A digital certificate that attests to facts about a person's or entity's identity, such as name or attributes, signed by a certifier. It allows the holder to selectively prove claims about themselves to others without revealing unnecessary information.
- Identity certificatecertificate
A signed statement by a certifier about someone's identity, with the fields encrypted so the holder chooses which to reveal and to whom.
Used inBRC-52BRC-53BRC-103See alsoCertifierIdentity key- identity commitment
An identity commitment is a cryptographic value that represents a person's or entity's identity without exposing the underlying identifying information directly. It allows the identity to be referenced and later verified or linked without disclosing sensitive details upfront.
Used inBRC-108- Identity keyBRC-42 Identity KeyBRC-42master public key
The master public key that identifies a wallet, and by extension its user. It is safe to share, and other standards derive per-purpose keys from it rather than using it directly.
- identity packet
A bundled piece of data that carries identity related information, such as certificate fields or credentials, for transmission between parties. It packages the information needed to prove or convey aspects of a person's or entity's identity.
Used inBRC-51- identity spillover
The unintended leakage of information that allows separate actions or accounts belonging to the same underlying identity to be linked together. It undermines privacy by letting an observer connect activities that were meant to remain separate.
Used inBRC-152- ik1 codeik1
A short identifier code used to reference or classify an identity key within a key management scheme. It functions as a compact label distinguishing one identity key from another.
Used inBRC-145- integrity tag
A piece of data attached to a message or record that allows a verifier to check whether the content has been altered since it was created. It is typically generated using a cryptographic function over the data and a key.
Used inBRC-140- Interactive wallet
An interactive wallet is a wallet application that expects a human user to be present to review and approve actions such as spending funds or granting permissions. It typically shows prompts or dialogs and waits for user input before completing sensitive operations.
Used inBRC-219- internalizeAction()
A wallet function that takes an existing transaction and imports it into the wallet's own storage, labeling and processing its outputs so they become part of the wallet's managed funds or data. It allows a transaction created or received outside the normal wallet flow to be recognized and tracked by the wallet afterward.
- invoice fingerprint
An invoice fingerprint is a unique identifier derived from the details of a specific invoice, typically produced by hashing its contents. It allows systems to reference or verify a particular invoice without storing or transmitting the full invoice data.
Used inBRC-109- Invoice numberBRC-43 invoice numberBRC-43 label
The string fed into key derivation that makes each derived key unique. It is open-ended by design, so a protocol can number its keys however suits it.
- issuance decision
An issuance decision is the determination made by an authority on whether to issue a particular certificate, credential, or token to a requesting party. It reflects the outcome of whatever checks or criteria the authority applied before granting the item.
Used inBRC-200
K
- k-value
The k-value is the random or deterministic nonce chosen during ECDSA signature generation, used in computing the R and S components of a signature. Its value directly determines the R-value that appears in the resulting signature.
Used inBRC-17- key commitment
A key commitment is a value, usually a hash, that fixes or binds a cryptographic key in advance without revealing the key itself. It lets someone later prove they used a specific key by revealing it and showing it matches the earlier commitment.
Used inBRC-370- Key ID
Distinguishes one key from another within the same protocol, so an application can hold many keys for the same purpose.
Used inBRC-43BRC-100See alsoProtocol IDInvoice number- kindtyped content
A label or type identifier attached to a piece of data or a message that indicates what category it belongs to and how it should be interpreted. It lets software route or process the data differently depending on its declared category.
Used inBRC-145
L
- label
A label is a short text tag attached to an action or output to categorize it for later retrieval or filtering. Wallets and applications use labels to group related transactions, such as those belonging to a particular app or activity.
- Lagrange interpolation
A mathematical technique for reconstructing a polynomial from a set of known points on it. It is used in secret sharing schemes to recover a hidden value once enough shares, treated as points, are combined.
Used inBRC-140- leaf
A node at the bottom level of a tree data structure that holds an actual piece of data rather than pointing to other nodes. In a Merkle tree, each leaf typically represents the hash of a single transaction or data item.
Used inBRC-71- Level 2 protocol
A protocol built on top of the base Bitcoin transaction and script layer that defines additional rules, data formats, or behaviours for applications. It relies on the underlying Bitcoin network for settlement and security but adds its own semantics on top.
Used inBRC-116- lifecycle status
A value indicating the current stage of an item's existence, such as whether an output is still spendable, has been spent, or is otherwise no longer active. It lets software determine how the item should be treated without needing to inspect its full history.
Used inBRC-154- lineage validation
The process of checking that a chain of related transactions or records (their lineage) is internally consistent and correctly derived from its ancestors. It confirms that each item in the chain properly follows from, and is validly linked to, the ones before it.
Used inBRC-197- listActions
listActions is a wallet API function that returns a list of previously submitted or recorded transaction actions, along with their associated metadata. It allows an application to review the history of operations it has performed through the wallet.
- ListingDescriptor
A ListingDescriptor is a data structure that describes the details of an item or service being listed for sale or offer, such as its attributes, price, and terms. It provides the information needed for others to understand and evaluate the listing.
Used inBRC-197- listingId
A listingId is a unique identifier assigned to a specific listing, such as an item or service offered for sale. It allows that particular listing to be referenced or looked up distinctly from others.
Used inBRC-197- listOutputs
listOutputs is a wallet API function that retrieves a list of transaction outputs currently tracked by the wallet, often filtered by basket or other criteria. It gives an application visibility into spendable or reserved funds without exposing the wallet's full internal state.
- Locking scriptunlocking scriptscriptPubKey
The conditions attached to an output that say how it may be spent. The spender supplies an unlocking script that has to satisfy them.
- logical protocol ID
A logical protocol ID is a string or identifier that names a specific key derivation or encryption protocol in an abstract way, independent of how it is implemented. It lets software agree on which protocol rules to apply without depending on a fixed numeric code.
- Lookup servicels_uhrpBRC-24 lookup service
The read side of an overlay: the interface for querying the outputs it is tracking, as opposed to submitting new transactions to it.
- loopback-network permission
Loopback-network permission is authorization for software to make network requests to the loopback address, meaning the same machine it is running on, such as 127.0.0.1. This permission is distinct from general local network access because it covers only the local host rather than other devices on the network.
Used inBRC-325
M
- manifestreachability manifest
A manifest is a structured document listing the components, files, or data items that make up a larger package, along with identifying details like hashes needed to verify each item. It lets a recipient know exactly what should be present and check that nothing has been altered or omitted.
- manifest.jsonBRC-68
A JSON file that describes metadata about an application, such as its name, icons, and configuration details, so that other software can discover and understand it. In Bitcoin-related applications it is commonly used to advertise an app's identity and capabilities to wallets or platforms.
- mark
A mark is a label or flag attached to data, such as a transaction or record, to indicate a particular status or classification. Its specific meaning depends on the scheme that defines and interprets it.
Used inBRC-210- master keyringkeyringForSubjectkeyringmasterKeyring
A collection of encrypted keys held by the owner of a certificate that allows selective decryption of specific fields within that certificate. It serves as the source from which individual field revelation keys are derived and distributed to others.
Used inBRC-52- master private key
The top-level private key derived from a seed, from which all other keys in a hierarchical wallet structure are mathematically generated. Possessing the master private key allows control over every key and fund derived from it.
Used inBRC-75- Merkle pathmerkle proof
The sequence of hashes that connects one transaction to the merkle root in a block header. Following it proves the transaction was included in that block without needing the rest of the block.
- Merkle root
A single hash at the top of a tree built from every transaction in a block, stored in the block header. Any change to any transaction changes it.
Used inBRC-10BRC-74See alsoMerkle path- MessageboxBRC-33BRC-33 relayBRC-33 inbox
A messagebox is a server-side inbox where encrypted or plain messages can be dropped off for a recipient to collect later. It lets two parties exchange data such as payment or transaction information without both needing to be online at the same time.
- Metanet Login
Metanet Login is an authentication method that lets a user sign in to a website or application using a Bitcoin-derived identity key controlled by their wallet instead of a traditional username and password. It relies on cryptographic signatures to prove control of the identity without transmitting a secret to the server.
Used inBRC-137- module ID
A module ID is a unique identifier assigned to a specific software module or component so it can be referenced unambiguously by other parts of a system. It distinguishes one module's data, protocol, or logic from others operating within the same environment.
Used inBRC-111- MsgType
MsgType is a field in a message header that identifies what kind of message is being sent, so the receiver knows how to parse and handle its contents. It acts like a label distinguishing one message format from another within the same protocol.
- multicodec
A multicodec is a self-describing prefix added to binary data that indicates which encoding or data format was used, so that a reader can correctly interpret the bytes that follow. It allows different systems to share data of varying types without needing out-of-band agreement on format.
Used inBRC-202
N
- name token
A name token is a token that represents ownership or control of a specific human-readable name within a naming system. Transferring the token transfers control of the associated name to the new holder.
Used inBRC-174- nLocktime
A field in a Bitcoin transaction specifying the earliest time or block height at which the transaction may be added to the blockchain. If set to zero, the transaction can be included immediately, otherwise it is not valid until the specified time or height is reached.
- non-final transaction
A Bitcoin transaction that is not yet considered final because it uses a sequence number and locktime indicating it may still be replaced or updated before being confirmed. Such a transaction can be superseded by a later version until it becomes final and is mined.
Used inBRC-60- Non-interactive wallet
A non-interactive wallet is a wallet that operates without a human present to approve each action, instead following pre-set rules or automated logic. It is commonly used for server-side or machine-to-machine payment processes where no one is available to click confirm.
Used inBRC-219- non-linkability
A property ensuring that separate pieces of data or separate transactions cannot be proven to relate to the same person or entity. It is a privacy guarantee that observers cannot connect actions that are meant to remain unrelated.
Used inBRC-152- nonce exchange
A step in an authentication handshake where each party sends a random, single-use value called a nonce to the other. Combining and signing these nonces proves the exchange is fresh and prevents an attacker from replaying an old message.
Used inBRC-31- noSend action
A noSend action is a transaction that a wallet constructs and signs but does not broadcast to the network immediately, leaving the decision to send it for later. This lets an application prepare or chain multiple transactions before committing any of them to the blockchain.
Used inBRC-177- note
A note is a small piece of human-readable text attached to a transaction, output, or record to describe its purpose or context. It is generally intended for local reference rather than being required for transaction validation.
Used inBRC-109- notice round
A notice round is a defined phase or interval during which participants in a protocol send out notifications or announcements to each other before proceeding to the next step. It coordinates timing so that all relevant parties are informed before an action takes effect.
Used inBRC-234- nSequence
A per-input field in a Bitcoin transaction originally intended to signal that an input is not yet final and can be replaced, and now also used to encode relative timelocks. Its exact meaning depends on its value and which bits are set, but it works alongside nLocktime to control when a transaction becomes valid.
Used inBRC-67
O
- object plane
The object plane is the layer of a system that carries the actual data objects being stored or transferred, as distinct from the layer that carries control or coordination messages. It is where the substantive payload lives, separate from the signaling used to manage its movement.
Used inBRC-148- Observation
An Observation is a recorded piece of information that someone has witnessed or collected about an event, transaction, or entity. It serves as a discrete, attributable input that can later be combined with other observations to build evidence or support a conclusion.
Used inBRC-192- OP_FALSE
OP_FALSE is a Bitcoin script opcode that pushes an empty value (equivalent to zero or false) onto the script execution stack. It is often paired with OP_RETURN at the start of a data-carrying output to ensure the script cannot be executed as spendable.
- OP_RETURN
OP_RETURN is a Bitcoin script opcode that marks an output as unspendable while allowing arbitrary data to be attached after it. It is commonly used to embed metadata or application data directly on the blockchain.
- OP_TRUE
OP_TRUE is a Bitcoin script opcode that pushes a true (non-zero) value onto the script execution stack. It can be used to create a locking script that is trivially satisfied, since any script leaving a true value on the stack succeeds.
Used inBRC-19- operating statement
An operating statement is a declaration published by an entity, such as a certifier or service, that sets out the rules, policies, or conditions under which it operates. Other parties read it to understand what guarantees or obligations the entity has committed to.
Used inBRC-200- OpNSOpen Pubkey Name SystemOpen Paymail Name SystemOpen Payment Name Service
OpNS is an on-chain naming system that allows human-readable names to be registered and resolved to data such as keys or addresses using Bitcoin transactions. It functions similarly to a domain name system but relies on blockchain transactions rather than centralized registries.
Used inBRC-174- OrigFrameVer
OrigFrameVer is a field recording the frame version of the original, unfragmented message, preserved within its fragments. It lets the receiver correctly interpret the reassembled data according to the format it was originally created in.
Used inBRC-130- origin
A string identifying the application, domain, or service that requested or created a given piece of data, such as an output or a key. It lets a wallet or system record where a request came from so access and history can be traced back to its source.
- OutpointTXID + vout
A reference to one specific transaction output, written as the transaction id followed by the index of the output within it.
- Outputs Extension
An extension to a transaction request or response format that carries extra structured information about specific outputs, such as their purpose or how they should be handled. It lets applications attach metadata to outputs beyond the basic script and value fields.
Used inBRC-50- Overlay serviceoverlay networkoverlay
An index that watches the chain for the subset of transactions one application cares about, grouped under a topic. It exists because scanning the whole chain for your own data does not scale.
P
- P2PKHPay to Public Key HashPay-to-Public-Key-Hashpay-to-public-key-hash
The most common way to lock an output: it can be spent by whoever proves they hold the private key for a given public key hash. What a traditional Bitcoin address encodes.
- PacketPay
A payment mechanism that allows an HTTP request to include a micropayment so a server can charge for individual API calls or data packets. It embeds payment information directly in the HTTP exchange rather than requiring a separate payment step.
Used inBRC-41- PACT
Peer Aggregated Consensus Transfer, a protocol pattern used to coordinate agreement between peers about the state of shared data before it is finalized. It helps ensure multiple parties reach consistent conclusions about transaction or data validity.
- pairwise key
A pairwise key is a cryptographic key that is unique to a specific pair of parties, derived so that each counterparty relationship gets its own distinct key rather than reusing one key everywhere. This lets two parties compute a shared key independently while keeping the relationship unlinkable to the same parties' dealings with anyone else.
Used inBRC-182- payer/owner decoupling
Payer/owner decoupling is the separation of the party who pays for a transaction's fees from the party who owns or controls the funds or assets being transacted. This allows one entity to cover costs, such as a service sponsoring fees, while another entity retains ownership rights over the underlying value.
Used inBRC-227- payload tag
A payload tag is a short identifying value placed at the start of a data structure to indicate what kind of content follows. It allows software to quickly recognize and correctly parse the format of the data without needing to inspect the entire payload first.
Used inBRC-225- Paymail
An addressing scheme that uses a human-readable name at a domain in place of a Bitcoin address, resolving to a payment destination over HTTPS.
- payment bundle
A payment bundle is a package of data that groups together everything needed to process a payment, such as transaction details and supporting information. It allows a payment to be transmitted and verified as a single unit rather than as separate pieces.
Used inBRC-175- PaymentACK
PaymentACK is a message a payment processor sends back to a wallet to confirm that a submitted payment transaction was received and accepted. It typically includes a status and an optional memo, letting the paying party know the transaction can be considered complete from the merchant's side.
Used inBRC-54- Peer attestation
Peer attestation is a statement made by one party vouching for a fact about another party, such as their identity or reputation. It allows trust to be built between users through claims signed by other participants rather than a central authority.
Used inBRC-169- PeerServBRC-33
PeerServ is a message relay service that allows one party to deliver data or notifications to another party's identity key, enabling asynchronous communication between peers. It acts as an intermediary so that messages can be stored and retrieved even if the recipient is not online at the time of sending.
- Pending request
A pending request is an action or permission request that has been submitted but not yet approved, denied, or completed. It remains in a waiting state until the required party, often a user, responds to it.
Used inBRC-219- permission module
A component that implements the logic for a particular permission scheme, evaluating whether a requested action should be allowed. It can be plugged into a system to enforce a specific set of access rules.
Used inBRC-123- Permission-required request
A permission-required request is an action, such as signing a transaction or revealing a key, that a wallet will not carry out automatically because it needs explicit user approval first. It marks the point where software must pause and ask the user to confirm before proceeding.
Used inBRC-219- POTATOESBRC-196 settlement
POTATOES is a term used for a structured response confirming that a submitted transaction or proposal has been accepted and recorded, similar in role to a acknowledgment receipt. It tells the submitter that their submission was successfully processed.
- primer
A primer is an initial piece of data or setup information supplied before the main operation begins, used to establish shared context or starting state. It ensures that all parties or components begin a process with the same baseline information.
Used inBRC-325- private overlay
A private overlay is a restricted-access network or service layer built on top of the base Bitcoin network that only authorized participants can read from or write to. It is used to share or process additional data, such as application-specific transactions or indexes, without exposing that data publicly.
- PrivatePublicationStore
A PrivatePublicationStore is a storage component that holds published data or content in a restricted manner, making it accessible only to authorized parties rather than the general public. It manages where and how private publications are kept and retrieved.
Used inBRC-195- profile IRIprofile
A profile IRI is an Internationalized Resource Identifier that uniquely names a particular profile, such as a set of rules or conventions, so it can be referenced unambiguously. IRIs extend URIs to support a wider range of characters, including non-ASCII text.
Used inBRC-194- profileData
profileData is a structured set of fields describing identity or account information about a user, such as a name, avatar, or other attributes. It is typically published or shared so other parties can read and display that user's public profile.
Used inBRC-209- Proof of Ancestor
Evidence establishing that a particular transaction or data item is a genuine predecessor in a chain of transactions or records, linking it to a later descendant. It confirms lineage or history by showing an unbroken connection back to an earlier point.
Used inBRC-63- proof of referral
Evidence that demonstrates a particular party introduced or referred another party into a transaction or system, often used to attribute credit or rewards. It links an action or outcome back to the referring party for verification purposes.
Used inBRC-51- proof-type
A proof-type identifies the specific cryptographic method or format used to demonstrate that a claim, signature, or piece of data is valid. It tells a verifier which algorithm and structure to apply when checking the proof.
Used inBRC-97- protected action
A protected action is an operation on a wallet or token that requires explicit user permission or additional authentication before it can proceed, rather than happening automatically. This safeguards sensitive operations like spending funds or revealing private data from being triggered without the user's knowledge.
Used inBRC-177- Protocol ID
Names what a derived key is for, so keys used for one purpose cannot be reused for another. Paired with a security level that decides how much the user is asked to approve.
- protocolID
A protocolID is an identifier that specifies which key derivation or cryptographic protocol context a particular operation belongs to, such as a specific application feature or message type. It is used alongside other parameters to ensure that keys or signatures generated for one purpose cannot be reused or confused with those generated for another.
Used inBRC-56- ProtoMap
A ProtoMap is a mapping structure that associates protocol identifiers with the specific rules or handlers used to process data belonging to that protocol. It allows a system to look up the correct logic to apply based on which protocol a piece of data belongs to.
Used inBRC-184- public reveal
A public reveal is the act of disclosing information, such as a secret value, key, or commitment, openly so that anyone can see and verify it. It typically happens after that information was previously kept hidden or committed to, allowing others to confirm it matches an earlier commitment.
Used inBRC-370- Public revelationtm_identity
A Public revelation is the act of disclosing information, such as a key, proof, or fact, openly so that anyone can see and verify it. Once revealed publicly, the information can no longer be treated as secret or withheld.
- PublicationResult
A data structure returned after an attempt to publish something, such as a transaction or record, that reports whether the publication succeeded and includes relevant details like identifiers or errors. It gives the caller confirmation and information about the outcome of the publish action.
Used inBRC-195- purchaseCommitment
A data field or object representing a buyer's binding commitment to purchase a listed item, typically including the details needed to carry out or verify the transaction. It serves as evidence that a purchase has been agreed to before it is finalized on-chain.
Used inBRC-196- PushDropPay to Push DropBRC-48
A script template that pushes arbitrary data onto the stack, drops it, then applies an ordinary key lock. The result is an output that carries metadata and is still spendable, which is how these standards represent tokens.
R
- R-puzzle
An R-puzzle is a type of Bitcoin script condition that requires a signature containing a specific R-value, derived from the ECDSA signing process, in order to spend an output. It allows spending rights to be locked to a value related to a chosen k-value rather than a public key.
Used inBRC-17- reassembly slot
A reassembly slot is a temporary storage location used to hold incoming fragments of a message until all pieces have arrived and can be combined into the complete original data. Each slot tracks the fragments belonging to one specific message being reconstructed.
Used inBRC-130- reclaim transaction
A reclaim transaction is a transaction that returns funds or a token back to its original owner, typically used when a conditional or time-locked arrangement fails to complete as intended. It acts as a fallback so locked value is not lost if the main path of a protocol is not followed.
Used inBRC-177- recoveryUntil
recoveryUntil is a field or parameter specifying the point in time up until which a recovery action, such as reclaiming funds or restoring access, remains permitted. After this time passes, the associated recovery option is no longer available.
Used inBRC-195- ReleaseEvidence
ReleaseEvidence is a data record that proves a piece of locked or escrowed content was released under the agreed conditions. It typically bundles signatures, keys, or other proofs that a verifier can check to confirm the release was legitimate.
Used inBRC-196- ReleasePolicy
A ReleasePolicy is a set of rules defining the conditions under which something, such as funds, data, or access, is permitted to be released. It specifies the criteria that must be met before the release action is allowed to proceed.
Used inBRC-196- Releaser
A releaser is the party or process responsible for making a piece of protected or encrypted data available to an authorized recipient, typically by providing the key or permission needed to unlock it. It acts as the controlling entity that decides when and to whom access is granted.
Used inBRC-369- relinquishCertificate
An operation that tells a wallet to delete or stop managing a stored identity certificate, removing it from local storage. It does not revoke or invalidate the certificate itself, only the wallet's record of holding it.
Used inBRC-66- relinquishOutput
An operation that tells a wallet to stop tracking a specific transaction output as part of its managed funds, without spending it or affecting its state on the blockchain. It is used to remove an output from local wallet bookkeeping, for example when it belongs to another application or is no longer relevant.
Used inBRC-66- rendition
A rendition is a specific representation or version of a piece of data, such as a formatted or encoded output derived from an original source. It describes one particular way that underlying content or data has been expressed or displayed.
Used inBRC-188- reserved verb
A reserved verb is an action keyword that is set aside by the standard for future or internal use and must not be used for custom, application-defined purposes. Using a reserved verb outside its intended meaning can cause conflicts with future or system-level behavior.
Used inBRC-218- retry safety
Retry safety is a property of an operation meaning it can be attempted again after a failure or timeout without causing incorrect or duplicate effects. An operation with retry safety typically achieves this by being idempotent or by including checks that detect if it already succeeded.
Used inBRC-326- revealCounterpartyKeyLinkage
An operation that discloses the cryptographic relationship between a user's key and a counterparty's key that was used in a specific interaction. It allows selective proof of a connection between two parties without exposing this link by default.
Used inBRC-151- revenue quantum
A discrete, defined unit or share of revenue that is allocated or distributed, often used to split payments among multiple parties in fixed portions. It represents the smallest or standard increment by which revenue is divided.
Used inBRC-197- RevenueState
RevenueState is a data structure that tracks the current status of revenue related to an item or transaction, such as how much has been earned, collected, or is still owed. It reflects the up-to-date financial standing associated with that revenue stream.
Used inBRC-197- revocation outpoint
A specific transaction output, identified by transaction ID and output index, whose spending state is used to signal whether a certificate or agreement has been revoked. If that outpoint is spent, the associated certificate is treated as no longer valid.
- revocation output
A revocation output is a transaction output in a payment channel construction that gives one party the ability to punish the other for broadcasting an outdated channel state, typically by letting the honest party claim the funds if the revoked state is published. It acts as a penalty mechanism to keep both parties from cheating by publishing stale channel balances.
Used inBRC-204
S
- SASM
SASM is a structured or extended variant of Bitcoin script assembly notation designed to add extra formatting or metadata beyond standard ASM. It aims to make scripts easier to author, read, or parse in specific tooling contexts.
Used inBRC-14- satoshi
A satoshi is the smallest unit of bitcoin, equal to one hundred millionth of a single bitcoin. All Bitcoin transaction amounts are ultimately denominated in satoshis internally, even when displayed to users in larger units.
Used inBRC-112- satoshis
The smallest unit of bitcoin currency, where one bitcoin equals one hundred million satoshis. Amounts in Bitcoin systems are typically expressed and stored as whole numbers of satoshis to avoid floating point rounding issues.
Used inBRC-41- scene cue
A scene cue is a marker embedded in media content that signals a specific point in time, such as a transition or event, to trigger an associated action. It allows software processing the media to synchronize other behavior, like displaying data, with what is happening in the content.
Used inBRC-224- scopepermission axis
A scope is a defined boundary that limits what data, permissions, or actions a piece of code, key, or request is allowed to access. In wallet and permission systems, it restricts an operation to a specific application, domain, or purpose so it cannot affect unrelated resources.
- score
A score is a numeric value assigned to something, such as a transaction or a piece of data, to indicate its relative priority, confidence, or ranking according to some defined metric. The exact meaning of the number depends on the system that calculates it.
Used inBRC-210- script number
A script number is a numeric value encoded in the compact, variable-length format used by Bitcoin Script for arithmetic and comparison operations. It differs from ordinary fixed-width integers in that its byte length can vary and its sign is indicated by a bit in the last byte.
Used inBRC-162- script_idscript_id
A script_id is an identifier used to reference a specific script, such as a locking or unlocking script, without including its full contents. It lets systems look up or point to a particular script elsewhere rather than repeating the raw script data each time.
Used inBRC-370- secp256k1
The specific elliptic curve Bitcoin uses for its keys and signatures. Every public key in these standards is a point on it.
- Security level
How broadly a user's permission applies when an application asks to use a key: whether the approval covers the protocol generally, or is scoped to a specific counterparty.
Used inBRC-43BRC-44BRC-98BRC-116See alsoProtocol IDWallet interface- seed
A piece of random data used as the starting input for generating a hierarchy of cryptographic keys. Anyone with the seed can regenerate the same keys, so it must be kept secret and backed up securely.
Used inBRC-75- selective disclosure
Selective disclosure is the practice of revealing only specific pieces of information needed for a given purpose, while withholding the rest. It allows a party to prove or share certain facts, such as attributes from an identity credential, without exposing unrelated or unnecessary data.
Used inBRC-191- selective field revelation
Selective field revelation is the ability to disclose only specific pieces of information from a larger data set, such as a certificate, while keeping the rest hidden. This lets a holder prove particular facts to a verifier without exposing unrelated private data.
Used inBRC-108- self-child derivation
Self-child derivation is a method of generating a new key directly from an existing key using that same key as both the source and reference point, without requiring an external parent. This allows a single key to produce its own derived descendant keys in a consistent, repeatable way.
Used inBRC-208- senderIdentityKey
The long-term public key that identifies the party who sent a particular message or payment. It allows the recipient to verify who originated the communication, as distinct from any temporary keys used just for that exchange.
Used inBRC-228- SeqNum
SeqNum, short for sequence number, is a numeric field used to order or identify items within a series, such as messages or overlay network updates. Recipients use it to detect missing, duplicate, or out-of-order data.
- SHIPBRC-88
SHIP stands for Service Host Interconnect Protocol, a protocol used to advertise which topics a given overlay node hosts. It allows nodes in an overlay network to discover peers that carry the topic data they need.
- SHIP and SLAPSHIPSLAP
Advertisements that let overlay nodes find each other: SHIP, Service Host Interconnect, announces which topics a host tracks, and SLAP, Service Lookup Availability, announces which lookup services it offers.
Used inBRC-23BRC-25BRC-101BRC-194See alsoOverlay serviceLookup service- signed range
A signed range is a contiguous span of values, such as block heights or sequence numbers, over which a signature or proof is declared to be valid. It tells a verifier the boundaries within which a given signed statement applies.
Used inBRC-217- SLAP
SLAP stands for Service Lookup Availability Protocol, a protocol used to advertise which lookup services are available across overlay nodes. It is closely related to CLAP and helps clients locate nodes offering a needed lookup capability.
- SlotSpan
A SlotSpan is a defined range of time slots that a process or allocation covers, marking a start point and an end point within a slotted timeline. It is used to describe how long, in terms of discrete slots, something remains valid or active.
Used inBRC-148- specific key linkage
Specific key linkage is the association of a particular cryptographic key with a single identified purpose, counterparty, or context rather than being reused broadly. This limits how far a key can be correlated across unrelated interactions, improving privacy.
Used inBRC-97- SPVSimplified Payment Verification
Checking that a transaction is in a block by verifying a merkle proof against block headers, instead of downloading and validating the whole chain. It is what lets a wallet on a phone accept a payment.
- SPV envelopespv
An SPV envelope is a data package that bundles a transaction together with the Merkle proof and block header information needed to verify it using Simplified Payment Verification (SPV), without requiring the full blockchain. It allows a recipient to independently confirm a transaction is included in a valid block.
Used inBRC-220- Square-root weights
Square-root weights refer to a weighting scheme where a participant's influence or probability of selection is proportional to the square root of some underlying quantity, such as stake or resource amount, rather than the quantity itself. This dampens the advantage of participants with very large amounts of that quantity compared to linear weighting.
Used inBRC-178- STAS output
A STAS output is a transaction output formatted according to the STAS (Simple Token and Asset Scheme) token protocol, which represents ownership of a token on top of Bitcoin using standard-looking outputs enforced by locking script rules. It allows tokens to be transferred, split, or merged while staying compatible with normal Bitcoin transaction structures.
Used inBRC-54- state token
A state token is a token, typically represented as a blockchain output, that encodes the current state of an ongoing process or contract. Updating the state is done by spending the existing state token and creating a new one carrying the updated data.
Used inBRC-222- STEAK
STEAK is a term used for a structured response format that confirms the outcome of a submitted transaction, including which inputs were accepted. It communicates back to the submitter the status of their transaction after processing.
- step certificate
A step certificate is a signed attestation confirming that a particular stage of a multi-stage process was completed correctly. It allows later steps or other parties to verify that earlier steps were performed as expected without redoing the verification work themselves.
Used inBRC-222- Step Digest
A Step Digest is a cryptographic summary representing a single step within a multi-step process, such as a workflow or protocol exchange. It allows each stage of the process to be verified independently without needing to review the full history leading up to it.
Used inBRC-222- Strict Overlay
A Strict Overlay is a type of overlay network service that enforces its topic's admittance rules exactly as defined, only accepting and forwarding transactions or data that strictly satisfy those rules. This makes its behavior fully predictable and verifiable by anyone inspecting the rule set.
Used inBRC-183- Subhandle
A subhandle is a handle that is created and managed under a parent handle, similar to how a subdomain sits under a main domain name. It allows the owner of the parent handle to delegate distinct identities or namespaces beneath it.
Used inBRC-169- Subject BEEF
A BEEF (Background Evaluation Extended Format) transaction bundle that is built around a specific transaction of interest, called the subject, along with the ancestor transactions needed to verify it. It lets a recipient validate the subject transaction's inputs without needing a separate blockchain lookup.
- submission record
A submission record is a stored entry that documents the details of something submitted into a system, such as when and by whom it was sent. It serves as evidence and a reference point for tracking that particular submission over time.
Used inBRC-149- Substrate
The transport an application uses to reach a wallet on the same device, such as HTTP to a local port or a browser window message. The calls are the same whichever is used.
- subtree
A subtree is a smaller grouping of transactions organized as its own partial Merkle tree, used so large blocks can be built, transmitted, and verified in manageable pieces rather than as one enormous structure. Combining the roots of all subtrees produces the final Merkle root for the block.
- SubtreeGroupAnnounce
A message that announces the existence or availability of a group of Merkle subtrees to other participants in a network. It allows recipients to become aware of new subtree groups without needing to discover them independently.
Used inBRC-127- SubtreeID
A unique identifier for a Merkle subtree, allowing it to be referenced distinctly from other subtrees. It is typically derived from the subtree's contents, such as a hash of its root.
- Successor block
A successor block is the block that follows immediately after a given block in a blockchain, extending the chain by one step. It references the prior block, forming the ongoing sequence of the chain.
Used inBRC-139- sweep
A sweep is the act of collecting funds from one or more outputs, often ones that have just become spendable, and moving them into a new transaction, usually to consolidate them or move them to a safer address. In payment channel and wallet contexts, sweeping often refers to claiming funds after a timelock expires or a dispute resolves.
Used inBRC-204
T
- tagQueryMode
A setting that controls whether a search for tagged outputs must match all of the given tags or just any one of them. It determines the logical combination (AND versus OR) applied when filtering outputs by their tags.
Used inBRC-164- tamper fingerprintFP_SUFFIX
A derived value, usually a hash, that represents the exact state of a piece of data at a point in time. Comparing it later reveals whether that data has been modified since the fingerprint was taken.
Used inBRC-145- targetType
targetType is a field used to specify what kind of value a Merkle proof target refers to, such as a block hash, block header, or merkle root. It tells software how to interpret the accompanying target data when verifying a proof.
Used inBRC-11- thresholdt
The minimum number of shares or signatures required to reconstruct a secret or authorize an action in a scheme where the total is split among multiple parties. For example, a threshold of three out of five means any three of the five shares are enough to recover the secret.
- THROTTLED
Throttled describes a state where a node or connection has had its data rate deliberately limited, usually to avoid overwhelming a peer or network link. A throttled sender must slow down or pause transmission until conditions allow full speed again.
Used inBRC-126- tip
The most recent, highest known block in a blockchain at a given moment. It represents the current end of the chain that new blocks are added to.
- tombstone
A tombstone is a marker left in place of data that has been deleted or revoked, indicating that something existed there but is no longer valid or available. It lets other parties detect that the item was intentionally removed rather than simply missing.
- Topic
The label an overlay tracks outputs under. Submitting a transaction to a topic returns which of its outputs that overlay admitted and which earlier outputs it retained.
Used inBRC-22BRC-23BRC-87See alsoOverlay serviceLookup service- Topic ManagerBRC-22 topic manager
A Topic Manager is a component that decides which outputs from a transaction are relevant to a particular topic and should be admitted for tracking. It applies custom rules to filter and validate transaction outputs before they are passed on to a lookup service for indexing.
- TopicID
A TopicID is a unique identifier assigned to a specific topic, which is a named category or channel used to group related messages or data. It lets participants reference or subscribe to that particular topic without ambiguity.
Used inBRC-149- totalOutputs
totalOutputs is a field or value representing the total count of transaction outputs returned or available in a given query result. It helps a caller understand the overall size of a result set, especially when results are paginated.
Used inBRC-112- Transaction envelope
An earlier format for sending a transaction together with the input transactions and merkle proofs a recipient needs to verify it. BEEF is the format that replaced it.
- TTL
TTL, or Time To Live, is a value attached to a packet or message that limits how long it may exist or how many times it may be forwarded before being discarded. It is commonly used to prevent data from circulating indefinitely on a network.
Used inBRC-127- Tuple
An ordered, fixed-length list of values grouped together as a single unit. In data structures used by these standards, a tuple often pairs a key with its value or bundles several related fields together.
Used inBRC-35- TXID+VOUT
A combination of a transaction's unique identifying hash and the index number of one of its outputs, together pointing to a single specific output on the blockchain. This pairing is commonly used to reference an exact unspent output that can be spent as an input in a new transaction.
Used inBRC-76
U
- UHRPUniversal Hash Resolution Protocol
A way to find a file by its hash rather than by a URL, with hosts advertising on an overlay that they are holding it. Content survives any one host going offline.
Used inBRC-26See alsoOverlay service
V
- value-moving action
A value-moving action is an operation that transfers monetary value, such as bitcoin, from one party or output to another. It is distinguished from actions that only record information or metadata without changing ownership of value.
Used inBRC-218- vault masterwallet root secret
A vault master is a top-level key or authority from which other keys or permissions within a secure storage system, or vault, are derived. It represents the highest level of control over the vault's contents and derived key material.
- verdict
A verdict is the outcome of an evaluation process, stating whether a piece of data, transaction, or claim was accepted or rejected against defined rules. It typically includes enough detail to explain the basis for the decision.
Used inBRC-190- Verification event
A Verification event is a recorded occurrence of someone checking the validity of a credential, signature, or claim, typically including details like when the check happened and what the result was. It creates an auditable trail showing that verification took place.
Used inBRC-201- verification method
A verification method is an entry in a DID document that describes a specific cryptographic key or mechanism that can be used to verify signatures or other proofs made by the DID's controller. It includes details such as the key type and the actual public key value.
Used inBRC-202- VerificationContext
A VerificationContext is the set of information and parameters supplied to a verification process so it can correctly check whether something, such as a signature or proof, is valid. It typically includes details like the expected signer, the relevant data being checked, and any rules or state needed to perform the check.
Used inBRC-192- verifiedDocument
A verifiedDocument is a document, such as a DID document, whose authenticity and integrity have been checked and confirmed through a verification process like a cryptographic signature check. It represents data that a system has established can be trusted as genuine and unaltered.
Used inBRC-203- view grant
A view grant is a permission that allows a specific party to read or decrypt protected data without giving them the ability to modify it or grant access to others. It is typically issued by whoever controls the underlying content or encryption keys.
Used inBRC-165- vouch gate
A vouch gate is a checkpoint that requires an attestation or endorsement from a trusted party before allowing something to proceed. It functions as a permission step based on someone vouching for the validity or legitimacy of the item being checked.
Used inBRC-190- voucher
A voucher is a digitally issued token or certificate that represents a right, such as a claim to funds, a discount, or access to a service, which can be redeemed later. It typically carries proof of its issuance so the redeemer can verify it is genuine.
Used inBRC-227
W
- walk-back
A walk-back is the process of tracing a chain of records or references backward from a given point to an earlier one, typically to verify history or lineage. It is used to confirm that a current state can be validly derived from a known prior state by following the chain in reverse.
Used inBRC-175- wallet catalog endpoint
A wallet catalog endpoint is a network address, usually a URL, that a wallet application exposes so that other software can query it for a list of supported capabilities, apps, or services. It acts as a discovery point for what a given wallet is able to do.
Used inBRC-137- wallet firewall
A boundary or set of controls that prevents information, such as keys or transaction data, from flowing freely between different wallets or identity contexts. It is designed to stop unwanted linkage between separate financial or identity domains.
Used inBRC-152- Wallet interfaceBRC-100 interfacewallet-to-application interface
The vendor-neutral set of calls an application uses to ask a wallet to do things: build transactions, derive keys, encrypt data, sign messages, prove identity. Defined by BRC-100.
- Wallet Toolbox
A software library providing reusable components and functions for building Bitcoin wallets, covering tasks like key management, transaction construction, and storage. It lets developers implement wallet functionality without writing these lower-level pieces from scratch.
Used inBRC-38- work
Work refers to the computational effort, typically repeated hashing, that must be expended to produce a result meeting a required difficulty target. It is the basis of proof of work, where the amount of work done can be verified cheaply even though producing it was costly.
Used inBRC-210
X
- x-bsv-overlay-capability header
The x-bsv-overlay-capability header is an HTTP header used to declare or request specific capabilities supported by an overlay network service. It allows clients and servers to communicate which optional features or behaviors are available during a request.
Used inBRC-194- x-bsv-payment header
The x-bsv-payment header is a custom HTTP header used to carry payment information, such as a transaction or payment reference, alongside an HTTP request. It allows a client to attach proof of payment directly to an API call so a server can verify payment before fulfilling the request.
Used inBRC-105
SocialCert is a certificate type used to attest that a given identity key is linked to a specific social media account or profile. It allows an identity to prove ownership of a social media presence by having that association certified and signed by a certifier.