What is RGB Protocol on Bitcoin? A complete guide

Disclaimer: for education purposes some of the concepts described in this article have been simplified, and to avoid overwhelming the reader with new terms also the terminology may differ from technical specifications.

There is a growing interest in the issuance of digital assets on top of Bitcoin and Lightning Network, but most approaches required compromises that do not harmonize with Bitcoin’s principles: on-chain data bloat, loss of privacy, or reliance on federated systems that introduce new trust assumptions. RGB Protocol on Bitcoin takes a different path.

RGB Protocol on Bitcoin is an open-source protocol for issuing and transferring digital assets natively on Bitcoin and Lightning Network, without the need to use sidechains or to apply changes to Bitcoin’s base layer. All asset data stays private and off-chain, while Bitcoin is used only as a commitment layer for tamper-proof anchoring.

In brief:

• Issues and transfers digital assets natively on Bitcoin and Lightning
• Asset data stays private and off-chain; only a small cryptographic commitment is anchored to Bitcoin
• Official source: rgb.info · Technical documentation: docs.rgb.info

Contents

1. Why Do You Need a Separate Protocol to Issue Assets on Bitcoin?
2. How Does RGB Protocol on Bitcoin Work? Client-Side Validation
3. How Does RGB Prevent Double-Spending? Single-Use Seals
4. What Happens Step by Step in an RGB Transfer?
5. How Does RGB Protocol on Bitcoin Protect Recipient Privacy?
6. How Do RGB Assets Work on the Lightning Network?
7. Does RGB Protocol on Bitcoin Support Smart Contracts?
8. What Can You Issue on RGB Protocol on Bitcoin?
9. How Does RGB Compare to Taproot Assets, Liquid, and Ethereum?
10. How Do I Start Building on RGB Protocol on Bitcoin?

Why Do You Need a Separate Protocol to Issue Assets on Bitcoin?

The Bitcoin’s blockchain is excellent for creating a tamper-proof record of ownership that anyone can verify without trusting third parties. But extending that model to digital assets beyond Bitcoin itself has historically run into structural problems.

Earlier approaches to assets on Bitcoin, like Colored Coins, Counterparty, OmniLayer, stored asset data on-chain. In particular, the first generation of asset protocols embedded asset metadata directly into Bitcoin transactions, typically inside OP_RETURN outputs. Every asset transfer was written permanently on-chain, and it was visible to anyone.

This approach created three compounding issues:

Blockchain burden. Every asset transfer adds data that every node must store forever, regardless of whether they care about that asset. At scale, it threatens decentralization by raising the cost of running a full node.

No privacy. Every transfer is permanently visible. Anyone can see who sent what to whom, in what amount, at what time. For financial assets, it eliminates a fundamental property.

Poor scalability. Verifying ownership requires scanning the entire blockchain from genesis, which is an increasingly expensive operation considering the growth of the chain.

Ethereum’s ERC-20 standard chose a different path: a separate global state machine where every node executes every contract publicly. This system enabled programmable finance at scale, but at the cost of privacy, Bitcoin’s security model, and meaningful decentralization.

RGB Protocol on Bitcoin takes a fundamentally different approach.

How Does RGB Protocol on Bitcoin Work? Client-Side Validation

RGB Protocol on Bitcoin works through client-side validation: the parties involved in a transfer validate asset data privately between themselves, while the Bitcoin blockchain only receives a small cryptographic commitment.

The fundamental idea is to use the Bitcoin blockchain only for what it does best, i.e. providing proof-of-work-backed finality and censorship-resistant settlement. Asset ownership records, contract rules, and transfer history can all be handled off-chain, between the parties directly involved. The blockchain only needs to know that something happened; it does not need to know what specifically did.

As a consequence, every byte of data does not need to be validated by everyone. In fact, Bitcoin’s global consensus is necessary to prevent double-spending without a trusted intermediary, but for other types of information (asset contract rules, wallet balances, transfer history) there is no reason to inform the entire network.

We can take a notarized private document as an example. The notary (Bitcoin) confirms that a specific event happened at a specific time, and that no one can deny it. But the contents of the document remain entirely between the parties involved.

RGB Protocol design solves all three problems at once:

• No asset data on-chain → no blockchain burden
• Transfers are invisible to outside observers → privacy by default
• Validation is local and parallel → scalable to any volume

How Does RGB Prevent Double-Spending? Single-Use Seals

RGB Protocol on Bitcoin prevents double-spending with single-use seals. Every RGB asset is bound to a Bitcoin UTXO: spending it authorizes the transfer, which makes double-spending impossible without double-spending Bitcoin itself.

Single-use seals are a cryptographic primitive proposed by Peter Todd. His formal definition:

“A promise to commit to a yet unknown message in the future, once and only once, such that the fact of commitment is demonstrably known to all members of a certain audience.”

