Progress pill
RGB in theory

RGB Glossary

RGB programming

RGB Glossary

If you need to come back to this short glossary of important technical terms used in the RGB world (listed in alphabetical order), you'll find it useful. This chapter isn't essential if you've already understood everything we've covered in the first section.

AluVM

The abbreviation AluVM stands for "Algorithmic logic unit Virtual Machine", a register-based virtual machine designed for smart contract validation and distributed computing. It is used (but not exclusively reserved) for the validation of RGB contracts. Scripts or operations included in an RGB contract can thus be executed in the AluVM environment.
For further information: AluVM official website

Anchor

An Anchor represents a set of client-side data used to prove the inclusion of a unique commitment in a transaction. In the RGB protocol, an Anchor consists of the following elements:
  • The Bitcoin transaction identifier (TXID) of the witness transaction;
  • The Multi Protocol Commitment (MPC);
  • The Deterministic Bitcoin Commitment (DBC);
  • The Extra Transaction Proof (ETP) if the Tapret commitment mechanism is used (see the section dedicated to this model).
An Anchor therefore serves to establish a verifiable link between a specific Bitcoin transaction and private data validated by the RGB protocol. It guarantees that these data are indeed included in the blockchain, without their exact content being publicly exposed.

Assignment

In RGB's logic, an Assignment is the equivalent of a transaction output that modifies, updates or creates certain properties within the state of a contract. An Assignment comprises two elements:
  • A Seal Definition (reference to a specific UTXO);
  • An Owned State (data describing the state associated with this new owner).
An Assignment therefore indicates that a portion of the state (for example, an asset) is now allocated to a particular holder, identified via a Single-use Seal linked to a UTXO.

Business Logic

The Business Logic groups together all the rules and internal operations of a contract, described by its schema (i.e. the structure of the contract itself). It dictates how the state of the contract can evolve, and under what conditions.

Client-side Validation

Client-side Validation refers to the process by which each party (client) verifies a set of data exchanged privately, according to the rules of a protocol. In the case of RGB, this exchanged data is grouped together in what are known as consignments. Unlike the Bitcoin protocol, which requires all transactions to be published on-chain, RGB allows only commitments (anchored in Bitcoin) to be stored in public, while the essential contract information (transitions, attestations, proofs) remains off-chain, shared only between the users concerned.

Commitment

A Commitment (in the cryptographic sense) is a mathematical object, denoted C, derived deterministically from an operation on structured data m (the message) and a random value r. We write:
This mechanism comprises two main operations:
  • Commit: a cryptographic function is applied to a message m and a random number r to produce C;
  • Verify: we use C, the m message and the r value to check that this commitment is correct. The function returns True or False.
A commitment must respect two properties:
  • Binding: it must be impossible to find two different messages producing the same C:
Such as:
  • Hiding: knowledge of C must not reveal the contents of m.
In the RGB protocol, a commitment is included in a Bitcoin transaction to prove the existence of a certain piece of information at a given time, without revealing the information itself.

Consignment

A Consignment groups together the data exchanged between the parties, subject to Client-side Validation in RGB. There are two main categories of consignment:
  • Contract Consignment: supplied by the issuer (contract issuer), it includes initialization information such as Schema, Genesis, Interface and Interface Implementation.
  • Transfer Consignment: supplied by the paying party (payer). It contains the entire history of state transitions leading up to the terminal consignment (i.e. the final state received by the payer).
These consignments are not recorded publicly on the blockchain; they are exchanged directly between the parties concerned via the communication channel of their choice.

Contract

A Contract is a set of rights executed digitally between several actors via the RGB protocol. It has an active state and a business logic, defined by a Schema, which specifies which operations are authorized (transfers, extensions, etc.). The state of a contract, as well as its validity rules, are expressed in the Schema. At any given time, the contract evolves only in accordance with what is permitted by this Schema and by validation scripts (run, for example, in AluVM).

Contract Operation

A Contract Operation is a contract status update performed according to Schema rules. The following operations exist in RGB:
  • State Transition;
  • Genesis;
  • State Extension.
Each operation modifies the state by adding or replacing certain data (Global State, Owned State...).

Contract Participant

