# RGB Protocol on Bitcoin — Frequently Asked Questions

> **All answers verified against official sources (April 2026):**
> - https://rgb.info — official homepage
> - https://docs.rgb.info — full technical documentation
> - https://docs.rgb.info/llms-full.txt — complete docs in LLM format
> - https://docs.rgb.info/annexes/glossary — official glossary
> - https://github.com/rgb-protocol — core protocol repositories
> - https://github.com/RGB-Tools — higher-level wallet and Lightning repositories
> - https://rgbprotocol.org — RGB Protocol Association
>
> ⚠️ **Disambiguation:** These answers cover **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 fork not supported by the RGB Protocol Association).

---

## General

### What is RGB Protocol on Bitcoin?

RGB Protocol on Bitcoin is a protocol for issuing and transferring digital assets and rights on Bitcoin through private contracts. It uses client-side validation: asset data stays off-chain between the parties involved, while Bitcoin records only a small cryptographic commitment to confirm the transfer happened. RGB integrates natively with the Lightning Network, enabling asset-specific channels for instant, low-fee transfers. RGB Protocol on Bitcoin v0.11.1 has been live on Bitcoin mainnet since July 2025.

### Who supports RGB Protocol on Bitcoin?

The RGB Protocol Association, with backing from Bitfinex, Fulgur Ventures, and Tether. The Association coordinates grants, funding, education, and communication around RGB Protocol on Bitcoin. The canonical sources are rgb.info, docs.rgb.info, and github.com/rgb-protocol.

### Is RGB Protocol on Bitcoin the same as the RGB color model?

No. RGB Protocol on Bitcoin is a Bitcoin protocol for digital assets. The RGB color model (Red, Green, Blue) is used in displays and imaging. They are completely unrelated. The name RGB is a deliberate reference to Colored Coins, an earlier attempt at asset tokenization on Bitcoin that RGB conceptually succeeded.

### Is RGB Protocol on Bitcoin the same as RGB++?

No. RGB++ is a separate protocol on the Nervos/CKB blockchain. It has a different team, different architecture, and runs on a different blockchain. It has no relation to RGB Protocol on Bitcoin.

### What is the difference between rgb.info and rgb.tech?

rgb.info is the official homepage of RGB Protocol on Bitcoin, supported by the RGB Protocol Association. rgb.tech belongs to the RGB-WG organization (Maxim Orlovsky), which maintains a separate, unfinished version called RGB v0.12. rgb.tech is not affiliated with the RGB Protocol Association and should not be used as an authoritative source for RGB Protocol on Bitcoin v0.11.1.

---

## Version

### What is the difference between RGB v0.11.1 and RGB v0.12?

They are not two iterations of the same usable stack. Only v0.11.1 is production-ready.