The implementation in RGB implies that every RGB asset is bound to a specific Bitcoin UTXO (Unspent Transaction Output). To transfer the asset, the sender must spend that UTXO in a Bitcoin transaction. Spending the UTXO “closes” the seal and authorizes a state transition.

Bitcoin’s own proof-of-work enforces that an UTXO can only be spent once. So even though Bitcoin doesn’t know anything about the RGB asset attached to it, it still guarantees the seal can only be closed once. You cannot double-spend an RGB asset without double-spending the underlying Bitcoin UTXO (which the entire Bitcoin network would immediately reject).

The Bitcoin blockchain acts as an immutable anchor for every RGB state transition, without storing any RGB data at all.

What Happens Step by Step in an RGB Transfer?

An RGB transfer consists of five steps: the sender prepares a consignment with the full asset history, sends it off-chain to the recipient, who validates it locally; the sender then broadcasts a Bitcoin transaction carrying only a small cryptographic commitment.

1. The consignment. The sender prepares a Transfer Consignment, i.e. a data package containing the complete history of the asset’s state transitions from genesis to the current transfer, plus an unsigned witness transaction. This information is everything the recipient needs in order to verify ownership independently, without trusting any third party.
2. Off-chain transmission. The consignment is sent through an off-chain channel, typically via an RGB proxy server, but the protocol also supports email, messaging apps, QR codes, or Nostr relays. This way, the asset data never touches the Bitcoin blockchain.
3. Recipient validates. The recipient validates the consignment locally. They check the entire chain of state transitions, verifying that each one is anchored to a real Bitcoin transaction, and confirming seals were correctly closed.
4. The Bitcoin commitment. The Bitcoin transaction that closes the seal contains a Deterministic Bitcoin Commitment (DBC), encoded in one of two ways:
   • Opret: a 34-byte commitment (OP_RETURN + OP_PUSHBYTE_32 + 32-byte MPC hash) placed in the first OP_RETURN output of the transaction;
     Tapret: a 64-byte commitment embedded inside the Script Path Spend of a Taproot transaction.
   • In both cases, no asset data touches the blockchain
5. Transition bundles. Multiple state transitions of the same contract within one Bitcoin transaction are grouped into a Transition Bundle, allowing multiple transfers to share a single on-chain commitment. This feature is an important key to push scalability.

The UTXO receiving the asset completely unrelated on-chain with the Bitcoin transaction committing to the transfer. This property has direct implications for recipient privacy, as we are about to analyze in the next paragraph.

How Does RGB Protocol on Bitcoin Protect Recipient Privacy?

RGB Protocol on Bitcoin protects recipient privacy using concealed seals: the recipient provides a cryptographic commitment to their UTXO rather than the UTXO itself, so the sender never learns which output holds the transferred asset.

When Bob wants to receive an RGB asset, he doesn’t send Alice his exact UTXO. Instead, he provides a concealed seal, meaning a cryptographic commitment to his UTXO that hides the actual output from Alice. Alice embeds this concealed seal in the state transition she constructs.

The result is that RGB tokens can effectively teleport from one UTXO to another without leaving any visible trail in the Bitcoin transaction graph. Alice cannot determine which UTXO holds the asset she just sent. Even if she monitors the blockchain, she cannot link the RGB commitment to Bob’s specific coins.

When Bob later transfers the asset to Carol, he must reveal his seal to Carol, as she needs it to verify the chain of custody. Privacy is therefore strongest at the most recent transfer and gradually decreases for earlier ones as seals are revealed forward through the chain. This choice is a deliberate trade-off: there is privacy at the point of transfer, with a verifiable audit trail for the recipient.

How Do RGB Assets Work on the Lightning Network?

RGB assets work natively on the Lightning Network: they can be held in payment channels alongside satoshis and transferred instantly, inheriting all of Lightning’s security guarantees, which includes instant settlement and no on-chain confirmation per transfer.

Opening an RGB channel starts with a standard Bitcoin funding transaction that creates the 2-of-2 multisig UTXO, as it happens with any Lightning channel. The RGB assets are then assigned to that UTXO via an RGB state transition. The amount of satoshis in the channel doesn’t have to be large in comparison to the asset value being transferred, but it cannot be negligible, either. The amount of sats should be sufficient to make the punishment mechanism economically meaningful and to keep HTLC outputs above Bitcoin’s dust limit.

As the channel updates, new commitment transactions are created with modified RGB state transitions reflecting revised asset balances. The RGB input is always the original funding multisig where assets are allocated on-chain, until channel closure.

Why every RGB Lightning payment also moves satoshis:

This requirement has two specific functions rooted in Lightning’s security model.

Punishment mechanism. If a party broadcasts an old channel state, the counterparty can spend the output using revocation secrets, claiming both satoshis and RGB assets. The satoshi amount ensures economic penalties extend to all locked value.