A Contract Participant is an actor who takes part in operations relating to the contract. In RGB, a distinction is made between:
  • The issuer of the contract, which creates the Genesis (the origin of the contract);
  • The contract parties, i.e. the holders of rights to the state of the contract;
  • Public parties, who can build State Extensions if the contract offers Valencies accessible to the public.

Contract Rights

Contract Rights refer to the various rights that can be exercised by those involved in an RGB contract. They fall into several categories:
  • Ownership rights, associated with the ownership of a particular UTXO (via a Seal Definition);
  • Executive rights, i.e. the ability to build one or more transitions (State Transitions) in accordance with the Schema;
  • Public rights, when the Schema authorizes certain public uses, for example the creation of a State Extension via the redemption of a Valency.

Contract State

The Contract State corresponds to the current state of a contract at a given moment. It can be made up of both public and private data, reflecting the state of the contract. RGB distinguishes between:
  • The Global State, which includes the contract's public properties (set up in Genesis or added via authorized updates);
  • Owned States, which belong to specific owners, identified by their UTXOs.

Deterministic Bitcoin Commitment - DBC

Deterministic Bitcoin Commitment (DBC) is the set of rules used to provably and uniquely register a commitment in a Bitcoin transaction. In the RGB protocol, there are two main forms of DBC:
  • Opret
  • Tapret
These mechanisms define precisely how the commitment is encoded in the output or structure of a Bitcoin transaction, to ensure that this commitment is deterministically traceable and verifiable.

Directed Acyclic Graph - DAG

A DAG (or Acyclic Guided Graph) is a cycle-free graph, enabling topological scheduling. Blockchains, like the shards of RGB contracts, can be represented by DAGs.
For further information: Directed Acyclic Graph

Engraving

Engraving is an optional data string that successive owners of a contract can enter into the contract history. This feature exists, for example, in the RGB21 interface and enables commemorative or descriptive information to be added to the contract history.

Extra Transaction Proof - ETP

The ETP (Extra Transaction Proof) is the part of the Anchor that contains the additional data required to validate a Tapret commitment (in the context of taproot). It includes, among other things, the taproot script's internal public key (internal PubKey) and information specific to the Script Path Spend.

Genesis

Genesis refers to the set of data, governed by a Schema, that forms the initial state of any contract in RGB. It can be compared to Bitcoin's Genesis Block concept, or to the Coinbase transaction concept, but here at the client-side and RGB token level.

Global State

The Global State is the set of public properties contained in the Contract State. It is defined at Genesis and, depending on the contract rules, can be updated by authorized transitions. Unlike Owned States, the Global State does not belong to a particular entity; it is closer to a public registry within the contract.

Interface

The Interface is the set of instructions used to decode the binary data compiled in a Schema or in contract operations and their states, in order to make them readable for the user or his wallet. It acts as an interpretation layer.

Interface Implementation

Interface Implementation is the set of declarations that link an Interface to a Schema. It enables the semantic translation performed by the Interface itself, so that the raw data of a contract can be understood by the user or the software involved (the wallets).

Invoice

An Invoice takes the form of a URL encoded in base58, which embeds the data necessary for the construction of a State Transition (by the payer). In other words, it's an invoice enabling the counterparty (payer) to create the corresponding transition to transfer the asset or update the state of the contract.

Lightning Network

The Lightning Network is a decentralized network of payment channels (or state channels) on Bitcoin, made up of 2/2 multi-signature wallets. It enables fast, low-cost off-chain transactions, while relying on Bitcoin's Layer 1 for arbitration (or closure) when necessary.
For more information on how Lightning works, I recommend you take this other course:
Lightning Network Theory
Lightning Network Theory
Lightning Network Theory
Intermediate
4.8(152)

Discover the Lightning Network from a technical perspective

4.8(152)
Lightning Network Theory
Lightning Network Theory

Discover the Lightning Network from a technical perspective

Fanis MichalakisFanis Michalakis
Intermediate
6 hours
4.8(152)

Multi Protocol Commitment - MPC

Multi Protocol Commitment (MPC) refers to the Merkle tree structure used in RGB to include, within a single Bitcoin transaction, several Transition Bundles from different contracts. The idea is to group together several commitments (potentially corresponding to different contracts or different assets) in a single anchor point in order to optimize the occupation of block space.

Owned State

An Owned State is the part of a Contract State that is enclosed in an Assignment and associated with a particular holder (via a Single-use Seal pointing to a UTXO). This represents, for example, a digital asset or a specific contractual right assigned to that person.