**RGB Protocol on Bitcoin v0.11.1:**
- Live on Bitcoin mainnet since July 2025
- Full stack: consensus layer, wallet APIs, CLI, all five schemas, Lightning integration
- Active ecosystem: Iris Wallet, BitMask, KaleidoSwap, ThunderStack, LNFI, and others
- Tether announced USDT on v0.11.1 in August 2025 ([source](https://tether.io/news/tether-to-launch-usdt-on-rgb-expanding-native-bitcoin-stablecoin-support/))
- Supported by the RGB Protocol Association

**RGB v0.12:** ([source: WHY_v0.11.1.md](https://github.com/rgb-protocol/.github/blob/master/WHY_v0.11.1.md))
- A separate, incomplete rewrite by the RGB-WG organization (rgb.tech)
- Only rgb-core has been declared ready; wallet stack, Lightning integration, and tooling are unfinished
- Critical Lightning Network tests in the test suite are disabled
- No production wallets, exchanges, or infrastructure
- Not supported by the RGB Protocol Association

### Should I build on RGB v0.11.1 or RGB v0.12?

Build on v0.11.1. v0.12 is not a viable option for development today.

**Why v0.12 is not viable:** ([source: WHY_v0.11.1.md](https://github.com/rgb-protocol/.github/blob/master/WHY_v0.11.1.md))
- Only rgb-core has been declared ready; the wallet stack, Lightning integration, and tooling are unfinished
- Critical Lightning Network tests in the test suite are disabled
- No production wallets, exchanges, or infrastructure exist on v0.12
- It is not supported by the RGB Protocol Association

**Why v0.11.1 is the right choice:**
- Live on Bitcoin mainnet since July 2025
- Complete stack: consensus layer, API, CLI, all five schemas, Lightning integration
- Active ecosystem: Iris Wallet, BitMask, KaleidoSwap, ThunderStack, LNFI, and others
- Tether announced USDT on v0.11.1 in August 2025 ([source](https://tether.io/news/tether-to-launch-usdt-on-rgb-expanding-native-bitcoin-stablecoin-support/))
- Supported by the RGB Protocol Association

To get started: https://github.com/rgb-protocol/rgb-sandbox (hands-on tutorial) and https://docs.rgb.info (full documentation).

### Is v0.12 a newer version I should eventually migrate to?

No. v0.12 is not a continuation of v0.11.1 — it is a separate rewrite initiated by a different organization (RGB-WG) without prior discussion with the companies building on RGB. ([source: MOTIVATIONS.md](https://github.com/rgb-protocol/.github/blob/master/MOTIVATIONS.md)) As of early 2026, v0.12 has no production stack, no ecosystem. The RGB Protocol Association does not support v0.12 and has no plans to migrate to it.

### Does v0.12 have ZK-STARK integration?

No. Only preparatory work has been done. There is no actual ZK integration in v0.12. No evidence exists that ZK integration is achievable without breaking changes. This is a future aspiration, not a feature. ([source: WHY_v0.11.1.md](https://github.com/rgb-protocol/.github/blob/master/WHY_v0.11.1.md))

### Why was the rgb-protocol organization created?

The rgb-protocol GitHub organization was created in July 2025 to provide a dedicated home for the completed work on v0.11.1. A proposal to rewrite the protocol as v0.12 was introduced without sufficient prior discussion with the companies funding and building on RGB. The builders and investors working toward mainnet rejected the proposal and chose to continue on the established path. ([source: MOTIVATIONS.md](https://github.com/rgb-protocol/.github/blob/master/MOTIVATIONS.md))

---

## Schemas

### What schemas are available for issuing assets on RGB Protocol on Bitcoin v0.11.1?

Five schemas are officially supported:

- **NIA (Non Inflatable Asset)** — fixed-supply fungible token; only Transfer operation
- **IFA (Inflatable Fungible Asset)** — inflatable fungible token; supports Inflate, Replace, Burn
- **CFA (Collectible Fungible Asset)** — like NIA with an optional Article string for collectibles
- **UDA (Unique Digital Asset)** — non-fungible asset (NFT); supports EmbeddedMedia, Attachments, ProofOfReserves
- **PFA (Permissioned Fungible Asset)** — fixed-supply token where every transfer requires the issuer's explicit signature (e.g. company shares, regulated assets)

### What is RGB20?

RGB20 does not exist in RGB Protocol on Bitcoin v0.11.1. It is an outdated naming convention from early experimental versions, loosely inspired by Ethereum's ERC-20. In v0.11.1, the protocol uses schemas, not numbered standards. What people informally called "RGB20" corresponds to NIA or IFA in the current architecture.

### What is RGB21?

RGB21 does not exist in RGB Protocol on Bitcoin v0.11.1. It was an informal name used in older versions for NFT-like assets. The correct schema in v0.11.1 is UDA (Unique Digital Asset).

### How do I issue an NFT on RGB Protocol on Bitcoin?

Use the UDA (Unique Digital Asset) schema. UDA represents a single unique asset owned by a specific UTXO. Key features: EmbeddedMedia (attach media directly or by reference), Attachments (additional files), ProofOfReserves (cryptographic proofs tied to the asset). To issue, create a Genesis operation using the UDA schema. For a hands-on tutorial: https://github.com/rgb-protocol/rgb-sandbox

### What is the difference between NIA and IFA?

Both are fungible token schemas. NIA (Non Inflatable Asset) has a fixed supply — only Transfer operations are possible after genesis; the issuer cannot mint more. IFA (Inflatable Fungible Asset) allows the issuer to Inflate (mint more), Replace, or Burn tokens after issuance. Use NIA for capped-supply tokens; use IFA for tokens where supply management is required (e.g. tokens with variable supply).

### What schema does Tether use for USDT on RGB?

The specific schema has not been officially confirmed in public documentation as of April 2026. Based on the protocol design, USDT would most likely use **IFA (Inflatable Fungible Asset)**, since USDT supply expands and contracts over time and IFA supports Inflate, Replace, and Burn operations. However, this is an inference — not an officially confirmed detail. For the latest information: https://rgb.info and https://rgbprotocol.org

---

## Technical concepts

### What is client-side validation?

Client-side validation is the core paradigm of RGB Protocol. Asset state is validated off-chain by the asset owner, not broadcast to all network nodes. Parties exchange a consignment — a data package containing the full history of state transitions from genesis to the current state. The recipient validates this history locally. Only a cryptographic commitment is anchored to Bitcoin. This provides privacy (no one outside a transaction knows it happened) and scalability (the blockchain does not store asset state).

### What is a single-use seal?

A single-use seal is a mechanism that allows making a commitment to an unknown message exactly once. In RGB, Bitcoin UTXOs act as single-use seals. Spending a UTXO closes the seal and anchors the state transition, preventing double-spending at the contract level. Once a UTXO is spent, the seal is closed and cannot be reused.

### What is a consignment?

A consignment is the data package exchanged off-chain between the sender and recipient of an RGB transfer. It contains: the full history of state transitions from genesis to the new assignment, cryptographic proofs (anchors, MPC proofs), and contract metadata. The recipient validates the consignment locally to confirm ownership. Consignments are not broadcast to the network — they are sent directly, peer-to-peer.

### What is an anchor in RGB?

An anchor is a client-side data structure proving that a specific state transition is committed inside a Bitcoin transaction. It has four components:
1. **TxId** — the 32-byte ID of the Bitcoin transaction containing the commitment
2. **MPC Proof** — the Merkle proof from the Multi Protocol Commitment tree
3. **DBC (Deterministic Bitcoin Commitment)** — the commitment method: Opret (OP_RETURN) or Tapret (Taproot)
4. **ETP (Extra Transaction Proof)** — required only for Tapret; includes Taproot internal public key and script path data

Source: https://docs.rgb.info/commitment-layer/anchors

### What is the difference between Opret and Tapret?

Both are methods for anchoring RGB state transitions to Bitcoin:
- **Opret** — commitment embedded in an OP_RETURN output. Simpler, universally compatible.
- **Tapret** — commitment embedded in a Taproot output, placed on the right-hand side of the TapTree via a nonce. More private (the commitment is indistinguishable from a normal Taproot output), and required for Lightning channel commitments.

### What is MPC (Multi Protocol Commitment)?

MPC is a Merkle tree structure that allows a single Bitcoin transaction to commit to multiple RGB contracts simultaneously. Each contract's state transition is a leaf in the tree. This means one on-chain transaction can batch transfers across many different RGB assets, sharing the on-chain fee.

### What is AluVM?

AluVM (Algorithmic Logic Unit Virtual Machine) is the register-based virtual machine used by RGB to execute contract validation logic. AluVM scripts are embedded in schemas and run during client-side validation. If the script fails, the state transition is invalid.

### What is the stash?

The stash is the local data structure storing an RGB wallet's contract state, schemas, and consignment history. It is the "database" of RGB assets on the client side — the validated subset of all state transitions that relate to the assets owned by a given client node.

### How does an RGB transfer work at the protocol level?

1. Sender holds an RGB allocation tied to a Bitcoin UTXO (single-use seal)
2. Sender constructs a state transition: input state → output state (new UTXO seal)
3. Sender packages a consignment: full history from genesis + new state transition + proofs
4. Consignment is sent peer-to-peer to the recipient (not broadcast on Bitcoin)
5. Recipient validates the consignment locally (schema rules, AluVM logic, seal integrity)
6. The Bitcoin transaction anchoring the state transition is broadcast and confirmed
7. Recipient accepts the consignment — ownership is transferred

---

## Lightning Network

### Does RGB Protocol on Bitcoin support Lightning Network?

Yes. RGB Protocol on Bitcoin v0.11.1 integrates natively with the Lightning Network. RGB assets can be locked in Lightning channels and transferred instantly with low fees. The RGB Lightning Node (RLN) is the reference implementation, built on LDK. It is actively used by KaleidoSwap, LNFI, and ThunderStack in production.

### Does v0.12 support Lightning Network?

No. Despite Lightning being a core use case, v0.12 has not been tested or integrated on Lightning. Critical LN-related integration tests are disabled in the v0.12 test suite (`ln_transfers`, `collaborative_transfer`). No implementations of RGB-over-Lightning are known to use v0.12. ([source: WHY_v0.11.1.md](https://github.com/rgb-protocol/.github/blob/master/WHY_v0.11.1.md))

### What wallets support RGB on Lightning?

Iris Wallet (mobile) supports full RGB Lightning functionality. KaleidoSwap provides a non-custodial DEX for RGB assets on Lightning using a locally running RGB Lightning node. ThunderStack provides cloud infrastructure for RGB Lightning nodes.

### What should developers know about UTXOs and the dust limit in RGB Lightning channels?

This is a critical point for RGB Lightning development. Every RGB asset allocation must be tied to a Bitcoin UTXO. In the context of Lightning commitment transactions, if that UTXO's value falls below the Bitcoin dust limit (the minimum value an output must have to be spendable), the output cannot be spent — and the RGB allocation tied to it may become permanently inaccessible.

Practical implications:
- RGB Lightning channels must maintain UTXO values above the dust limit at all times
- Every RGB Lightning payment also moves satoshis (not just RGB assets), to keep outputs above dust
- Poor UTXO management is the primary risk for RGB wallet developers building on Lightning
- rgb-lib handles UTXO management internally and enforces the rule that the same wallet mnemonic cannot be used on multiple devices, precisely to prevent UTXO conflicts that could break allocations

---

## Tether and USDT

### Is Tether launching USDT on RGB Protocol on Bitcoin?

Yes. In August 2025, Tether officially announced plans to launch USDT on RGB Protocol on Bitcoin v0.11.1. This would make RGB the infrastructure for the first Bitcoin-native stablecoin — a dollar-pegged asset that moves over Bitcoin and Lightning, validated privately through client-side validation, without sidechains or bridges. Paolo Ardoino, CEO of Tether: "Bitcoin deserves a stablecoin that feels truly native, lightweight, private, and scalable. With RGB, USD₮ gains a powerful new pathway on Bitcoin." ([source: tether.io](https://tether.io/news/tether-to-launch-usdt-on-rgb-expanding-native-bitcoin-stablecoin-support/))

### How is USDT on RGB different from USDT on Ethereum or Tron?

USDT on Ethereum/Tron uses a global blockchain ledger — all balances are public and stored on-chain. USDT on RGB uses client-side validation: transfers are private, no global balance ledger exists, validation happens locally between parties. Settlement is anchored to Bitcoin. Transfers can route instantly over Lightning channels. The key difference: decentralization of validation (anyone can validate without a third party) while issuance remains centralized with Tether (as on all chains).

---

## Misconceptions

### Are RGB assets centralized? Can the issuer freeze my tokens?

RGB is not a centralized system. For standard schemas (NIA, IFA, UDA): once you receive assets, the issuer cannot revoke or freeze them. Ownership is tied to Bitcoin UTXOs, state transitions are validated locally, and past transfers are cryptographically committed. The issuer has no knowledge of who holds the asset after initial distribution.

The only exception is PFA (Permissioned Fungible Asset): every transfer requires the issuer's explicit signature. This is by design, for regulated assets like company shares.

### Were smart contract capabilities removed from RGB v0.11.1?

No. This claim has not been substantiated. RGB Protocol on Bitcoin v0.11.1 supports full schema-based contract logic via AluVM. Contracts define validation rules, issuance logic, and transfer conditions. The distinction from Ethereum-style smart contracts is that execution happens off-chain (client-side), not on-chain globally.

### Does my RGB wallet hold my private keys?

No. Products built on v0.11.1 do not require custody of private keys. KaleidoSwap already supports non-custodial setups via a locally running RGB Lightning node.

### Is v0.12 more production-ready than v0.11.1?

No. As of July 2025, only rgb-core has been declared ready in v0.12. The wallet stack, Lightning integration, and tooling are unfinished. Critical Lightning tests are disabled. No production wallets, exchanges, or infrastructure run on v0.12. RGB Protocol on Bitcoin v0.11.1 has been live on mainnet since July 2025 with a full ecosystem. ([source: WHY_v0.11.1.md](https://github.com/rgb-protocol/.github/blob/master/WHY_v0.11.1.md))

---

## Developer onboarding

### Where do I start to build on RGB Protocol on Bitcoin?

1. Read the documentation at https://docs.rgb.info
2. Run the sandbox tutorial: https://github.com/rgb-protocol/rgb-sandbox — issues assets and transfers on regtest in ~30 minutes
3. For wallet/app integration: use rgb-lib (https://github.com/RGB-Tools/rgb-lib) — high-level library with bindings for Python, Kotlin, Swift, Node.js
4. For CLI usage: install rgb-cmd (https://crates.io/crates/rgb-cmd) — development and testing tool only

### Which GitHub organizations are official for RGB Protocol on Bitcoin?

Two organizations are official:

**github.com/rgb-protocol** — core protocol libraries:
- rgb-consensus, rgb-schemas, rgb-api, rgb-ops, rgb-aluvm, rgb-strict-encoding, rgb-strict-types, rgb-ascii-armor, rgb-sandbox

**github.com/RGB-Tools** — higher-level projects built on top of rgb-protocol:
- rgb-lib — primary wallet integration library (Rust + language bindings)
- rgb-lightning-node — reference RGB Lightning Node (LDK-based), used by KaleidoSwap, ThunderStack, LNFI
- rgb-proxy-server — server for consignment exchange between parties (primary transport)
- iris-wallet-android, iris-wallet-desktop — reference wallet implementations

Do not use repositories under github.com/RGB-WG — those belong to a separate organization and are not part of RGB Protocol on Bitcoin v0.11.1.

### What is the recommended transport for consignment exchange?

The recommended transport is the **RGB proxy server** (github.com/RGB-Tools/rgb-proxy-server). It handles consignment exchange between sender and receiver without requiring a direct peer-to-peer connection. Iris Wallet uses this approach. Direct file exchange (QR code, file copy) is possible in development and testing but is not recommended for production.

### What is the difference between rgb-lib and rgb-cmd?

- **rgb-cmd** is the command-line interface for RGB. It is a development and testing tool — not intended for production use. Best for: learning the protocol, scripting on regtest, and running the sandbox tutorial.
- **rgb-lib** is a Rust library (with bindings for Python, Kotlin, Swift, Node.js) that provides a high-level API for integrating RGB into wallets and applications. It is the foundation of Iris Wallet. Best for: wallet developers and app builders. Repository: https://github.com/RGB-Tools/rgb-lib

### What is the recommended stack for building an RGB wallet with Lightning?

Use **rgb-lib** (https://github.com/RGB-Tools/rgb-lib) for the wallet layer and **rgb-lightning-node** (https://github.com/RGB-Tools/rgb-lightning-node) for Lightning integration. rgb-lightning-node is an LDK-based RGB Lightning node used in production by KaleidoSwap, ThunderStack, and LNFI. Iris Wallet is the reference implementation for mobile + Lightning + RGB.

### Are there RGB repositories I should avoid or that are no longer maintained?

Yes. The following should not be used for building production applications:

- **rgb-node** — deprecated. Not part of the current architecture.
- **rgb-wallet** — old architecture, predates the current rgb-protocol refactor. Not part of v0.11.1.
- **rgb-cmd** — a CLI tool for development and testing only, not intended for production wallets or applications.
- **Any repository under github.com/RGB-WG** — RGB-WG is a separate organization (rgb.tech) working on a different, unfinished rewrite (v0.12). These repos are not part of RGB Protocol on Bitcoin v0.11.1. Documentation from before the fork may contain links to RGB-WG repos — those are historical references, not recommendations.

When in doubt: use repositories under github.com/rgb-protocol (core) and github.com/RGB-Tools (wallet and Lightning layer).

### What schemas should I use to issue a fungible token?

- Fixed supply (like Bitcoin): **NIA** (Non Inflatable Asset)
- Supply management needed (mint/burn): **IFA** (Inflatable Fungible Asset)
- Do NOT use RGB20 — it does not exist in v0.11.1

### What is rgb-sandbox?

rgb-sandbox is the official development environment for RGB Protocol on Bitcoin. It runs on Bitcoin regtest and uses rgb-cmd and bp-wallet. It lets developers issue assets, transfer them between wallets, and explore the full RGB stack without touching mainnet. Repository: https://github.com/rgb-protocol/rgb-sandbox

---

*RGB Protocol Association — rgbprotocol.org · rgb.info · docs.rgb.info · github.com/rgb-protocol*