Developing RGB Protocol Solutions (Bitcoin)
RGB is a protocol for smart contracts and tokens on Bitcoin and Lightning Network, developed by LNP/BP Standards Association. Unlike Ethereum where contracts and their state are stored publicly in blockchain, RGB stores contract state off-chain with owners of assets. Bitcoin is used exclusively as anchor for commitments: state hash is hidden in transaction via OP_RETURN or taproot output. This is fundamentally different model — privacy-preserving, scalable, but requiring developer understanding of client-side validation.
Client-Side Validation: Key Concept
In RGB, consensus rules are enforced not by network nodes, but by clients. Token seller proves to buyer the history of ownership transition from genesis contract, providing chain of consignments. Buyer independently validates each transition per contract rules — without trusting third party and without publishing data to blockchain.
Alice → Bob (RGB asset transfer):
1. Bob generates UTXO "seal" (Bitcoin UTXO where RGB right attaches)
2. Alice creates state transition: "transfer N tokens to Bob's seal"
3. Alice creates Bitcoin tx containing commitment to state transition
4. Alice delivers Bob consignment: state transition + history to genesis
5. Bob validates: checks each transition, anchoring in Bitcoin
6. Bob confirms receipt
Key point: state transition content (how many tokens, to whom) never appears publicly. In Bitcoin blockchain — only 32-byte commitment hash. External observer sees Bitcoin transaction but doesn't know what it contains RGB.
RGB Protocol v0.11: Current State
RGB has traveled long path through unstable early versions. Current production-ready version — RGB v0.11 (released 2024). Main changes from v0.10:
- AluVM — new virtual machine for executing RGB smart contracts
- Strict Types — type system with deterministic serialization
- RGB Schema — declarative contract type description
- Improved Lightning integration (RGB-over-LN)
RGB20: Fungible Tokens
RGB20 is standard for fungible tokens (ERC-20 equivalent). Creating new token via rgb-cli or programmatically via SDK:
use rgb_schemata::rgb20;
use rgbstd::interface::rgb20::Rgb20;
use rgbstd::stl::{Amount, Precision, RicardianContract};
// Define genesis contract
let contract = rgb20::issue(
ticker: "MYTKN",
name: "My Token",
precision: Precision::CentiMicro, // 8 decimals
issued_supply: Amount::from(1_000_000_00000000u64), // 1M tokens
seal: genesis_seal, // Bitcoin UTXO where all tokens go in genesis
terms: RicardianContract::new("Token Terms..."),
)?;
// Serialize contract for publication
let contract_bytes = contract.to_strict_serialized::<{ u24::MAX as usize }>()?;
For development use RGB Core Library in Rust as primary SDK. High-level wrapper RGB Std provides interfaces for specific standards (RGB20, RGB21).
RGB21: NFTs and Collectibles
RGB21 is standard for unique assets with optional media embeddings. Feature: media files aren't stored on-chain or in Bitcoin — only file hash in state. File itself — with owner or any storage (IPFS, Arweave, centralized).
use rgb_schemata::rgb21;
let nft = rgb21::issue_unique(
name: "Rare Art #1",
token_id: TokenId::from_random(),
media: Some(EmbeddedMedia {
media_type: MediaType::from("image/png"),
data: SmallBlob::try_from(image_bytes)?,
}),
seal: nft_genesis_seal,
)?;
Wallet and State Management
Working with RGB assets requires RGB-aware wallet. Standard Bitcoin wallet doesn't see RGB balances — doesn't know about RGB protocol.
Existing implementations:
- Bitmask — web/mobile wallet with RGB support
- BitLight — Lightning-first RGB wallet
- MyCitadel — desktop wallet from LNP/BP team
For server side (custodial service, exchange) — integration via RGB Node and its RPC API or direct use of RGB Core Rust library.
State Storage
RGB state stored in stash — owner's local database. Stash contains:
- All received consignments
- History of state transitions of your assets
- Necessary witness data for future transitions
// Initialize stash
let stash = RgbStash::new(stash_path, bitcoin_provider)?;
// Get RGB20 token balance by contract
let balance = stash.contract_state::<Rgb20>(contract_id)?
.fungibles()
.filter(|a| a.owner == my_seal)
.sum();
RGB Over Lightning
One of RGB's key advantages — native Lightning integration. RGB-over-LN enables micropayments in RGB tokens over Lightning channels. Payment in USDC over Lightning in milliseconds — what RGB-LN makes possible without bridges and wrapped tokens.
Technically: Lightning HTLC extends with RGB state transition. During routing, BOLT-11 invoice encodes not just satoshi amount, but RGB asset transfer. Routing nodes don't see RGB data — route ordinary HTLC.
Implementation: LDK (Lightning Development Kit) with RGB extensions from Bitfinex (project Iris). This is actively developed area, not all edge cases of LN are compatible with RGB in v0.11.
Practical Limitations
No public mempool visibility: RGB state invisible to anyone except participants. Privacy feature, but also means — no public block explorer for RGB. Verification works only with full consignment.
UTXO as seal: RGB ownership rights tied to Bitcoin UTXO. When spending UTXO, must explicitly transfer RGB asset to new output — forgotten RGB transfer = permanent asset loss. Requires RGB-aware wallet, normal Bitcoin wallet will "lose" RGB tokens on UTXO spend.
Ecosystem still forming: RGB v0.11 is stable version, but tooling (IDE support, debugging) significantly less mature than Ethereum. Documentation incomplete, most examples in Rust library tests.
No EVM equivalent: RGB smart contracts (AluVM) are low-level and less expressive than Solidity. Complex DeFi logic on RGB requires significantly more effort.
When to Choose RGB
RGB justified when: hard Bitcoin settlement and confidentiality requirements; stable tokens without complex contract logic (transfer, issuance, burn); Lightning-native applications; ideological requirement to work in Bitcoin without alternative L1.
For most DeFi applications, NFT marketplaces, DAOs — Ethereum or its L2 remain right choice due to ecosystem maturity. RGB is right choice for Bitcoin-native financial instruments.
Stack
- Rust — only production-ready language for RGB (official library)
- RGB Core + RGB Std — main dependencies
- Bitcoin Core or Electrum Server — Bitcoin backend
- LND/CLN with RGB patches — for Lightning functionality
Developing basic RGB20 token with issuance, transfer, and verification via CLI — 2–3 weeks. Custodial service with RGB wallet, API, and Lightning integration — 3–5 months, accounting for deep protocol immersion needed.