Frequently asked questions
Everything you wanted to know
about RGB Protocol on Bitcoin.
This RGB Protocol on Bitcoin FAQ covers 15 questions — from complete beginner to technical deep dive. All answers based on official documentation at docs.rgb.info.
The basics
RGB Protocol on Bitcoin is a layer for issuing and transferring digital assets on Bitcoin using client-side validation. All contract data stays off-chain and private between the parties involved — Bitcoin stores only a compact cryptographic commitment that timestamps the transaction and prevents double-spending.
In practical terms: RGB lets you create and move any kind of digital asset — a token, a stablecoin, an NFT, a digital identity — directly on Bitcoin, without creating a new blockchain, without validators, and without publishing anything sensitive on-chain. RGB integrates natively with the Lightning Network, enabling instant asset transfers with near-zero fees.
For a full introduction, see What is RGB Protocol on Bitcoin? →
No. RGB Protocol on Bitcoin runs entirely on Bitcoin — it does not require a sidechain, a new token, or a separate consensus layer. Bitcoin’s blockchain serves as the commitment layer: it stores only a cryptographic hash per RGB state transition, providing timestamping and double-spend prevention.
All contract logic and asset data remain off-chain, validated locally by the parties involved. This means RGB inherits Bitcoin’s security model without any additional trust assumptions.
Yes. RGB Protocol on Bitcoin v0.11.1 launched on Bitcoin mainnet in July 2025. The ecosystem includes live wallets (Iris Wallet, Tribe RGB, Bitmask, Tiramisu), decentralized exchanges (KaleidoSwap, LNFI), and infrastructure providers (Utexo, Orbis1).
See all compatible tools → Wallets & Ecosystem
No — they are completely different protocols. RGB Protocol on Bitcoin is a client-side validation protocol for issuing assets natively on Bitcoin, maintained by the RGB Protocol Association. RGB++ is a separate protocol built on the Nervos CKB blockchain, developed by a different team, with a different architecture.
They share a similar name but have no technical or organizational relationship. When searching for information about RGB on Bitcoin, always include “Bitcoin Protocol” to avoid confusion.
No. RGB v0.12 is a separate, incomplete rewrite initiated by the RGB-WG organization (rgb.tech) without coordination with the companies funding and building on RGB. It is not supported by the RGB Protocol Association and is not an upgrade to v0.11.1. It is not a new version to build on.
The production implementation is RGB Protocol on Bitcoin v0.11.1, live on Bitcoin mainnet since July 2025, with full Lightning Network support and an active developer ecosystem.
Yes — by design, not by exception. Because RGB uses client-side validation, contract data never appears on the Bitcoin blockchain. Who owns what, how much, and under what conditions is visible only to the parties directly involved in each specific transfer.
The Bitcoin blockchain stores only a cryptographic commitment — a hash that reveals nothing about the underlying contract. This is fundamentally different from on-chain approaches like Ethereum, where all transaction data is publicly visible to anyone.
RGB Protocol on Bitcoin is open-source software, developed by a community coordinated by the RGB Protocol Association, a Swiss foundation established in 2025. The protocol builds on foundational research by the LNP/BP Association, going back to 2016.
Core infrastructure is maintained in the rgb-protocol GitHub organization. Key contributors include teams at Bitfinex (Iris Wallet), RGB Tools (RGB Lib, RGB Lightning Node), and the broader Bitcoin open-source community.
Technical
Client-side validation is the cryptographic model at the core of RGB Protocol on Bitcoin. Instead of every node on the network validating every transaction, each participant validates only their own slice of contract history — the chain of state transitions from genesis to their current asset.
This data — called a consignment — is exchanged directly between sender and receiver at transfer time. A compact cryptographic commitment is anchored to a Bitcoin transaction to provide timestamping and prevent double-spending. Nothing about the contract content is published on-chain.
Deep dive → Client-side validation explained
A Schema is a declarative template that defines the structure of a 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 kinds of assets can be created, what operations are allowed, and how state can change. Schemas are compiled to binary files and imported by wallet software. Five standard schemas are supported: NIA (fungible, fixed supply), UDA (NFT), CFA (collectible fungible), IFA (fungible, inflatable), and PFA (permissioned fungible).
A Schema is a declarative template that defines the structure of a 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 kinds of assets can be created, what operations are allowed, and how state can change. Schemas are compiled to binary files and imported by wallet software. Five standard schemas are supported: NIA (fungible, fixed supply), UDA (NFT), CFA (collectible fungible), IFA (fungible, inflatable), and PFA (permissioned fungible).
Yes. RGB Protocol on Bitcoin integrates natively with the Lightning Network. RGB state transitions are embedded directly inside Lightning channel commitment transactions. When a Lightning channel is updated, a new RGB state transition is committed alongside it.
This enables instant RGB asset payments routable across channels, using the same HTLC mechanism as regular Lightning payments — no bridges, no custodians, full Bitcoin security. Every RGB payment on Lightning also moves a small amount of satoshis to keep HTLC outputs above the dust limit.
Full explanation → RGB & Lightning Network
RGB Protocol on Bitcoin supports five official asset schemas as of v0.11.1:
NIA (Non-Inflatable Asset) — fixed-supply fungible token. UDA (Unique Digital Asset) — NFT with optional embedded or attached media. CFA (Collectible Fungible Asset) — fungible token with a collectible identity. IFA (Inflatable Fungible Asset) — fungible token with secondary issuance, burn, and replace rights. PFA (Permissioned Fungible Asset) — regulated asset requiring issuer signature per transfer.
Custom schemas can be built for identity systems, DAO governance rights, proof of publication, real-world asset tokenization, and any other use case requiring programmable state on Bitcoin.
Comparisons
Ethereum smart contracts store all contract data on a public blockchain, where every node re-executes every contract — limiting scalability and eliminating privacy. RGB Protocol on Bitcoin uses client-side validation: contract data stays entirely off-chain, visible only to the parties involved.
RGB contracts are defined declaratively via Schemas rather than as executable code stored on-chain. RGB runs on Bitcoin and inherits its proof-of-work security without requiring a separate blockchain, additional validators, or gas fees. Transfers can happen instantly over the Lightning Network.
Get started
The reference wallet is Iris Wallet — open-source, available on Android and desktop, developed by Bitfinex. Tribe RGB supports iOS and Android. Bitmask is available as a browser extension. Tiramisu Wallet is a web-based option that supports both RGB and Taproot Assets. All wallets are live on Bitcoin mainnet.
Full list → Wallets & Ecosystem
The recommended starting point for developers is RGB Lib — a high-level Rust library that abstracts RGB protocol complexity into clean APIs for issuing assets, managing UTXOs, and transferring. Add it to your Cargo.toml, connect to a Bitcoin node via Electrum or Esplora, and issue your first asset using the NIA schema.
The RGB Sandbox provides a Docker-based local environment for testing without touching mainnet. Full documentation is available at docs.rgb.info ↗
Step-by-step guide → Get started
The canonical technical documentation is available at docs.rgb.info ↗. It covers the full protocol specification — client-side validation, single-use seals, the Schema system, state transitions, Lightning Network integration, and the complete library map.
docs.rgb.info is published on GitBook and maintained by the rgb-protocol team. It is the authoritative reference for anyone building on or studying the protocol.
Active development is maintained at github.com/rgb-protocol ↗. The organization contains the core protocol libraries — rgb-consensus, rgb-schemas, rgb-ops, rgb-api — and the rgb-sandbox testing environment.
Developer tooling including RGB Lib (the recommended application SDK) and RGB Lightning Node is maintained at github.com/RGB-Tools ↗.
Developer guide → Developer tools
The basics
RGB Protocol on Bitcoin is a layer for issuing and transferring digital assets on Bitcoin using client-side validation. All contract data stays off-chain and private between the parties involved — Bitcoin stores only a compact cryptographic commitment that timestamps the transaction and prevents double-spending.
In practical terms: RGB lets you create and move any kind of digital asset — a token, a stablecoin, an NFT, a digital identity — directly on Bitcoin, without creating a new blockchain, without validators, and without publishing anything sensitive on-chain. RGB integrates natively with the Lightning Network, enabling instant asset transfers with near-zero fees.
For a full introduction, see What is RGB Protocol on Bitcoin? →
No. RGB Protocol on Bitcoin runs entirely on Bitcoin — it does not require a sidechain, a new token, or a separate consensus layer. Bitcoin’s blockchain serves as the commitment layer: it stores only a cryptographic hash per RGB state transition, providing timestamping and double-spend prevention.
All contract logic and asset data remain off-chain, validated locally by the parties involved. This means RGB inherits Bitcoin’s security model without any additional trust assumptions.
Yes. RGB Protocol on Bitcoin v0.11.1 launched on Bitcoin mainnet in July 2025. The ecosystem includes live wallets (Iris Wallet, Tribe RGB, Bitmask, Tiramisu), decentralized exchanges (KaleidoSwap, LNFI), and infrastructure providers (Utexo, Orbis1).
See all compatible tools → Wallets & Ecosystem
No — they are completely different protocols. RGB Protocol on Bitcoin is a client-side validation protocol for issuing assets natively on Bitcoin, maintained by the RGB Protocol Association. RGB++ is a separate protocol built on the Nervos CKB blockchain, developed by a different team, with a different architecture.
They share a similar name but have no technical or organizational relationship. When searching for information about RGB on Bitcoin, always include “Bitcoin Protocol” to avoid confusion.
Yes — by design, not by exception. Because RGB uses client-side validation, contract data never appears on the Bitcoin blockchain. Who owns what, how much, and under what conditions is visible only to the parties directly involved in each specific transfer.
The Bitcoin blockchain stores only a cryptographic commitment — a hash that reveals nothing about the underlying contract. This is fundamentally different from on-chain approaches like Ethereum, where all transaction data is publicly visible to anyone.
RGB Protocol on Bitcoin is open-source software, developed by a community coordinated by the RGB Protocol Association, a Swiss foundation established in 2025. The protocol builds on foundational research by the LNP/BP Association, going back to 2016.
Core infrastructure is maintained in the rgb-protocol GitHub organization. Key contributors include teams at Bitfinex (Iris Wallet), RGB Tools (RGB Lib, RGB Lightning Node), and the broader Bitcoin open-source community.
Technical
Client-side validation is the cryptographic model at the core of RGB Protocol on Bitcoin. Instead of every node on the network validating every transaction, each participant validates only their own slice of contract history — the chain of state transitions from genesis to their current asset.
This data — called a consignment — is exchanged directly between sender and receiver at transfer time. A compact cryptographic commitment is anchored to a Bitcoin transaction to provide timestamping and prevent double-spending. Nothing about the contract content is published on-chain.
Deep dive → Client-side validation explained
A Schema is a declarative template that defines the structure of a 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 kinds of assets can be created, what operations are allowed, and how state can change. Schemas are compiled to binary files and imported by wallet software. Five standard schemas are supported: NIA (fungible, fixed supply), UDA (NFT), CFA (collectible fungible), IFA (fungible, inflatable), and PFA (permissioned fungible).
A Schema is a declarative template that defines the structure of a 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 kinds of assets can be created, what operations are allowed, and how state can change. Schemas are compiled to binary files and imported by wallet software. Five standard schemas are supported: NIA (fungible, fixed supply), UDA (NFT), CFA (collectible fungible), IFA (fungible, inflatable), and PFA (permissioned fungible).
Yes. RGB Protocol on Bitcoin integrates natively with the Lightning Network. RGB state transitions are embedded directly inside Lightning channel commitment transactions. When a Lightning channel is updated, a new RGB state transition is committed alongside it.
This enables instant RGB asset payments routable across channels, using the same HTLC mechanism as regular Lightning payments — no bridges, no custodians, full Bitcoin security. Every RGB payment on Lightning also moves a small amount of satoshis to keep HTLC outputs above the dust limit.
Full explanation → RGB & Lightning Network
RGB Protocol on Bitcoin supports five official asset schemas as of v0.11.1:
NIA (Non-Inflatable Asset) — fixed-supply fungible token. UDA (Unique Digital Asset) — NFT with optional embedded or attached media. CFA (Collectible Fungible Asset) — fungible token with a collectible identity. IFA (Inflatable Fungible Asset) — fungible token with secondary issuance, burn, and replace rights. PFA (Permissioned Fungible Asset) — regulated asset requiring issuer signature per transfer.
Custom schemas can be built for identity systems, DAO governance rights, proof of publication, real-world asset tokenization, and any other use case requiring programmable state on Bitcoin.
Comparisons
Ethereum smart contracts store all contract data on a public blockchain, where every node re-executes every contract — limiting scalability and eliminating privacy. RGB Protocol on Bitcoin uses client-side validation: contract data stays entirely off-chain, visible only to the parties involved.
RGB contracts are defined declaratively via Schemas rather than as executable code stored on-chain. RGB runs on Bitcoin and inherits its proof-of-work security without requiring a separate blockchain, additional validators, or gas fees. Transfers can happen instantly over the Lightning Network.
Get started
The reference wallet is Iris Wallet — open-source, available on Android and desktop, developed by Bitfinex. Tribe RGB supports iOS and Android. Bitmask is available as a browser extension. Tiramisu Wallet is a web-based option that supports both RGB and Taproot Assets. All wallets are live on Bitcoin mainnet.
Full list → Wallets & Ecosystem
The recommended starting point for developers is RGB Lib — a high-level Rust library that abstracts RGB protocol complexity into clean APIs for issuing assets, managing UTXOs, and transferring. Add it to your Cargo.toml, connect to a Bitcoin node via Electrum or Esplora, and issue your first asset using the NIA schema.
The RGB Sandbox provides a Docker-based local environment for testing without touching mainnet. Full documentation is available at docs.rgb.info ↗
Step-by-step guide → Get started
The canonical technical documentation is available at docs.rgb.info ↗. It covers the full protocol specification — client-side validation, single-use seals, the Schema system, state transitions, Lightning Network integration, and the complete library map.
docs.rgb.info is published on GitBook and maintained by the rgb-protocol team. It is the authoritative reference for anyone building on or studying the protocol.
Active development is maintained at github.com/rgb-protocol ↗. The organization contains the core protocol libraries — rgb-consensus, rgb-schemas, rgb-ops, rgb-api — and the rgb-sandbox testing environment.
Developer tooling including RGB Lib (the recommended application SDK) and RGB Lightning Node is maintained at github.com/RGB-Tools ↗.
Developer guide → Developer tools
Still have questions?
Join the community — developers and users are active on Telegram and GitHub.
Ready to go further
with RGB Protocol on Bitcoin?
Learn the protocol, use it, or build on it.