What is RGB Protocol?
👋 New to this? Just start reading at the top — it begins in plain English and gets more detailed as you scroll. Jump to any level:
🟢 The simple version
Plain English — no jargon. Start here.
RGB Protocol is a smart contract system built on Bitcoin and the Lightning Network that uses "client-side validation" — keeping contract state and logic entirely off-chain, with only cryptographic commitments recorded in Bitcoin transactions — enabling scalable, private, and censorship-resistant contracts without bloating the Bitcoin blockchain.
The key insight: contracts don't need to be on-chain
Ethereum's approach: publish smart contract code and all contract state on the blockchain. Every node stores everything. Every execution is public. This is maximally verifiable but expensive and non-private. RGB's approach: only a cryptographic commitment (a hash) to a contract operation is embedded in a Bitcoin transaction. The actual contract code, state, and history are kept by the parties involved — "client-side."
When Alice transfers RGB tokens to Bob, Alice provides Bob with the complete history of those tokens — every previous ownership transfer, back to issuance. Bob validates this history himself. Only Bitcoin transactions containing tiny commitments appear on-chain. No contract code, no balances, no history is ever broadcast to the network. Validation is private, scalable, and does not require other nodes.
What RGB enables
RGB enables: fungible tokens (like ERC-20) on Bitcoin, non-fungible tokens (NFTs) on Bitcoin, complex financial contracts, decentralised identities, and any programmable logic — all without modifying Bitcoin's protocol and without a separate blockchain. RGB contracts can run on both Bitcoin's main layer and the Lightning Network (allowing instant, private token transfers).
Who develops RGB
RGB was designed by Peter Todd (2016) and significantly developed by Maxim Orlovsky and the LNP/BP Standards Association — a non-profit developing open standards for the Bitcoin and Lightning Network protocol layers. RGB v0.10 reached production readiness in 2023.
Is it relevant in India?
Yes. RGB tokens are assets on Bitcoin — VDA classification applies. See India regulation.
🟡 A bit more detail
For when you want to go a little deeper.
Client-side validation in practice
Understanding RGB requires understanding what "client-side validation" means concretely. In Ethereum: you can query any node to learn any token balance. In RGB: only the current token holder has the history proving they own the tokens. When they transfer to someone new, they hand over the proof — the new owner validates it themselves. This is analogous to physical cash: the cash itself is the proof of ownership, not a database entry.
RGB has been implemented in wallets including Iris Wallet (mobile) and Bitmask (browser extension). Several projects have issued fungible tokens and NFTs on RGB as a Bitcoin-native alternative to Ethereum ERC-20s. Lightning Network implementation allows RGB tokens to be transferred on Lightning channels — instant private token payments with no on-chain fees. The Taproot Assets protocol (by Lightning Labs) uses similar client-side validation concepts but with a different technical implementation. Financial institutions exploring Bitcoin-native tokenisation have evaluated RGB for its privacy and Bitcoin security properties.
Single-use seals — preventing double spends
RGB solves the double-spend problem for off-chain assets using "single-use seals" — a concept from Peter Todd's earlier work. A single-use seal is a promise that can be "opened" exactly once, and opening it is publicly observable. In Bitcoin, an unspent transaction output (UTXO) is a perfect single-use seal: it exists until it is spent, and the spending is publicly recorded. RGB binds token ownership to Bitcoin UTXOs — the tokens can only move when the corresponding UTXO is spent, and the RGB commitment in that spending transaction specifies where the tokens go next. Double-spending RGB tokens requires double-spending the Bitcoin UTXO — which Bitcoin's consensus prevents.
Key RGB metrics: wallet adoption, token issuance count, Lightning Network RGB channel adoption, and developer tooling maturity. RGB is technically sophisticated but has a steeper learning curve than EVM-based alternatives. The privacy and Bitcoin-alignment advantages appeal strongly to Bitcoin-native developers. Live data and ecosystem: rgb.tech · LNP-BP GitHub.
🟣 The full technical picture
For the technically curious.
RGB schema and contract architecture
An RGB contract is defined by a schema — a specification of the contract's data types, state transitions, and validation rules. The schema is like a class definition: it describes what the contract can do. A genesis operation instantiates a specific contract from a schema — like creating an object from a class. State transitions advance the contract state — transferring tokens, updating NFT metadata, etc. Each state transition commits to the new state using a deterministic hash embedded in a Bitcoin UTXO's witness data via Tapret (Taproot commitment) or OpRet (OP_RETURN commitment).
Source: LNP/BP Standards Association. rgb.tech/docs · RGB specifications: github.com/LNP-BP/LNPBPs
Strict type system and AluVM
RGB uses a strict type system — all data types in RGB contracts are precisely defined with no implicit conversions, making contracts more auditable and preventing a class of bugs common in loosely typed contract languages. Contract logic executes in AluVM (Algorithmic Logic Unit Virtual Machine) — a register-based virtual machine designed for deterministic, verifiable computation. AluVM programs are written in assembly language (human-readable) and compiled to bytecode. The VM is intentionally limited (not Turing-complete by default) for security — unbounded loops and unbounded recursion are not possible unless explicitly enabled by the schema definition.
RGB's Tapret commitment scheme: state transitions embed commitments in Taproot script trees. A Taproot output has a Merkle tree of scripts in its key path. RGB inserts its commitment as a leaf in this Merkle tree — indistinguishable from a regular Taproot output to external observers. The Tapret approach requires spending the UTXO to prove the commitment exists (revealing the Merkle proof), maintaining the privacy of commitments while ensuring their Bitcoin-level security. This is preferable to OP_RETURN commitments (which are publicly visible) for contracts where privacy is required.
Key facts
- Type: Bitcoin/Lightning smart contract system
- Validation: Client-side (off-chain, private)
- Bitcoin footprint: Only cryptographic commitment per transition
- Double-spend prevention: Single-use seals (Bitcoin UTXOs)
- VM: AluVM (register-based, limited by default)
- Designed by: Peter Todd (2016), developed by LNP/BP Association
- Production ready: RGB v0.10+ (2023)