Beersy

172 terms

Glossary

A

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
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.

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
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
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.

Atomic BEEF

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.

Used inBRC-95See alsoBEEF
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

Basketoutput basketbasket ID

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.

BEEFBackground Evaluation Extended Format

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.

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
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-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
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

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 bytes

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.

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
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
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
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.

Used inBRC-107
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
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
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.

Controller

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.

Used inBRC-35
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.

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
customInstructions

A free-form field where a wallet or service can attach extra, application-specific guidance or metadata alongside a request or output. Its contents are not standardized and are interpreted only by the specific application that defined them.

D

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
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.

Used inBRC-68
derivation prefix

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.

Used inBRC-29
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.

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.

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
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.

Used inBRC-122
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
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

field revelation key

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
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
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

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
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
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
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
GroupBlockBroadcast0xFFFE

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

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.

Used inBRC-169
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-146

I

identity certificateBRC-52 certificate

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.

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 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 code

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 number

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.

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 ID

Distinguishes one key from another within the same protocol, so an application can hold many keys for the same purpose.

kind

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.

Used inBRC-65
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
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.

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.

Used inBRC-112
Locking scriptunlocking script

The conditions attached to an output that say how it may be spent. The spender supplies an unlocking script that has to satisfy them.

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.

M

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.

Used inBRC-146
manifest.json

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.

master keyring

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.

Messagebox

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.

Used inBRC-169
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

N

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.

Used inBRC-67
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
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
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
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
Outpoint

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 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.

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.

Used inBRC-73
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.

Used inBRC-28BRC-70See alsoP2PKH
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
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
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
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.

PushDropPay to Push Drop

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
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
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
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
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.

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
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
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.

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 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
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.

Used inBRC-142
shard-index domain selector

A shard-index domain selector is a value or function used to decide which shard, or partition of a larger dataset, a particular item belongs to. It maps an item into a numeric or categorical index that identifies its assigned shard within the overall domain of shards.

Used inBRC-148
ShardBits

ShardBits is a field that encodes how many shards, or partitions, a dataset or network topic has been divided into. It is used together with a shard index so a node can determine which portion of the data it is responsible for.

Used inBRC-142
SHIP

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.

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
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 envelope

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
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
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.

T

tamper fingerprint

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
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.

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.

Used inBRC-8BRC-9See alsoBEEFSPV
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
UTXOunspent transaction output

An output of a past transaction that has not yet been spent. A wallet's balance is the sum of the UTXOs it can unlock, and several standards here treat a UTXO as a token rather than as loose change.

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
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-146
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-146
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

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

X

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
Was this helpful?

Search Beersy

Search standards by number, title, author or topic