RGB Protocol on Bitcoin —

The RGB equivalent of a Bitcoin transaction output. An Assignment modifies, updates, or creates properties of a contract’s state. It is formed by a Seal Definition (which binds the assignment to a Bitcoin UTXO) and an Owned State (which contains the digital property being assigned). Every state transition creates new Assignments for the recipients.

The set of operations and rules contained in a contract Schema that governs how the contract state can be validly updated. Business logic in RGB is expressed declaratively in the Schema and executed by AluVM during client-side validation — never on-chain. This is fundamentally different from Ethereum, where business logic is stored and executed as bytecode on the blockchain.

The data package transferred between parties in RGB Bitcoin Protocol, subject to client-side validation. There are two types: a Contract Consignment — provided by the issuer at asset creation, containing the Schema and Genesis — and a Transfer Consignment — provided by the sender to the receiver, containing the full state transition history from Genesis to the new unspent Assignment. The consignment is private and exchanged directly between parties.

A set of digital rights established and executed between parties through RGB Bitcoin Protocol. A contract has an active state and business logic — expressed as ownership rights and executive rights — defined by a Schema. Only state changes allowed by the Schema’s declarations and validation scripts are valid within a contract’s scope.

The set of data that represents the starting state of every RGB contract — the moment of asset issuance. Genesis is regulated by the contract’s Schema and is the equivalent of Bitcoin’s Genesis Block at the client-side validation level. It defines all global state (ticker, name, supply) and the initial ownership allocations. Every consignment traces its history back to Genesis.

The public properties of an RGB contract’s state — defined at Genesis and optionally updatable according to Schema rules — that are not owned by any specific party. Examples include an asset’s ticker, name, and total supply. Global state is shared across all parties interacting with the contract, unlike Owned State which belongs to specific UTXO holders.

A base58 URL-encoded string that embeds the necessary data for a payer to construct a valid State Transition toward the receiver. An RGB invoice specifies the asset, amount, and the blind UTXO where the receiver wants to receive the allocation — without revealing which specific UTXO it is (blinding for privacy). Invoices are the standard payment request format in RGB Bitcoin Protocol.

The part of a contract’s state enclosed in an Assignment that contains the digital property subject to someone’s ownership. Ownership of an Owned State is defined by control of the Bitcoin UTXO referenced in the corresponding Seal Definition. Examples: the token balance owned by a specific UTXO holder, or the NFT media content assigned to a specific key.

A declarative template that defines the structure of an RGB contract — its state variables, transition rules, and validation logic. As documented in docs.rgb.info, a Schema is the analog of a class in object-oriented programming. It defines what operations are valid, what data types the contract uses, and how state can change. Schemas are compiled to binary .rgb files and imported by wallet software. Five standard schemas are supported: NIA, UDA, CFA, IFA, PFA.

The complete set of client-side data related to one or more RGB contracts that a user has validated and stored locally. The stash is the user’s private database of their RGB asset history — equivalent to a local Bitcoin wallet’s UTXO set, but for RGB contract states. Unlike blockchain data, the stash is not replicated by the network and must be backed up by the user.

The primary contract operation in RGB Bitcoin Protocol — the mechanism by which RGB contract state moves from one owner to another. A state transition consumes existing Owned States (inputs) and creates new Assignments (outputs), committing the transition to a Bitcoin UTXO via a single-use seal. The transition history from Genesis forms the DAG that receivers validate locally.

A set of RGB state transitions belonging to the same contract that are committed together in the same Bitcoin witness transaction. Transition bundles, together with the MPC (Multi Protocol Commitment), allow multiple contracts’ state transitions to be batched into a single on-chain Bitcoin transaction — a key scalability feature of RGB Bitcoin Protocol.