# Glossary ### Anchor Set of client-side data that proves the inclusion of a unique [commitment](#commitment) inside a transaction. In RGB protocol it is constituted by: * The Bitcoin transaction ID of the [witness transaction](#witness-transaction). * The Multi Protocol Commitment - [MPC](#multi-protocol-commitment-mpc). * The Deterministic Bitcoin Commitment - [DBC](#deterministic-bitcoin-commitment-dbc). * The [ETP](#extra-transaction-proof-etp) in the case of [Tapret](/commitment-layer/deterministic-bitcoin-commitments-dbc/tapret.md) commitment scheme. ### AluVM Acronym of Algorithmic logic unit Virtual Machine, it is a register-based virtual machine for smart contract validation and distributed computing, used but not limited to RGB contract validation. [Link](/annexes/rgb-library-map.md#aluvm). ### Assignment The RGB-equivalent of a transaction output modifying, updating or creating some properties of the state of a [contract](#contract). It is formed by: * A [Seal Definition](#seal-definition) * An [Owned State](/rgb-state-and-operations/components-of-a-contract-operation.md#owned-states) [Link](/rgb-state-and-operations/components-of-a-contract-operation.md#assignments-of-an-owned-state) ### Business Logic The set of operations and rules contained in a contract [Schema](#schema) which allows for the rightful update of the [contract state](#contract-state). ### Client-side Validation The operation which allows the verification of some data exchanged between parties according to some defined protocol rules. In RGB protocol these data are in form of [consignment](#consignment); the above data can be exchanged privately between the parties involved as, unlike Bitcoin protocol, they don't need to be registered on a public medium (e.g. the blockchain). ### Commitment A defined mathematical object $$C$$, deterministically derived from applying a cryptographic operation to some structured input data $$m$$, called the message. The commitment can be registered in a defined publication medium (e.g. the blockchain) and embeds two operations: * ***Commit** operation, which* takes as inputs a public message $$m$$ and a random value $$r$$, and by applying to them the chosen cryptographic algorithm returns a value $$C = \text{commit}(m, r)$$. * ***Verify** operation, which* takes the value returned by the commit algorithm $$C$$, the public message $$m$$ and the secret value $$r$$ and returns True/False. $$\text{verify}(m, r, com) \rightarrow (\text{True} / \text{False})$$. The commitment is required to possess two fundamental security properties: * ***Binding***: requires that there cannot be two valid messages of the same commitment $$C$$. That is, it is computationally unfeasible to produce different $$m' : | : m' \neq m$$ and $$r' : | : r' \neq r$$ such that: $$\text{verify}(m,r,C)=\text{verify}(m',r',C) \rightarrow \text{True}$$ * ***Hiding***: requires that the message $$m$$ cannot be easily discovered by commitment attempts, i.e., that $$r$$ be uniformly sampled in a set $$R$$ such that it is statistically independent of $$m$$. ### Consignment The data transferred between parties that are subject to [client-side validation](#client-side-validation). In RGB there are 2 types of consignment: * **Contract Consignment**: provided by the contract issuer, includes the information about the contract setup, such as the [Schema](#schema) and the [Genesis](#genesis). * **Transfer Consignment**: provided by the payer to the payee, contains all the state transition history from [Genesis](#genesis) to the newly created unspent [Assignments](#assignment). ### Contract A set of [rights](#contract-rights) established and executed digitally between certain parties through RGB protocol. A contract possesses an [active state](/rgb-state-and-operations/state-transitions.md#state-generation-and-active-state) and [business logic](#business-logic), expressed in terms of ownership rights and executive rights. The contract state, rights and conditions of valid operations are defined using RGB [schema](#schema). Only state and operations which allowed by the schema declarations and validation scripts are allowed to happen within the contract scope. ### Contract Operation An update to the [contract state](#contract-state) performed according to the rules defined in the contract [schema](#schema). Contract operations include: * [Genesis](#genesis) * [State Transition](#state-transition) ### Contract Participant An actor who participates in contract operations. Contract parties are classified into the following categories: * **Contract issuer**: an actor creating contract [Genesis](#genesis). * **Contract party**: all actors who have some [ownership](#ownership) rights over RGB [contract state](#contract-state) which have been provided through an [Assignment](#assignment). ### Contract Rights RGB contract parties have different rights as a part of the contract conditions defined through RGB [Schema](#schema). The rights under RGB contracts can be classified into the following categories: * Ownership rights: the rights associated with the [ownership](#ownership) of some UTXO referenced by a [Seal Definition](#seal-definition). * Executive rights: the ability to construct the [contract state](#contract-state) in a final form, i.e. to construct a valid [state transition](#state-transition) satisfying [schema](#schema) validation rules. ### Contract State The set of up-to-date, private, and public information that manifests the condition of a contract at a certain point in history. In RGB, the contract state is constituted by: * [Global State](/rgb-state-and-operations/components-of-a-contract-operation.md#global-state) * [Owned State(s)](/rgb-state-and-operations/components-of-a-contract-operation.md#owned-states) ### Deterministic Bitcoin Commitment - DBC The set of rules which allows for the registration of a provably single [commitment](#commitment) in a Bitcoin transaction. Specifically, RGB protocol embeds 2 forms of DBC: * [Opret](/commitment-layer/deterministic-bitcoin-commitments-dbc/opret.md) * [Tapret](/commitment-layer/deterministic-bitcoin-commitments-dbc/tapret.md) ### Directed Acyclic Graph - DAG A directed graph that does not contain any directed cycle thus allowing topological ordering. A Blockchain or an RGB Contract [Shard](#shard) are examples of DAG. [Wikipedia link](https://en.wikipedia.org/wiki/Directed_acyclic_graph) ### Extra Transaction Proof - ETP The part of the [Anchor](/commitment-layer/anchors.md) that embeds the additional data necessary for the validation of [Tapret](/commitment-layer/deterministic-bitcoin-commitments-dbc/tapret.md) commitment contained in a [taproot](#taproot) transaction, such as the internal PubKey and the Script Path Spend. ### Genesis The set of data, regulated by a contract [schema](#schema), which represents the starting state of every contract of RGB. It's the equivalent of Bitcoin Genesis Block at the client-side level. [Link](/rgb-state-and-operations/state-transitions.md#genesis) ### Invoice A [base58](https://en.wikipedia.org/wiki/Binary-to-text_encoding#Base58) URL-encoded string embedding the necessary data in order to allow a payer counterpart to construct a [State Transition](#state-transition). ### Global State The set of public properties included in the [state](#contract-state) of a [contract](#contract), defined in [Genesis](#genesis) and optionally updatable according to the rule defined therein, which are not [owned](#ownership) by any party. [Link](/rgb-state-and-operations/components-of-a-contract-operation.md#global-state) ### Lightning Network A decentralized network of bidirectional payment (state) channels constituted by 2-of-2 mutisig wallet constructing and updating off-chain transactions. It represents a popular Bitcoin Layer 2 scaling solution. [Link](https://lightning.network/) ### Merkle Tree A cryptographic data structure that allows small (logarithmic) inclusion proofs. It's composed of a binary tree in which leaves are the set elements, each intermediate node contains the hash of its children and the root commits to the whole set of elements. To prove a leaf is part of the tree it's enough to provide sibling hashes throughout the path from the leaf to the root, whose size grows logarithmically with the number of leaves. [More details](https://developer.bitcoin.org/reference/block_chain.html#merkle-trees) ### Multi Protocol Commitment - MPC The [Merkle Tree](#merkle-tree) structure used in RGB to include in a single Bitcoin Blockchain commitment the multiple [Transition Bundles](#transition-bundle) of different contracts. [Link](/commitment-layer/multi-protocol-commitments-mpc.md) ### Owned State Part of the [state](#contract-state) of a [contract](#contract) enclosed into an [Assignment](#assignment) that contains the definition of the digital property being subjected to someone's [ownership](#ownership). [Link](/rgb-state-and-operations/components-of-a-contract-operation.md#owned-states) ### Ownership The control and thus the possibility to spend a [UTXO](#utxo) to which some client-side property isthat [assigned](#assignment). ### Partially Signed Bitcoin Transaction - PSBT A transaction which lacks some element of its signature and which can be completed/finalized with some additional elements later in time. [Link](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki) ### Schema A declarative piece of code that contains the set of variables, rules, and [business logic](#business-logic) according to which an RGB contract works. [Link](/rgb-contract-implementation/schema.md) ### Seal Definition The reference part of an [Assignment](#assignment) which binds the commitment to a [UTXO](#utxo) belonging to the new [owner](#ownership). [Link](/rgb-state-and-operations/components-of-a-contract-operation.md#seal-definition) ### Shard A branch of the [DAG](#directed-acyclic-graph---dag) chain of the RGB [State Transitions](#state-transition). ### Single-Use Seal A promise to [commit](#commitment) to a yet unknown message in the future, once and only once, such that commitment fact will be provably known to all members of a certain audience. [Link](/distributed-computing-concepts/single-use-seals.md) ### Stash The set of client-side data related to one or more [contracts](#contract) that undergo [validation](#client-side-validation) and are stored by the users. ### State Transition The most important [contract operation](#contract-operation) that makes possible the transition of an RGB State to a New State, changing [state](#contract-state) data and/or ownership. [Link](/rgb-state-and-operations/state-transitions.md#state-transitions-and-their-mechanics) ### Strict Type System An infrastructure that allows to create complex types which are deterministically identified by their `semId`. It is used by schemas to precisely define the data type for their state. [Link](/annexes/rgb-library-map.md#strict-types). ### Taproot The Bitcoin's Segwit v1 transaction format detailed in [BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) and [BIP342](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki). ### Transition Bundle A set of RGB [State Transitions](#state-transition) that belong to the same contract and that are committed in the same [witness transaction](#witness-transaction). [Link](/rgb-state-and-operations/state-transitions.md#transition-bundle) ### UTXO A Bitcoin Unspent Transaction Output. It is defined by a transaction hash and a *vout* index which, collectively, constitute an [outpoint](https://en.bitcoin.it/wiki/Protocol_documentation#tx). ### Witness Transaction The transaction that provides the [Seal](#single-use-seal) closing operation around a message that contains a [Multi Protocol Commitment](#multi-protocol-commitment-mpc) an [MPC](#multi-protocol-commitment-mpc) Tree. *** --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.rgb.info/annexes/glossary.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.