RGB Protocol

What Is RGB Protocol?

The RGB Protocol is a smart contract system that runs on top of Bitcoin and the Lightning Network. Rather than executing contracts on a global shared ledger the way Ethereum does, RGB uses client-side validation: each participant validates only the contract history relevant to their own assets. Bitcoin itself serves as a timestamping and commitment layer, anchoring small cryptographic proofs while all contract logic, state, and data remain entirely off-chain.

The protocol was originally conceived by Giacomo Zucco around 2016-2018, then substantially redesigned and developed by Dr. Maxim Orlovsky and the LNP/BP Standards Association, a Swiss non-profit that maintains the RGB specification and reference implementation. RGB reached its first production-ready release (v0.10) in April 2023, with v0.11 launching on Bitcoin mainnet in 2025. For a deeper technical analysis, see our RGB protocol research article.

How It Works

RGB rests on three core cryptographic primitives: client-side validation, single-use seals, and deterministic Bitcoin commitments. Together, these allow RGB to run complex smart contracts while leaving almost no footprint on the Bitcoin blockchain.

Client-Side Validation

In traditional blockchains, every node validates every transaction. This provides consensus but creates scalability and privacy problems. RGB reverses this model: only the parties directly involved in a transaction validate its correctness.

When a user receives an RGB asset, they receive a "consignment" containing the full chain of state transitions from the original issuance (called the "genesis") to the current owner. The receiver validates this chain locally, checking that every transition followed the contract's rules and committed to a valid Bitcoin transaction. No global network of validators is needed.

Single-Use Seals

Single-use seals, a concept proposed by Peter Todd, are RGB's mechanism for preventing double-spending. Each piece of contract state is bound to a specific Bitcoin UTXO via a seal definition. When the owner wants to transition that state (for example, transferring tokens), they spend the UTXO in a Bitcoin transaction. Spending the UTXO "closes" the seal permanently: that particular state can never be reassigned again.

Because Bitcoin's proof-of-work consensus prevents any UTXO from being spent twice, RGB inherits Bitcoin's own double-spend protection. Reversing an RGB state transition would require reversing a confirmed Bitcoin transaction.

Deterministic Bitcoin Commitments

RGB anchors its state transitions to Bitcoin using one of two commitment methods. A witness transaction uses either method, never both:

• Opret: places a 32-byte commitment hash in an OP_RETURN output. This is simpler to implement and works with any Bitcoin transaction, but creates a visible (though unspendable) extra output.
• Tapret: embeds the commitment inside the script tree of a Taproot output. The transaction looks identical to any other Taproot spend, providing superior privacy. No additional output is needed.

Both methods use a Multi-Protocol Commitment (MPC) layer built on a Merkle tree structure. This allows multiple RGB contracts, or even other protocols, to share a single commitment slot in one Bitcoin transaction.

The Transfer Flow

A typical RGB asset transfer works as follows:

1. Bob wants to receive tokens. He creates an invoice containing a seal definition that points to one of his UTXOs (optionally blinded for privacy).
2. Alice constructs a state transition that reassigns ownership from her UTXO to Bob's.
3. Alice builds a Bitcoin transaction (the "witness transaction") that spends her UTXO and embeds an Opret or Tapret commitment to the state transition.
4. Alice sends Bob a consignment containing the state transition and its full history. Bob validates the entire chain client-side.
5. The witness transaction is broadcast to Bitcoin. Once confirmed, the transfer is final.

AluVM

RGB executes smart contract logic using AluVM (Algorithmic Logic Unit Virtual Machine), a register-based virtual machine designed by Maxim Orlovsky to be deterministic and platform-independent. AluVM processes the validation rules defined in contract schemata, enabling programmable logic beyond simple token transfers. Contract rules are expressed through formal schemas that define allowed state types, transition rules, and metadata structures.

Token Standards

RGB defines its asset types through "schemata" (formal contract specifications). Three primary token schemata exist:

RGB-20 supports issuance with configurable supply (fixed or with reserved future issuance rights), transfers, and burning. Tether has explored issuing USDT via RGB-20, which would bring a major fiat-backed stablecoin to Bitcoin natively. For more on this landscape, see our research on stablecoins on Bitcoin.

Privacy Properties

RGB provides privacy properties that are fundamentally stronger than most blockchain smart contract platforms:

