RGB is a client-side-validated smart-contract system for representing and transferring digital rights with commitments anchored in Bitcoin transactions. Contract participants exchange the data needed to validate state changes, while Bitcoin supplies ordered transaction history and proof that UTXO-based seals were closed.
RGB is not a separate coin or proof-of-work blockchain. It also does not place a conventional global token ledger inside Bitcoin. Bitcoin nodes validate Bitcoin transactions, blocks, scripts, and UTXO spends. They do not execute RGB contract logic, calculate RGB balances, or store every RGB transfer.
That boundary defines both RGB's design and its operational burden.
What RGB is designed to do
A globally replicated contract system asks many participants to download or validate state they may never use. RGB takes a different approach. A holder or recipient validates the contract history needed for the rights being received, rather than expecting every Bitcoin node to validate every contract.
This design can support fungible state, unique or non-fungible state, and more general programmable rights. The contract data can remain outside the public Bitcoin ledger while compact commitments are published through Bitcoin transactions.
The benefit is selective disclosure and reduced global data replication. The tradeoff is that transfer data must reach the recipient, remain compatible with the recipient's software, and be backed up well enough for later validation and spending.
Client-side validation is not Bitcoin consensus validation
Bitcoin consensus validation asks whether a Bitcoin transaction or block follows Bitcoin's shared rules. A full node checks signatures, scripts, input availability, amounts, block limits, proof of work, and other consensus conditions.
Client-side validation asks a different question. Given an RGB contract and a proposed transfer, does the supplied contract history prove that the transferred state was created and moved according to the RGB rules being applied?
The recipient's RGB software performs that work. It checks the contract origin, relevant operations, state rules, seals, commitments, and Bitcoin witness history. Bitcoin nodes do not return an answer such as "this RGB transfer is valid."
A confirmed Bitcoin witness transaction provides chain-ordering and spend evidence. A separately verified anchor proves that the RGB operation commitment is included in that transaction. Neither fact by itself proves that the external contract data is complete, non-conflicting, or valid under the relevant RGB contract rules.
Single-use seals connect rights to one-time events
A single-use seal is a commitment primitive designed to be closed once.
In Bitcoin-based RGB, a seal definition can identify a Bitcoin transaction output. That output is an ordinary UTXO from Bitcoin's perspective. RGB software gives its future spend an additional client-side meaning.
When a valid Bitcoin transaction spends the associated output, the seal is closed. Bitcoin consensus prevents the same UTXO from being spent twice in the selected chain. RGB validation uses that unique spend event as evidence that prior owned state was consumed.
The seal does not place the RGB state inside the UTXO. It binds the ability to move particular client-side state to a Bitcoin output that can be spent only once.
A concealed or blinded seal can let a recipient provide a destination without revealing the full outpoint or ownership details to parties that do not need them. The exact concealment method and invoice encoding depend on the RGB version and software in use.
State transitions close old seals and define new ones
An RGB state transition consumes existing owned state and creates replacement state.
A transfer can assign state to new seal definitions controlled by recipients and, when necessary, return change-like state to the sender. The transition includes the contract operation data needed to describe those changes.
The Bitcoin transaction that spends the old seal definitions is the witness transaction. It closes the old seals and carries or participates in the commitment to the RGB operation. The resulting contract state is validated off-chain by the parties that receive the needed data.
Assignments are client-side records connecting state to seal definitions. They are not token balances written into Bitcoin outputs. Bitcoin sees UTXOs, scripts, and commitments. RGB software interprets the contract operation and assignment under the relevant protocol rules.
Commitments and anchors link state to Bitcoin
RGB uses deterministic Bitcoin commitments so a transaction can commit to client-side data without requiring Bitcoin consensus to interpret that data.
An anchor is the proof structure connecting an RGB operation to the commitment contained in a Bitcoin witness transaction. Depending on the protocol version and transaction construction, the commitment can use a supported method such as a Taproot-based commitment or an OP_RETURN fallback arrangement.
A valid anchor shows that the committed message was included under the commitment scheme and associated with the witness transaction. The recipient still has to validate the message itself.
This distinction resembles a sealed envelope attached to an ordered public event. Bitcoin can prove that the envelope commitment was present and that the relevant UTXO was spent. It does not read the enclosed RGB contract history or decide whether the contract claims are true.
Contract genesis and identifiers establish the starting point
Every RGB contract begins with a genesis operation.
Genesis establishes the initial contract parameters, rules, state, and issued rights. The contract identifier is derived from the contract's defining data. It gives software a precise reference that is stronger than a display name, ticker, image, or issuer description.
A recipient should validate the contract identifier and genesis data required by the supported protocol version. Two assets can use the same name or ticker while representing different contracts. A familiar label is not a substitute for a verified identifier.
Issuance also does not prove value, legitimacy, redeemability, legal status, or issuer solvency. Those claims exist outside protocol validity.
RGB v0.12 replaced the older schema model
RGB terminology changed materially between versions 0.11 and 0.12.
In the v0.11 architecture, a schema defined contract validation rules, interfaces described application-facing semantics, and implementations connected a schema to an interface. Many existing documentation pages and wallet libraries still use those terms.
The final v0.12 consensus architecture removed schemata from the current contract model. A codex now supplies the consensus rule package used to verify contract operations, together with its required libraries and execution environment. Wallet-facing software uses a contract API rather than the former standard-library interface and implementation combination.
Interfaces still appear in the Contractum developer environment, where they can be compiled into application-facing contract APIs. They should not be described as unchanged v0.12 standard-library objects.
This is not a vocabulary-only update. Contracts and software built for incompatible consensus generations cannot be assumed interoperable. A wallet must know which protocol, codex, API, encoding, and application library it supports.
Contract state is local and operation-based
Contract state is the result of valid operations known to the validating client.
The current v0.12 implementation exposes contract state through memory cells and application APIs. Its application layer uses names including GlobalApi and OwnedApi for globally readable and ownership-bound views. These names replaced earlier immutable and destructible API labels in the v0.12 release-candidate line.
Owned state is tied to single-use seals and is consumed when those seals close. Global state can represent contract information that is not assigned to one owner's seal in the same way. The precise state cell types and available operations are defined by the current codex and contract API.
Older explanations often divide state into fungible, structured, and attachment categories. Version 0.12 unified the consensus representation, so those older structural categories should not be copied directly into a current data-model explanation.
RGB-20 and RGB-21 are application standards
RGB-20 identifies a fungible-asset application standard. RGB-21 identifies a non-fungible or unique-asset application standard.
They describe application behavior above Bitcoin consensus. Bitcoin nodes do not know that a commitment represents an RGB-20 amount or an RGB-21 item.
The v0.12 release-candidate 2 announcement reported updated RGB-20 and RGB-21 standards alongside the new contract API and codex architecture. That does not make older v0.11 schema and interface artifacts automatically compatible with v0.12 contracts.
Support remains software-specific. A wallet that displays one RGB-20 generation may not understand another version, an RGB-21 contract, or a custom contract API. "Supports RGB" is incomplete without exact version and standard details.
Invoices describe requested contract state
An RGB invoice is a structured request for state under a specific contract and application environment.
It can identify a contract, requested state, amount or other assignment information, beneficiary seal, network, and related payment parameters. Version 0.12 expanded invoice capabilities for fungible and non-fungible state and more complex payment scripts.
An RGB invoice is not automatically a Lightning invoice. The formats, validation rules, routing behavior, and settlement workflows differ unless a specific integration defines how they interact.
Blinded or concealed seals can reduce what a sender learns about the recipient's Bitcoin outpoint. They do not conceal every other part of the interaction. Transport metadata, counterparties, timing, wallet telemetry, and later chain activity can still reveal information.
A consignment carries transfer evidence
A consignment is the RGB contract and transfer data delivered to a recipient for client-side validation. It is not a Bitcoin transaction.
The sender must provide enough information for the recipient to connect the received state to a valid contract origin and verify the relevant transition history. That can include contract identification, operations, seal definitions, witnesses, anchors, and supporting libraries or API information required by the version.
The recipient should not need every unrelated branch of a large contract history. Client-side validation can disclose the history required for the received state while omitting unrelated ownership branches. The exact pruning and disclosure behavior must match the implementation being used.
Version 0.12 changed consignments from file-like packages loaded as a whole into streams that can be validated as they arrive. The current validation code reads operations and seals from a consignment stream, verifies contract rules, and checks seal-closing witnesses.
A relay or proxy can deliver the package, but delivery does not make it valid. The recipient's client still performs validation.
Recipient validation has several layers
A recipient validating an RGB transfer needs to determine that:
- The contract identifier and genesis are the intended ones.
- The operation sequence follows the current codex and contract rules.
- The transferred state exists and was assigned through valid seal definitions.
- Earlier owned state was not reused within the validated history.
- Relevant seals were closed by the correct Bitcoin witness transactions.
- Anchors prove inclusion of the required commitments.
- The Bitcoin transactions are in the expected network and chain history.
- The received application API and data encodings are supported.
- The consignment contains enough data to establish the received rights.
A chain resolver, Electrum server, Esplora service, or local Bitcoin node can supply Bitcoin transaction and confirmation information. That service does not replace RGB contract validation. It answers chain questions used by the client-side validator.
A confirmed anchor can coexist with missing transfer data. Confirmation cannot deliver a consignment to a wallet that never received it.
An invalid RGB consignment is not necessarily an invalid Bitcoin transaction. Counterfeit issuance, excess supply, reused state, or unauthorized transitions are rejected by RGB client-side validation, even when the witness transaction itself is valid under Bitcoin's rules. If conflicting histories claim the same owned state, the client must compare their seal-closing evidence with Bitcoin's selected chain and reject any history that lacks the authoritative spend or fails RGB rules.
Data availability and backups affect enforceable use
Exercising RGB rights depends on more than private keys.
A seed phrase may restore Bitcoin keys, but it may not restore the RGB contract history, consignments, seal metadata, contract APIs, media, or transfer records needed to prove and spend client-side state.
Wallet software therefore has responsibilities for import, export, persistence, backup, and recovery. The v0.12 RC2 runtime and command-line release added contract import and export, contract backups, and removal of unused contracts. Those capabilities still need correct integration and user-facing recovery testing.
Losing required data can make valid rights difficult or impossible to demonstrate to a later recipient. A third-party proxy or indexer may retain copies, but relying on it creates availability and privacy dependencies. A backup claim should state whether it preserves keys only, complete consignments, contract state, attachments, or all data needed for future validation.
Using a proxy, indexer, or storage provider creates availability and privacy dependencies, not automatic custody. Custody depends on who controls the keys and any additional authorization required to move the state. A self-custodial label does not restore missing consignments or fix incompatible software.
Secure transport matters too. Private transfer packages must reach the intended recipient without substitution, corruption, or accidental disclosure.
Confirmations and reorganizations affect anchors
RGB relies on Bitcoin's selected chain for the witness transactions that close seals and publish commitments.
Before confirmation, a transaction can be replaced, conflict, or disappear from a node's mempool. After confirmation, a reorganization can remove the transaction from the active chain or change its depth and ordering context.
RGB v0.12 introduced a revised model intended to handle reorganization risks more explicitly. Wallets still need current chain data and clear policies for when a transfer is considered sufficiently settled.
If a reorganization removes the witness transaction, the wallet must reconsider the affected seal closing and downstream state, then revalidate against the selected chain.
One confirmation is not absolute finality. A recipient should distinguish successful client-side validation from the separate question of how much Bitcoin confirmation depth is required for the witness transaction.
Privacy comes from selective disclosure, not invisibility
RGB can keep detailed contract state away from the public Bitcoin ledger. Observers may see a Bitcoin transaction and commitment without learning the full contract operation.
Recipients can also receive only the history needed for their state rather than a global database.
Those properties do not create automatic privacy. A sender and recipient know transaction details. A relay can observe delivery metadata. A hosted wallet, resolver, indexer, or issuer can correlate requests. Bitcoin transaction structure can reveal relationships. Contract identifiers, repeated invoices, media retrieval, and backup services can create additional links.
Privacy depends on the complete wallet, transport, chain-access, and counterparty model.
Wallet and SDK versions are not one release line
As of July 19, 2026, RGB has several simultaneously relevant version families.
The rgb-core consensus crate is version 0.12.0. Its maintainers describe consensus functionality as frozen except for bug fixes.
The current default branches of the RGB wallet runtime and RGB standard library identify themselves as 0.12.0-rc.3. The latest published GitHub release for the runtime and command-line tool remains v0.12.0-rc.2, released June 3, 2025.
The separate rgb-lib wallet SDK identifies itself as 0.3.0-beta.7 and currently depends on v0.11.1-rc.11 RGB application libraries. It belongs to a different compatibility line from the v0.12 default branches.
Official documentation also contains pages written around v0.11 schemas and interfaces alongside newer v0.12 material. Readers and implementers must verify a page's architecture rather than assuming that an unversioned documentation page describes the final v0.12 model.
The consensus layer being final does not make every wallet, standard library, SDK, or application final.
Lightning compatibility is implementation-specific
RGB is designed to support client-side state associated with Lightning channels, and current repositories describe commitments to RGB state in channel transactions.
That design claim is not universal Lightning deployment.
The maintained RGB Lightning Node identifies itself as version 0.1.0 and currently pins rgb-lib 0.3.0-beta.7, matching the separate rgb-lib default branch's current 0.3.0-beta.7 version. Its documentation labels the software early alpha and limits ordinary testing to regtest and testnet environments. It requires a Bitcoin node and an Electrum or Esplora indexer; an RGB proxy server is required only when proxy-based consignment transport is used. These are implementation dependencies, not universal protocol requirements.
It should therefore be described as an experimental integration, not proof that arbitrary RGB contracts can move across the public Lightning Network through ordinary wallets and nodes. Compatibility depends on modified channel software, shared RGB versions, liquidity, transfer-data delivery, backup, and close handling.
Operational risks and open questions
RGB separates Bitcoin settlement evidence from client-side contract validation. That produces several independent failure surfaces.
A Bitcoin transaction can confirm while a consignment is missing. A consignment can be complete while the witness transaction remains unconfirmed. Contract data can be valid while a wallet lacks the correct API. A wallet can control the Bitcoin key while losing the RGB history. Two products can both advertise RGB support while implementing incompatible version families.
Open technical and operational questions include cross-wallet interoperability, migration between version families, long-term availability of contract data, hardware-wallet verification, secure relay design, reorganization handling, attachment storage, issuer metadata, audit coverage, and usable backup restoration.
The durable mental model is narrow: Bitcoin orders and validates the UTXO spends and commitments that reach its chain. RGB clients validate the contract history and state they receive. Neither layer can silently perform the other's job.