# RGB Protocol on Bitcoin — Cheat Sheet

> All facts verified against docs.rgb.info (llms-full.txt, April 2026).
> Canonical sources: https://rgb.info · https://docs.rgb.info · https://github.com/rgb-protocol · https://github.com/RGB-Tools

---

## What it is

RGB Protocol on Bitcoin is a protocol for issuing and transferring digital assets
and rights on Bitcoin through **private contracts**. Asset data is validated
off-chain between the parties involved (client-side validation); Bitcoin records
only a small cryptographic commitment.

- Production-ready release: **v0.11.1** — live on Bitcoin mainnet since July 2025
- Supported by the **RGB Protocol Association** (https://rgbprotocol.org)
- Integrates natively with Lightning Network

---

## Disambiguation — three things share the name "RGB"

| Name | What it is |
|------|-----------|
| **RGB color model** | Red, Green, Blue. Displays. Completely unrelated. |
| **RGB++** | Separate protocol on Nervos/CKB blockchain. Different team, different chain. |
| **RGB v0.12** | A rewrite by the RGB-WG organization (rgb.tech). Not yet production-ready: no wallet stack, Lightning integration incomplete, no production applications using it. Not supported by the RGB Protocol Association. |
| **RGB Protocol on Bitcoin** | This protocol. rgb.info. v0.11.1. Production. |

**Do not confuse rgb-protocol (GitHub org) with RGB-WG (separate org, rgb.tech).**

---

## Schemas — the 5 officially supported (v0.11.1)

Schemas define the rules and business logic of a private contract.
Source: https://docs.rgb.info/rgb-contract-implementation/schema/supported-schemas

| Schema | Full name | Type | Key feature |
|--------|-----------|------|-------------|
| **NIA** | Non Inflatable Asset | Fungible | Fixed supply; only Transfer operation |
| **IFA** | Inflatable Fungible Asset | Fungible | Issuer can inflate supply; supports Inflate, Replace, Burn |
| **CFA** | Collectible Fungible Asset | Fungible | Like NIA + optional Article string |
| **UDA** | Unique Digital Asset | Non-fungible (NFT) | EmbeddedMedia + Attachments + ProofOfReserves |
| **PFA** | Permissioned Fungible Asset | Fungible | Every transfer requires issuer's explicit signature (e.g. company shares) |

**Old names to avoid:** RGB20, RGB21, RGB25 — these do not exist in v0.11.1.

---

## Key concepts

**Client-side validation** — Asset state is validated by the asset owner off-chain,
not broadcast to all nodes. Parties exchange a *consignment* containing the full
history needed to validate.

**Single-use seal** — A promise to commit to an unknown message once and only once.
Bitcoin UTXOs act as seals; spending a UTXO closes the seal and anchors a state
transition.

**Commitment** — A cryptographic proof anchored to a Bitcoin transaction via one
of two DBC (Deterministic Bitcoin Commitment) methods:
- **Opret** — commitment in an OP_RETURN output
- **Tapret** — commitment in a Taproot output

**Schema** — A declarative template containing variables, rules, and business logic
for a contract. Analogous to a class in OOP. Compiled to a `.rgb` binary file.

**Genesis** — The initial contract operation that creates the contract and its
starting state. Equivalent of the Bitcoin genesis block at the client-side level.

**State transition** — The primary contract operation that moves or updates owned
state from one seal (UTXO) to another.

**Contract operation types:** Genesis, State Transition.
*(State Extension exists in the architecture but is not in the current supported schemas.)*

**Consignment** — The data package exchanged between parties. Two types:
- *Contract consignment*: includes Schema + Genesis (from issuer)
- *Transfer consignment*: full state transition history from Genesis to new unspent assignments

**Stash** — The local data structure storing contract state, schemas, and consignment
history on the user's device.

**AluVM** — Algorithmic Logic Unit Virtual Machine. Register-based VM for contract
validation logic embedded in schemas.

**MPC (Multi Protocol Commitment)** — A Merkle tree structure that allows a single
Bitcoin transaction to commit to multiple RGB contracts simultaneously.

**Anchor** — Client-side data proving the inclusion of a commitment inside a
Bitcoin transaction. Composed of four components: TxID + MPC Proof + DBC (commitment method: Opret or Tapret) + ETP (only for Tapret).

---

## Lightning Network

RGB state transitions can be committed inside Lightning commitment transactions,
enabling RGB asset-specific Lightning channels. Each channel update includes a new
RGB state transition. HTLCs work the same way as in standard Lightning, with the
HTLC output carrying both satoshis and RGB asset allocations.

Every RGB Lightning payment also moves satoshis — this is required to keep outputs
above the Bitcoin **dust limit**. If a commitment transaction output falls below dust,
it cannot be spent and the RGB allocation becomes inaccessible. UTXO management
is a critical responsibility for any RGB Lightning wallet developer.

Reference implementation: **rgb-lightning-node** (LDK-based, github.com/RGB-Tools/rgb-lightning-node),
used by KaleidoSwap, ThunderStack, LNFI, Iris Wallet desktop.

---

## Terminology rules

| Use | Avoid |
|-----|-------|
| "private contracts" | "smart contracts" |
| "RGB Protocol on Bitcoin" (first mention) | bare "RGB" without qualification |
| "supported by the RGB Protocol Association" | "maintained by" |
| NIA / IFA / CFA / UDA / PFA | RGB20 / RGB21 / RGB25 |
| docs.rgb.info | RGB-WG sources, rgb.tech |
| v0.11.1 (production, complete stack) | v0.12 (separate org, not production-ready) |

---

## Ecosystem (built on v0.11.1)

- **Iris Wallet** — mobile wallet, full RGB Lightning support
- **BitMask** — browser extension wallet
- **Tribe RGB** — RGB-compatible mobile wallet
- **KaleidoSwap** — DEX for RGB assets on Lightning
- **BiHelix** — app framework for issuing RGB assets on Bitcoin
- **ThunderStack** — cloud infrastructure for RGB Lightning nodes

**Tether/USDT:** In August 2025, Tether announced plans to launch USDT on RGB v0.11.1 —
the first Bitcoin-native stablecoin via client-side validation, no sidechains or bridges.

---

## Official repositories

**github.com/rgb-protocol** — core protocol:
- rgb-consensus, rgb-schemas, rgb-api, rgb-ops, rgb-aluvm, rgb-strict-encoding, rgb-strict-types, rgb-ascii-armor
- rgb-sandbox — hands-on regtest sandbox (uses rgb-cmd CLI from crates.io)

**github.com/RGB-Tools** — higher-level projects built on rgb-protocol:
- rgb-lib — primary wallet library (Rust + Python, Kotlin, Swift, Node.js bindings)
- rgb-lightning-node — LDK-based RGB Lightning node (used by KaleidoSwap, ThunderStack, LNFI)
- rgb-proxy-server — consignment transport server (recommended for production)
- iris-wallet-android, iris-wallet-desktop — reference wallet implementations

**Do not use:**
- github.com/RGB-WG — separate organization (rgb.tech / v0.12), not part of v0.11.1
- `rgb-node` — deprecated
- `rgb-wallet` — old architecture (pre-refactor)
- `rgb-cmd` — development and testing CLI only; use **rgb-lib** for production
- `rgb-core`, `rgb-std`, `bp-core` — RGB-WG crate names; not part of the rgb-protocol stack; do not use as dependencies

## Canonical sources

- https://rgb.info — homepage, concepts, education
- https://docs.rgb.info — full technical documentation
- https://docs.rgb.info/llms-full.txt — complete docs in LLM-readable format
- 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