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. RGB Protocol on Bitcoin v0.11.1 is the production release, live on Bitcoin mainnet since July 2025, with wallets, exchanges, and infrastructure built on it. In September 2026, the five core libraries dropped the release-candidate tag with the final 0.11.1 release.
The code is under active maintenance in the open: security issues reported by external researchers get fixed in public releases, as in RC11 and v0.11.2-rc.1, with the related tests published in the rgb-protocol ↗ repositories. As with any software that handles value, test on regtest or testnet first and keep your dependencies up to date.
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 its open-source contributors and supported by the RGB Protocol Association, a Swiss non-profit association established in July 2025. The protocol builds on research that began in 2016, when Peter Todd presented client-side validation and single-use seals at Scaling Bitcoin Milan.
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.
The RGB Protocol Association is a Swiss non-profit association, founded in July 2025, that supports the RGB Protocol on Bitcoin ecosystem through grants, education, community events, and coordination among the companies building on RGB.
The Association does not write or maintain the protocol code: the development of RGB Protocol on Bitcoin takes place in the open-source rgb-protocol ↗ GitHub organization. More on the Association at rgbprotocol.org ↗.
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 implemented: NIA (fungible, fixed supply), UDA (NFT), CFA (collectible fungible), IFA (fungible, inflatable), and PFA (permissioned fungible). IFA and PFA are not yet production-ready.
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 implemented: NIA (fungible, fixed supply), UDA (NFT), CFA (collectible fungible), IFA (fungible, inflatable), and PFA (permissioned fungible). IFA and PFA are not yet production-ready.
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 has five official asset schemas as of v0.11.1 (IFA and PFA are not yet production-ready, and rgb-lib does not allow IFA on mainnet):
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 link operations. 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.
Yes. In August 2025, Tether announced its plan to bring USD₮ to RGB Protocol on Bitcoin, for transfers of USD₮ on Bitcoin and on the Lightning Network. Read the Tether announcement.
In August 2026, RGB Lightning support also entered Tether’s Wallet Development Kit (WDK), through a module developed by Utexo. More in RGB Lightning Is Now in Tether’s WDK.
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.
rgb.info is the official website of RGB Protocol on Bitcoin, the v0.11.1 production line live on Bitcoin mainnet. Together with docs.rgb.info ↗ and the rgb-protocol ↗ GitHub organization, rgb.info forms the documentation set for the protocol supported by the RGB Protocol Association.
rgb.tech belongs to the RGB-WG organization and presents v0.12, an unfinished proposal to rewrite the protocol, with no compatibility with v0.11.1. Developers building on RGB Protocol on Bitcoin should follow rgb.info and docs.rgb.info. More in Debunking the Myths About RGB Protocol on Bitcoin.
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.
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. RGB Protocol on Bitcoin v0.11.1 is the production release, live on Bitcoin mainnet since July 2025, with wallets, exchanges, and infrastructure built on it. In September 2026, the five core libraries dropped the release-candidate tag with the final 0.11.1 release.
The code is under active maintenance in the open: security issues reported by external researchers get fixed in public releases, as in RC11 and v0.11.2-rc.1, with the related tests published in the rgb-protocol ↗ repositories. As with any software that handles value, test on regtest or testnet first and keep your dependencies up to date.
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 its open-source contributors and supported by the RGB Protocol Association, a Swiss non-profit association established in July 2025. The protocol builds on research that began in 2016, when Peter Todd presented client-side validation and single-use seals at Scaling Bitcoin Milan.
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.
The RGB Protocol Association is a Swiss non-profit association, founded in July 2025, that supports the RGB Protocol on Bitcoin ecosystem through grants, education, community events, and coordination among the companies building on RGB.
The Association does not write or maintain the protocol code: the development of RGB Protocol on Bitcoin takes place in the open-source rgb-protocol ↗ GitHub organization. More on the Association at rgbprotocol.org ↗.
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 implemented: NIA (fungible, fixed supply), UDA (NFT), CFA (collectible fungible), IFA (fungible, inflatable), and PFA (permissioned fungible). IFA and PFA are not yet production-ready.
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 implemented: NIA (fungible, fixed supply), UDA (NFT), CFA (collectible fungible), IFA (fungible, inflatable), and PFA (permissioned fungible). IFA and PFA are not yet production-ready.
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 has five official asset schemas as of v0.11.1 (IFA and PFA are not yet production-ready, and rgb-lib does not allow IFA on mainnet):
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 link operations. 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.
Yes. In August 2025, Tether announced its plan to bring USD₮ to RGB Protocol on Bitcoin, for transfers of USD₮ on Bitcoin and on the Lightning Network. Read the Tether announcement.
In August 2026, RGB Lightning support also entered Tether’s Wallet Development Kit (WDK), through a module developed by Utexo. More in RGB Lightning Is Now in Tether’s WDK.
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.
rgb.info is the official website of RGB Protocol on Bitcoin, the v0.11.1 production line live on Bitcoin mainnet. Together with docs.rgb.info ↗ and the rgb-protocol ↗ GitHub organization, rgb.info forms the documentation set for the protocol supported by the RGB Protocol Association.
rgb.tech belongs to the RGB-WG organization and presents v0.12, an unfinished proposal to rewrite the protocol, with no compatibility with v0.11.1. Developers building on RGB Protocol on Bitcoin should follow rgb.info and docs.rgb.info. More in Debunking the Myths About RGB Protocol on Bitcoin.
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.