• Contract data never touches the blockchain. Only cryptographic commitments (hashes) are anchored on Bitcoin. An observer cannot determine what assets are being transferred, what contracts exist, or who the parties are.
• State transition data is exchanged peer-to-peer between sender and receiver. No network broadcast occurs.
• There is no global state. Each participant only knows about transitions relevant to their own assets.
• Blinded UTXOs allow receivers to conceal which Bitcoin UTXO they are using, so even the sender may not know the receiver's exact on-chain position.
• With Tapret commitments, RGB transactions are indistinguishable from regular Taproot transactions on-chain.

RGB and the Lightning Network

RGB was designed from the ground up to be compatible with the Lightning Network. The goal is to enable RGB asset transfers (such as stablecoins) over Lightning payment channels, achieving near-instant, low-fee token transfers without leaving Bitcoin.

The LNP/BP Association has been developing Bifrost, a protocol extension that modifies Lightning's channel state machine to accommodate RGB state transitions alongside standard Bitcoin payments. In theory, a Lightning channel can carry both BTC and RGB assets simultaneously, with RGB transfers settling at Lightning speed.

As of 2025, RGB over Lightning remains an active area of development. The theoretical framework and proof-of-concept work exist, but full production-ready RGB-on-Lightning is not yet widely deployed. For context on how RGB fits into the broader scaling landscape, see our Bitcoin scaling comparison.

Use Cases

Token Issuance on Bitcoin

RGB enables issuing fungible tokens, NFTs, and complex financial instruments directly on Bitcoin without requiring a separate chain. Unlike BRC-20 tokens (which rely on Ordinals inscriptions), RGB tokens leave no visible data on-chain, preserving privacy and minimizing blockchain bloat.

Stablecoins on Bitcoin

RGB-20 tokens can represent fiat-backed stablecoins issued natively on Bitcoin. Tether's exploration of USDT on RGB signals demand for bringing dollar-denominated assets to Bitcoin without relying on sidechains or bridges. Combined with Lightning compatibility, this could enable instant stablecoin payments over Bitcoin's payment network.

Confidential Smart Contracts

Because contract state stays between the involved parties, RGB enables use cases where privacy is essential: private equity issuance, confidential supply chain tracking, or any scenario where counterparties need programmable logic without public disclosure.

Why It Matters

RGB represents a fundamentally different approach to smart contracts on Bitcoin. Rather than building a global execution layer (as rollups and sidechains do), RGB keeps everything local and private, using Bitcoin purely for its security guarantees. This philosophy aligns with Bitcoin's emphasis on decentralization and individual sovereignty.

For the broader Bitcoin Layer 2 ecosystem, RGB offers a path to programmable assets that doesn't require changes to Bitcoin's consensus rules or trust in federated operators. Projects like Spark share this commitment to extending Bitcoin's capabilities while preserving self-custody and trustlessness.

Risks and Considerations

Ecosystem Maturity

RGB is still in relatively early stages of ecosystem development. While the core protocol reached production readiness with v0.10 and advanced with v0.11, the wallet ecosystem, tooling, and developer documentation are less mature than those of Ethereum-based smart contract platforms. The number of applications built on RGB remains small compared to more established Layer 2 solutions.

Data Availability

Because RGB stores all contract data off-chain, users must preserve their own state history. If a user loses their consignment data (the chain of state transitions proving ownership), recovering assets may be impossible. There is no global ledger to fall back on. This places a significant responsibility on wallet software and backup practices.

Interoperability

RGB's client-side validation model means that each contract is a separate shard with no shared global state. While this provides scalability and privacy, it makes cross-contract interactions more complex than on platforms with a shared execution environment. Composability patterns familiar from DeFi on Ethereum do not translate directly.

Lightning Integration Complexity

Full RGB-over-Lightning support requires changes to channel management and state machines. The Bifrost protocol extends Lightning to handle RGB state transitions, but integrating this with existing Lightning implementations (LND, Core Lightning, Eclair) is nontrivial. Widespread Lightning-based RGB asset routing is not yet a reality.

Complexity of Validation

Receivers must validate the full state transition history back to the genesis. For assets that have been transferred many times, this history grows linearly. Long-lived, frequently traded assets could eventually present validation performance challenges, though the sharded nature of contracts limits the scope of what any single user must verify.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.