Ownership

Ownership refers to the ability to control and spend a UTXO referenced by a Seal Definition. When an Owned State is linked to a UTXO, the owner of this UTXO has the right, potentially, to transfer or evolve the associated state, according to the rules of the contract.

Partially Signed Bitcoin Transaction - PSBT

A PSBT (Partially Signed Bitcoin Transaction) is a Bitcoin transaction that is not yet fully signed. It can be shared between several entities, each of which can add or verify certain elements (signatures, scripts...), until the transaction is deemed ready for on-chain distribution.
For further information: BIP-0174

Pedersen commitment

A Pedersen commitment is a type of cryptographic commitment with the property of being homomorphic with respect to the addition operation. This means that it is possible to validate the sum of two commitments without revealing the individual values.
Formally, if:
then:
This property is useful, for example, for concealing the amounts of tokens exchanged, while still being able to verify the totals.
Further information: Pedersen commitment

Redeem

In a State Extension, a Redeem refers to the action of reclaiming (or exploiting) a previously declared Valency. As a Valency is a public right, the Redeem allows an authorized participant to claim a specific contract state extension.

Schema

A Schema in RGB is a declarative piece of code describing the set of variables, rules and business logic (Business Logic) that govern the operation of a contract. The Schema defines the state structure, the types of transitions allowed and the validation conditions.

Seal Definition

The Seal Definition is the part of an Assignment that associates the commitment with a UTXO owned by the new holder. In other words, it indicates where the condition is located (in which UTXO), and establishes ownership of an asset or right.

Shard

A Shard represents a branch in the DAG of the State Transitions history of an RGB contract. In other words, it is a coherent subset of the contract's overall history, corresponding, for example, to the sequence of transitions required to prove the validity of a given asset since the Genesis.

Single-use Seal

A Single-use Seal is a cryptographic promise of commitment to an as yet unknown message, which will be revealed only once in the future and must be known by all members of a specific audience. The aim is to prevent the creation of multiple competing commitments for the same seal.

Stash

The Stash is the set of client-side data that a user stores for one or more RGB contracts, for the purpose of validation (Client-side Validation). This includes transition history, consignments, proofs of validity, etc. Each holder retains only the parts of the history they need (shards).

State Extension

A State Extension is a contract operation used to re-trigger state updates by redeeming previously declared Valencies. To be effective, a State Extension must then be closed by a State Transition (which updates the final state of the contract).

State Transition

State Transition is the operation that changes the state of an RGB contract to a new state. It can modify Global State and/or Owned State data. In practice, each transition is verified by Schema rules and anchored in the Bitcoin blockchain via a commitment.

Taproot

Refers to Bitcoin's Segwit v1 transaction format, introduced by BIP341 and BIP342. Taproot improves the confidentiality and flexibility of scripts, in particular by making transactions more compact and harder to distinguish from one another.

Terminal Consignment - Consignment Endpoint

The Terminal Consignment (or Consignment Endpoint) is a transfer consignment containing the final state of the contract, including the State Transition created from the recipient's Invoice (payee). It is therefore the endpoint of a transfer, with the necessary data to prove that ownership or state has been transferred.

Transition Bundle

A Transition Bundle is a set of RGB State Transitions (belonging to the same contract) that are all engaged in the same witness transaction Bitcoin. This makes it possible to bundle several updates or transfers into a single on-chain anchor.

UTXO

A Bitcoin UTXO (Unspent Transaction Output) is defined by the hash of a transaction and the output index (vout). It is also sometimes called an outpoint. In the RGB protocol, reference to an UTXO (via a Seal Definition) enables the location of the Owned State, i.e. the property held on the blockchain.

Valency

A Valency is a public right which does not require state storage as such, but which can be redeemed via a State Extension. It is therefore a form of possibility open to all (or certain players), declared in the logic of the contract, in order to carry out a particular extension at a later date.

Witness Transaction

The Witness Transaction is the Bitcoin transaction that closes the Single-use Seal around a message containing a Multi Protocol Commitment (MPC). This transaction spends a UTXO or creates one, so as to seal the commitment linked to the RGB protocol. It acts as an on-chain proof that the state has been set at a specific point in time.
Quiz
Quiz1/5
What is an Assignment in the RGB protocol?