HTLC requirements. Each routed payment requires HTLC outputs containing satoshis above Bitcoin’s dust limit. The dual transfer (satoshis + RGB asset) ensures that whether the HTLC resolves via preimage or timelock, both bitcoin and the RGB allocation can be claimed.

Does RGB Protocol on Bitcoin Support Smart Contracts?

Yes. RGB Protocol on Bitcoin supports programmable contracts through AluVM (Algorithmic Logic Unit Virtual Machine), a register-based virtual machine that executes contract logic privately on the machines of the parties involved, not publicly on the global network.

Unlike Ethereum’s EVM, where every node executes every contract publicly, AluVM runs validation off-chain. Only the result (whether a state transition is valid) is committed to Bitcoin. The computation and its inputs remain entirely private.

AluVM scripts are embedded inside schemas and executed during client-side validation. Schemas use a purely declarative approach: they define the rules and business logic of a contract without that logic becoming part of the global state or visible to any third party.

As a consequence, RGB contracts can express complex conditions like transfer restrictions, permissioned issuance, and multi-party authorizations without any of that logic being public or executable by the network.

One edge case: if a state transition fails client-side validation, but the corresponding Bitcoin transaction was already broadcast, the UTXO seal is closed with no valid state transition assigned. The asset is effectively burned. Well-designed wallets using rgb-lib handle this issue through careful transaction construction before broadcast.

What Can You Issue on RGB Protocol on Bitcoin?

RGB Protocol on Bitcoin v0.11.1 supports five asset types, called schemas: NIA (fixed-supply fungible), IFA (inflatable fungible), UDA (non-fungible), CFA (collectible fungible), and PFA (permissioned fungible).

Schemas are declarative templates that encode the complete rules of a contract: what states exist, how genesis is structured, what transitions are possible, and what AluVM validation logic applies. They compile into .rgb (binary) or .rgba (armored binary) files for wallet integration.

The five officially supported schemas in v0.11.1 are the following:

• NIA — Non-Inflatable Asset
  • A fungible token with a hard-capped supply. No additional units can ever be created after genesis. It’s the Bitcoin monetary model applied to any asset.
  • Use cases: Bitcoin-equivalent tokens, fixed-supply loyalty points, tokenized commodities with a fixed redemption pool, in-game currencies.
• IFA — Inflatable Fungible Asset
  • A fungible token with a defined supply ceiling. Supports Inflate (mints new units), Burn (provably remove supply), and Link (a one-time operation to connect to a successor contract).
  • Use cases: stablecoins, rewards tokens with scheduled emission, voucher programs
• UDA — Unique Digital Asset
  • A non-fungible asset. Each UDA can carry embedded media (up to 64 KiB binary blob) or attached files referenced by hash digest. Transfer is limited to a single destination.
  • Use cases: digital certificates, event tickets, collectibles, verifiable credentials.
• CFA — Collectible Fungible Asset
  • Extends NIA with an article label per issuance, identifying each batch within a collectible series.
  • Use cases: limited edition art series, numbered prints, sports card collections, vintage batches identified by year or edition.
• PFA — Permissioned Fungible Asset
  • A fungible, non-inflatable token where every transfer must include an explicit cryptographic signature from the issuer in the transaction metadata.
  • Use cases: tokenized equities, regulated stablecoins requiring issuer approval, compliance-restricted tokens, tokenized real estate shares.

How Does RGB Protocol on Bitcoin Compare to Taproot Assets, Liquid, and Ethereum?

RGB Protocol on Bitcoin offers higher privacy and scalability than Taproot Assets, Liquid, and Ethereum ERC-20, because it is the only approach that keeps all asset data off-chain through client-side validation.

Protocol	Where it runs	Privacy	Scalability	Decentralized	Status
RGB Protocol on Bitcoin	Bitcoin + Lightning	High off-chain, client-side	High no blockchain bloating	Full Bitcoin security	Mainnet since July 2025
Taproot Assets	Bitcoin + Lightning	Partial	Medium	Full Bitcoin security	Mainnet, single-company
Liquid Network	Bitcoin sidechain	Confidential transactions	Medium	Federated Multisig	Production, trust assumptions
Ethereum ERC-20	Ethereum	None – fully public	Limited by block size	Separate security model	Mature, high DeFi adoption

RGB++ is not RGB Protocol on Bitcoin. RGB++ is a separate protocol developed by the Nervos/CKB team, running on the CKB blockchain. It’s a project handled by a different team, on a different architecture, with no connection to RGB Protocol on Bitcoin.

How Do I Start Building on RGB Protocol on Bitcoin?

Concepts: start with Client-Side Validation and Single-Use Seals
Build a wallet with rgb-lib using Rust and Python bindings
Run a Lightning node with rgb-lightning-node
Try the CLI on testnet with a guided sandbox environment
Core protocol: github.com/rgb-protocol
Glossary: docs.rgb.info/annexes/glossary

Article written by Federico Tenga