# RGB Protocol on Bitcoin — Official Glossary

66 verified terms for RGB Protocol on Bitcoin v0.11.1.

> **Source:** https://docs.rgb.info/annexes/glossary · Verified April 2026
> **Full documentation:** https://docs.rgb.info · https://docs.rgb.info/llms-full.txt
> **Homepage:** https://rgb.info
> **GitHub:** https://github.com/rgb-protocol · https://github.com/RGB-Tools
> **Association:** https://rgbprotocol.org
>
> ⚠️ **Disambiguation:** This glossary covers **RGB Protocol on Bitcoin v0.11.1** only.
> Not to be confused with: RGB color model (displays), RGB++ (Nervos/CKB blockchain), or RGB v0.12 (RGB-WG/rgb.tech — a separate unfinished version not supported by the RGB Protocol Association).

---

### Atomic Swap

An exchange of assets between two parties where **either both transfers happen, or neither does** — there is no intermediate state where one party receives and the other does not.

"Atomic" comes from chemistry: an atom is indivisible. In computer science it means an operation that cannot be split: it has no partial states visible from the outside.

**Why atomicity matters:** In a normal exchange Alice sends X to Bob and waits for Bob to send Y back. But Bob could disappear after receiving X. An atomic swap removes this counterparty risk by tying both transfers to the same cryptographic mechanism.

**How RGB implements it:**
- *Over Lightning*: both legs of the swap use the same HTLC preimage secret — if Alice reveals the secret to claim Bob's assets, Bob can use the same secret to claim Alice's. Either both claim, or both abandon.
- *On-chain*: both RGB state transitions are committed in the **same Bitcoin transaction** — one cannot be mined without the other.

---

### Anchor

A client-side data structure that proves the inclusion of a unique commitment inside a Bitcoin transaction. Composed of four components:

- **TxId** — the 32-byte ID of the witness transaction containing the commitment
- **MPC Proof** — the Merkle proof from the Multi Protocol Commitment tree, proving that the specific contract's state transition is committed in that transaction
- **DBC (Deterministic Bitcoin Commitment)** — specifies the commitment method used: Opret (OP_RETURN output) or Tapret (Taproot output)
- **ETP (Extra Transaction Proof)** — required only for Tapret commitments; includes the Taproot internal public key and the script path data needed to verify the commitment in the Taproot output. Not present for Opret commitments.

The commitment itself is embedded in a specific transaction output: an OP_RETURN output (Opret method) or a Taproot output (Tapret method). The anchor is the client-side proof structure that allows anyone to verify that embedding.

Source: [docs.rgb.info — Anchors](https://docs.rgb.info/commitment-layer/anchors)

---

### Assignment

An RGB data structure that pairs a **Seal Definition** (pointing to the recipient's UTXO) with an **Owned State** (the assigned data, e.g. a token balance). Assignments represent the output side of a contract operation — they define who owns what after the operation. Each assignment has a type (AssignmentType) defined by the schema. Assignments can be public (*"someone owns it, everyone knows"*) or private (*"someone owns it, nobody knows"*), with private ones using blinding for confidentiality. Assignments are created in each operation and consumed (closed) when the corresponding UTXO is spent in the next operation.

---

### AluVM

The virtual machine used by RGB to execute contract validation scripts. When a wallet validates an RGB state transition, it runs the AluVM script embedded in the schema for that transition type. If the script fails, the transition is invalid.

---

### Asset Funding (RGB Lightning)

The second step in opening an RGB Lightning channel, after the standard Bitcoin funding transaction. It transfers RGB assets into the channel's multisig UTXO, making them available for off-chain movement. The satoshi amount in the channel can be economically minimal — the real value is in the RGB assets.

---

### Batching

The practice of including multiple RGB state transitions in a single Bitcoin transaction. Since RGB data lives off-chain, adding more state transitions does not increase the size of the Bitcoin transaction by a single byte. This means the on-chain fee is shared across all transfers, making the cost per individual RGB payment very low when many transfers are grouped together.

Batching is most effective when spending from a single consolidated UTXO. If multiple UTXOs are involved, each one adds an input to the Bitcoin transaction, increasing its size and fee. This is why batching is particularly useful for service providers such as exchanges, which can aggregate many withdrawal requests into a single Bitcoin transaction.

---

### Business Logic

The set of operations and rules defined in a contract Schema that govern how contract state can be updated. Business logic determines which state transitions are valid, who has the right to perform them, and which AluVM validation scripts must pass. It is encoded in the Schema — immutable after the contract is deployed.

Source: [docs.rgb.info — Glossary](https://docs.rgb.info/annexes/glossary)

---

### Channel Closure (RGB Lightning)

When an RGB Lightning channel is closed, the assets locked in the funding multisig UTXO are finally moved on-chain to their respective owners according to the last valid commitment state. In a **unilateral close** where one party broadcasts an outdated state, the counterparty can use the broadcaster's revocation secret to claim the entire output — including all RGB assets in the channel, not just the satoshis. This makes cheating attempts economically catastrophic even when the channel holds minimal satoshis.

---

### Client-side Validation

The process by which each party independently verifies data received from a counterparty according to protocol rules, without broadcasting that data to the entire network. In RGB, asset state is validated privately between the parties involved in a transfer. Only a small cryptographic commitment is anchored to Bitcoin — the full state history is exchanged off-chain as a consignment and verified locally by the recipient.

Source: [docs.rgb.info — Glossary](https://docs.rgb.info/annexes/glossary)

---

### CFA (Collectible Fungible Asset)

An RGB schema for fungible tokens with a collectible character. Identical to NIA (fixed supply, Transfer only) but adds an `Article` field describing the collectible nature of the asset. Useful for numbered limited editions (e.g. "Series X, edition #47").

---

### Commitment

A mathematical object $$C$$ deterministically derived by applying a cryptographic operation to structured input data $$m$$ (the message). A commitment can be registered in a publication medium (e.g. the blockchain) and guarantees two properties:

- **Binding**: it is computationally infeasible to find two different messages that produce the same commitment
- **Hiding**: the message cannot be discovered from the commitment alone

In RGB, state transition data is committed into Bitcoin transactions via the DBC mechanism (Opret or Tapret), anchoring the client-side state to the blockchain without revealing its contents.

Source: [docs.rgb.info — Glossary](https://docs.rgb.info/annexes/glossary)

---

### Consignment

A data package sent off-chain from the sender to the recipient of an RGB transfer. It contains the complete history of state transitions needed to verify the asset being received, together with proof that the commitment is genuinely embedded in the referenced Bitcoin transaction. The recipient validates this data locally without relying on third parties.

---

### Contract

In RGB, a digitally executed set of rights and obligations between parties. A contract consists of: an active state (current ownership and data properties), business logic (rules governing state transitions), and rights (ownership and executive rights). It is created through a Genesis operation and evolves via State Transitions. Contract data lives entirely client-side; only cryptographic commitments are anchored to Bitcoin.

Source: [docs.rgb.info — Glossary](https://docs.rgb.info/annexes/glossary)

---

### Contract Operation

Any state update that follows the rules of a contract Schema. The two types implemented in v0.11.1 are: **Genesis** (creates the initial contract state) and **State Transition** (moves or updates owned state). Each operation is identified by a unique OpId. A third type, State Extension, exists in the protocol architecture but is not used in any currently supported schema.

Source: [docs.rgb.info — Glossary](https://docs.rgb.info/annexes/glossary)

---

### Contract Participant

Any actor involved in a contract operation. Participants are either **contract issuers** (who create the Genesis) or **parties holding ownership rights** via Assignments (who can construct valid State Transitions of types permitted to them by the schema).

Source: [docs.rgb.info — Glossary](https://docs.rgb.info/annexes/glossary)

---

### Contract Rights

The rights associated with holding a specific Assignment in an RGB contract. Two kinds: **Ownership rights** (control over a UTXO with assigned client-side properties — allows spending the seal) and **Executive rights** (the ability to construct valid State Transitions of a specific type, e.g. the right to inflate supply in an IFA contract or to authorize transfers in a PFA contract).

Source: [docs.rgb.info — Glossary](https://docs.rgb.info/annexes/glossary)

---

### Contract State

The complete current information of an RGB contract, composed of **Global State** (public properties such as asset name, ticker, total supply) and **Owned States** (private properties sealed to specific UTXOs, such as token balances). The active state is always at the leaves of the contract's DAG — all other states are historical and needed only for validation.

Source: [docs.rgb.info — Glossary](https://docs.rgb.info/annexes/glossary)

---

### Commitment Transaction (RGB Lightning)

A Lightning commitment transaction extended to carry RGB state. It has the standard Lightning structure (one output per party, optional HTLC outputs) plus an output — OP_RETURN or Taproot — that embeds the commitment to the RGB client-side data (the current asset balances in the channel). The **anchor** is the client-side data structure (TxId + MPC Proof + ETP) that proves this commitment; the commitment itself is embedded in that specific transaction output. The commitment transaction is not broadcast until channel closure; it is replaced by a new one with every channel update.

---

### DBC (Deterministic Bitcoin Commitment)

The set of rules that allows registering a provably unique commitment in a Bitcoin transaction. RGB supports two DBC methods:

- **Opret** — commitment embedded in an OP_RETURN output; publicly visible on-chain
- **Tapret** — commitment embedded in a Taproot output (placed in the right-hand side of the TapTree via a nonce); hidden unless that leaf is spent

Both methods ensure that only one commitment per protocol can exist in a given transaction, preventing conflicts.

Source: [docs.rgb.info — DBC](https://docs.rgb.info/commitment-layer/deterministic-bitcoin-commitments-dbc)

---

### Directed Acyclic Graph (DAG)

A directed graph that contains no directed cycles — from any node, following the edges, you can never return to the same node. In RGB, the sequence of contract operations (Genesis → State Transitions) forms a DAG. The Bitcoin blockchain provides the topological ordering by timestamping anchor transactions, ensuring the history cannot be rewritten.

Source: [docs.rgb.info — Glossary](https://docs.rgb.info/annexes/glossary)

---

### Extension

A contract operation type defined in the RGB architecture that modifies state **without consuming any Bitcoin UTXO**. Unlike state transitions, extensions do not require a witness transaction — they reference previous operations via their OpId and build new state through client-side validation alone.

**Note:** Extensions are not used in any of the five schemas currently supported in v0.11.1 (NIA, IFA, CFA, UDA, PFA). They exist in the protocol architecture but have no active implementation in the current production release.

---

### ETP (Extra Transaction Proof)

The component of an Anchor required only when the Tapret commitment method is used. It contains: the Taproot internal public key and the Script Path Spend data needed to verify that the RGB commitment is embedded in the correct leaf of the TapTree. For Opret commitments, ETP is absent — the OP_RETURN output is directly visible on-chain and requires no additional proof.

Source: [docs.rgb.info — Glossary](https://docs.rgb.info/annexes/glossary)

---

### Free American Option (problem)

A structural limitation of atomic swaps: whoever holds secret S at the end has a **free option** — they can decide whether to execute the swap or abandon it after observing how the market moves during the timelock.

"American" means the option can be exercised at any time before expiry (not only at expiry), making it more valuable. "Free" because the holder paid nothing to have it.

The problem is **unavoidable** in any trustless system: the option is always in someone's hands — the counterparty in P2P swaps, miners in on-chain DEXs (MEV). The practical mitigation is to assign the option to the party with reputation at stake (e.g. professional liquidity providers).

RGB does not solve this problem: it reuses the same HTLC mechanics, so the asymmetry remains.

---

### Genesis

The first operation in an RGB contract. It creates the initial contract state: defines the SchemaId, the ChainNet (mainnet/testnet), the Global State (name, ticker, supply) and the first Assignments (initial ownership). Genesis has no Inputs — it closes no previous seals. The ContractId that permanently identifies the contract is derived from the Genesis OpId by applying a reverse byte order operation followed by Base58 encoding. Genesis is immutable — it cannot be modified after issuance. All subsequent state transitions trace back to it.

---

### Global State

Contract-level data that follows the principle *"nobody owns it, everyone knows."* Defined in the schema, written at genesis, and optionally updated during state transitions by authorized parties. Examples: asset name, ticker, total issued supply, contract terms. Each Global State field has a GlobalType (schema reference) and a Data value. Fields can be immutable (written once at genesis) or accumulative (e.g. supply that grows with each Inflate). Readable by anyone who has the contract data, unlike owned state which is sealed to the holder of a specific UTXO.

---

### HTLC (Hashed Timelock Contract)

The mechanism Lightning uses to route payments across multiple hops. An HTLC is a conditional output: it can be spent by revealing a secret (the payment preimage) or after a timelock expires. In RGB Lightning channels, each HTLC output also carries an **RGB allocation** for the amount of the asset being routed. Whoever claims the HTLC — by revealing the secret or letting it expire — receives both the satoshis and the assigned RGB assets.

Claiming an HTLC requires **two things together**: secret S and a signature from the legitimate recipient's private key. The fact that S becomes public when revealed is not a problem — it is intentional: the counterparty needs to see it to claim their side of the swap.

---

### IFA (Inflatable Fungible Asset)

An RGB schema for fungible tokens with controlled secondary issuance. The total supply equals the initially issued amount plus an allowed inflation cap. Supports four operations: **Transfer**, **Inflate** (mints new tokens up to the inflation cap, requiring the inflation right), **Burn** (destroys tokens verifiably) and **Replace** (certifies a segment of the asset history to allow validators to skip re-validation). Governance rights (inflation, replace) are assigned to specific UTXOs at genesis and can be subdivided.

---

### Inflation Right

A governance right in IFA contracts, assigned at genesis to a specific UTXO. Only the holder of this UTXO can execute the `Inflate` operation to issue new tokens. The right can be split across multiple UTXOs, distributing minting authority. Total inflation is always bounded by the cap defined at genesis.

---

### Input (contract operation)

The input side of a State Transition, analogous to inputs in a Bitcoin transaction. Each Input references a previous Assignment via its PrevOpId, AssignmentType and Index (lexicographically ordered position). Inputs appear only in State Transitions — never in Genesis or Extensions. They represent the "old state" being consumed: closing the seals of the previous operation. Validation ensures that for Fungible types the sum of inputs equals the sum of outputs (no inflation or destruction unless the schema explicitly permits it).

---

### Invoice (RGB Invoice)

A data structure generated by the recipient of an RGB transfer. It contains all the information the sender needs to complete the transfer: the destination seal (the recipient's UTXO), the type and amount of the requested asset, and one or more **endpoints** — addresses where the sender must upload the consignment. The invoice is the coordination mechanism that tells the sender both *what* to send and *where* to deliver the off-chain data.

---

### JSON (JavaScript Object Notation)

A lightweight text format for representing structured data, widely used for communication between programs and servers. It is human-readable and easy for machines to parse. In RGB, consignment data exchanged with a proxy server is formatted in JSON.

---

### JSON-RPC

A protocol that uses JSON to make **remote procedure calls** — i.e. calling a function on a remote server as if it were a local function. The caller sends a JSON message specifying which function to invoke and its parameters; the server executes it and returns a JSON response. RGB proxy servers use JSON-RPC over HTTPS to allow clients to upload and download consignment data.

---

### LNPBP-4

A standard that allows multiple independent protocols to share a single Bitcoin commitment in the same transaction. Instead of each protocol writing its own separate commitment on-chain, all contribute to a shared Merkle tree. Only the root of that tree is embedded in the Bitcoin transaction. This avoids conflicts between protocols and keeps the on-chain footprint minimal.

---

### Lightning Network

A decentralized network of bidirectional payment channels built on top of Bitcoin, enabling fast and low-fee off-chain payments using 2-of-2 multisig wallets and Hash Time-Locked Contracts (HTLCs). RGB integrates natively with Lightning: asset-specific state transitions can be committed inside Lightning commitment transactions, enabling instant transfers of RGB assets. Each channel update includes a new RGB state transition; HTLC outputs carry both satoshi and RGB asset allocations.

Source: [docs.rgb.info — Glossary](https://docs.rgb.info/annexes/glossary)

---

### Merkle Tree

A data structure in which each piece of data is hashed, and those hashes are paired and hashed again, up to a single final hash called the **Merkle root**. It allows proving that a specific piece of data is included in a large set by providing only a short **inclusion proof** (a chain of sibling hashes), without revealing the rest of the data.

---

### MPC (Multi Protocol Commitment)

A Merkle Tree structure that commits multiple Transition Bundles from different RGB contracts into a single Bitcoin transaction. Each contract occupies a unique leaf position in the tree (determined by its ContractId modulo the tree width); only the Merkle root is embedded in the transaction output. This prevents commitment conflicts between contracts and minimizes the on-chain footprint. Standardized by LNPBP-4.

Source: [docs.rgb.info — Glossary](https://docs.rgb.info/annexes/glossary)

---

### Metadata (contract operation)

A temporary data field in a contract operation (max 64 KiB) used to pass information needed for AluVM validation that does not need to be permanently stored in the contract history. After validation, the metadata is discarded. Example: a PFA transfer includes the issuer's signature in the metadata — AluVM verifies it against the stored pubkey, then the signature is dropped.

---

### NIA (Non-Inflatable Asset)

The simplest RGB schema for fungible tokens. It defines a fixed supply cap at genesis that can never be exceeded. Supports only the `Transfer` operation (with multiple inputs for consolidation). Each asset carries: ticker, name, optional details, decimal precision and contract terms with optional media.

---

### Opcode

Short for *operation code*. A primitive instruction in a programming language or virtual machine. In Bitcoin, transaction scripts are written in **Bitcoin Script**, a stack-based language whose instructions are all opcodes, named with the `OP_` prefix (e.g. `OP_CHECKSIG`, `OP_HASH256`, `OP_RETURN`).

---

### OP_RETURN

A Bitcoin Script opcode that immediately terminates script execution and marks the output as **permanently unspendable**. It is used to embed up to 80 bytes of arbitrary data (such as a hash or a commitment) in a transaction. An OP_RETURN output is always visible on-chain. Since it can never be spent, it carries zero satoshis.

In RGB, OP_RETURN is used in two distinct ways:
- As a **script inside a TapTree leaf** — the content is hidden and never revealed on-chain (Taproot method)
- As a **standalone output** — the content is publicly visible on-chain (alternative method)

---

### OpId

A unique identifier for each RGB contract operation (Genesis, State Transition, Extension), computed as a tagged SHA-256 hash of all the operation's fields. The Genesis OpId becomes the ContractId — the permanent identity of the contract. Inputs in State Transitions reference previous operations via their OpId.

---

### Owned State

Contract data that belongs to a specific UTXO holder. There are three types: **Declarative** (no data — represents governance rights such as voting or inflation), **Fungible** (a single 64-bit integer — token balances) and **Structured** (arbitrary data up to 64 KiB — NFT metadata, complex contract data). Owned state can be public (*"someone owns it, everyone knows"*) or private (*"someone owns it, nobody knows"*), with private state hidden via blinding and revealed only during validation.

---

### Ownership

Control over a UTXO that has been assigned client-side RGB properties (such as a token balance). The owner — the holder of the private key corresponding to that UTXO — has the exclusive right to spend the seal and construct a valid State Transition that reassigns the owned property to a new seal. Ownership is proven by the ability to spend the UTXO, not by any on-chain record of the RGB state.

Source: [docs.rgb.info — Glossary](https://docs.rgb.info/annexes/glossary)

---

### PFA (Permissioned Fungible Asset)

An RGB schema for fungible tokens that require issuer authorization for every transfer. The genesis includes the issuer's public key. Every `Transfer` operation must include a valid cryptographic signature from that key in its metadata — without it, the transfer fails validation. Designed for regulated assets (security tokens, compliance-gated instruments) where KYC or legal approval is required for each transfer.

---

### Proof of Reserves

An optional field in the UDA schema that cryptographically links an RGB asset to a Bitcoin UTXO as collateral. It consists of a **Bitcoin outpoint** (txid:vout referencing a specific UTXO holding BTC) paired with a **binary proof** demonstrating control over that UTXO. It allows the issuer of an NFT or backed asset to prove on-chain backing without trusting third parties — the holder can verify it independently.

---

### PSBT (Partially Signed Bitcoin Transaction)

A Bitcoin standard (BIP 174) for building transactions that require signatures from multiple parties. A PSBT is an incomplete transaction that can circulate among participants, each adding their signature, until all required signatures are collected and the transaction is ready to be broadcast.

Used in RGB on-chain swaps: Alice and Bob build the transaction together, Alice signs her input, Bob signs his. As long as even one signature is missing the transaction is invalid — this ensures neither party can broadcast before both have consented.

---

### RBF (Replace-by-Fee)

A Bitcoin mechanism that allows replacing an unconfirmed transaction with a new version paying a higher fee. Miners will prefer to mine the higher-fee version, discarding the previous one.

Used in RGB on-chain swaps as a mitigation against double-spending: if one party attempts to spend their UTXO in another transaction while the swap is in the mempool, the other party responds by broadcasting a higher-fee version of the swap to get it confirmed first.

---

### Replace (IFA operation)

An operation in the IFA schema that allows the **Replace right holder** to certify that the complete history of a set of allocations, from the certified point back to genesis, is valid. The Replace right is assigned at genesis to a specific UTXO — typically the issuer or a trusted auditor. Once a Replace stamp is applied, wallets that choose to trust that holder can skip re-validating the certified segment of the history.

Trust is opt-in: each wallet independently decides whether to trust a given Replace right holder. Full trustless validation from genesis always remains possible as long as the original consignment data is available.

---

### RGB Proxy Server

A standardized HTTPS server acting as a relay between the sender and recipient of an RGB transfer. The sender uploads the consignment to the server; the recipient downloads it. A user can run their own proxy server for full control, or use a third-party server for convenience. Using a third-party server has **privacy and censorship implications** — the server operator can see who is transferring what and could block transfers — but **no security implications**, since the recipient always validates the consignment locally.

---

### RPC (Remote Procedure Call)

A communication method between programs where one program calls a function on a remote machine as if it were a local function. The caller sends the function name and its parameters over a network; the remote machine executes it and returns the result. In RGB, proxy servers expose RPC endpoints that clients use to upload and download consignment data. See also: **JSON-RPC**.

---

### Scalar

In elliptic curve cryptography, a **scalar** is a simple integer, as opposed to a **point** (a pair of coordinates on the curve). Private keys are scalars. Public keys are points, obtained by multiplying a scalar by the generator point `G`.

---

### Schema

A reusable template that defines the structure and rules of a family of RGB contracts, analogous to a class in object-oriented programming. A schema specifies: which types of owned and global state exist, how genesis is structured, which operations (state transitions) are allowed, who has permission to execute them, and the AluVM validation scripts that enforce all the rules. Schemas are compiled into `.rgb` files. The rules encoded in a schema are immutable — they cannot be changed after the contract has been deployed. Main schemas: NIA, CFA, IFA, PFA, UDA.

---

### Seal Definition

The component of an Assignment that identifies the recipient's UTXO. It contains: **txptr** (the transaction ID, or a self-reference "WitnessTx" for the current transaction), **vout** (the output index) and **blinding** (8 random bytes for privacy). The concealed form is a tagged SHA-256 hash of all three fields. The blinding ensures that even if two recipients use the same UTXO, their concealed seals are different and unlinkable — protecting privacy in client-side validation.

---

### Stash

The set of client-side data related to one or more contracts that undergo validation and are stored by the user. The stash holds everything needed to prove ownership and construct transfers: contract history, seal definitions, and consignment data.

Source: [docs.rgb.info — Glossary](https://docs.rgb.info/annexes/glossary)

---

### Shard

A branch of the RGB contract DAG formed by a chain of State Transitions descending from the same Genesis. A contract can have multiple shards — for example, when tokens are split across multiple UTXOs, each UTXO represents a separate shard of the contract history. Each party only needs to validate the shard relevant to their own assets, not the entire contract history.

Source: [docs.rgb.info — Glossary](https://docs.rgb.info/annexes/glossary)

---

### Single-Use Seal

A foundational concept of RGB. A **seal** is a Bitcoin UTXO designated to hold an RGB asset. Like a physical seal on an envelope, it can be opened only once — by spending the UTXO. The act of spending the UTXO *is* the state transition: it closes the old seal and, in the same transaction, opens a new one (a new UTXO) where the asset is re-anchored. If the UTXO is spent without a valid RGB state transition, the asset is considered lost.

---

### Strict Type System

Infrastructure used by RGB to define complex data types that are deterministically identified by their semantic ID (`semId`). It ensures that data exchanged in consignments is encoded unambiguously and reproducibly across all implementations, regardless of programming language. Schemas use Strict Types to precisely define the data types for their state fields. Published as the `rgb-strict-types` crate.

Source: [docs.rgb.info — Glossary](https://docs.rgb.info/annexes/glossary)

---

### State Transition

An RGB contract operation that moves state from old seals to new seals. It consumes Inputs (previous Assignments) and produces new Assignments, updating ownership and/or contract data. The old UTXOs are spent (closing the seals), and the commitment to the new state is embedded in a specific output of the witness transaction — an OP_RETURN output (Opret) or a Taproot output (Tapret). The **anchor** is the client-side data structure (TxId + MPC Proof + ETP) that proves this commitment was included in the transaction. The schema's AluVM script validates that the transition follows the rules (e.g. sum of fungible inputs equals sum of outputs). State Transitions are the most common operation type — every asset transfer is a State Transition.

---

### Submarine Swap

An atomic swap between on-chain BTC and Lightning Network BTC. "Submarine" evokes the fact that one leg of the payment travels underwater — off-chain, invisible, inside Lightning channels — while the other leg is on-chain, visible on the blockchain.

```
On-chain (visible)  ←→  Lightning (submerged/invisible)
```

It is atomic for the same reason as other HTLC swaps: same secret S on both legs. One party cannot claim without revealing S, and revealing S allows the other to claim their side. Since BTC is exchanged for BTC (same asset), there is no Free Option Problem — there is no exchange rate to speculate on during the timelock.

---

### Transition Bundle

The set of RGB State Transitions from the same contract that are committed together in a single witness transaction. Multiple State Transitions can be bundled because they all correspond to a single contract leaf in the MPC tree. Bundling enables batching: many parallel transfers of the same contract committed in one Bitcoin transaction, sharing the on-chain fee.

Source: [docs.rgb.info — Glossary](https://docs.rgb.info/annexes/glossary)

---

### TapTree

The hidden script tree inside a Taproot output. It is structured as a Merkle tree of leaves, where each leaf contains an arbitrary Bitcoin script. The entire tree is committed into the output's public key via key tweaking, but the contents of individual leaves are only revealed on-chain if that specific leaf is used for spending. RGB places its commitment in the right-hand side of the TapTree (a nonce in the commitment allows the prover to position it there deterministically).

---

### Taproot

A Bitcoin protocol upgrade (BIP 341, activated November 2021) that allows a transaction output to embed a script tree (TapTree) while appearing on-chain as a simple public key. This improves privacy — all unspent scripts remain invisible — and efficiency, since the most common spending path (key-path) requires only a single Schnorr signature with no script revealed.

---

### Tweaked Public Key

In Taproot, the public key that appears on-chain is not the owner's raw internal key, but a *tweaked* version:

```
pubkey_tweaked = pubkey_internal + hash(pubkey_internal || merkle_root_taptree) * G
```

The tweak mathematically binds the key to the entire TapTree. Anyone who knows the internal private key can compute the tweaked private key and spend normally. From the outside, the tweaked key looks like any other public key — nothing reveals the existence or content of the TapTree.

---

### UDA (Unique Digital Asset)

The RGB schema for non-fungible tokens (NFTs). Each UDA represents a single unique asset and can only be transferred to one destination at a time (no splitting). It supports embedded media up to ~64 KiB directly in the contract data, plus a list of attachment hashes for larger external files. It optionally includes a **Proof of Reserves** field linking the NFT to a Bitcoin UTXO as collateral.

---

### UTXO (Unspent Transaction Output)

A specific Bitcoin transaction output, identified by its transaction hash and output index (vout), that has not yet been spent. In RGB, UTXOs serve as single-use seals: each UTXO can be designated to hold client-side RGB state (a token balance, a governance right, an NFT). Spending a UTXO closes the seal and anchors the corresponding State Transition to the Bitcoin blockchain.

Source: [docs.rgb.info — Glossary](https://docs.rgb.info/annexes/glossary)

---

### Witness Transaction

The Bitcoin transaction that provides the seal closing operation. It contains a Multi Protocol Commitment (MPC) either in an OP_RETURN output (Opret method) or a Taproot output (Tapret method). The witness transaction is what makes an RGB state transition final and time-ordered on the blockchain.

Source: [docs.rgb.info — Glossary](https://docs.rgb.info/annexes/glossary)

---

*This glossary is a living document — definitions will be added as new concepts are introduced. All definitions are verified against [docs.rgb.info](https://docs.rgb.info).*