RGB Protocol for Bitcoin Smart Contracts and Tokens

Clients want private smart contracts but don't want to leave Bitcoin or move to sidechains. RGB Protocol solves this: state is stored with owners, while Bitcoin guarantees consensus. Our engineers develop solutions on RGB v0.11 — from simple tokens to Lightning integration. We have completed 30+ projects, saving clients up to 100x on transaction costs.

How client-side validation works in RGB

In RGB, consensus rules are executed not by network nodes but by clients. The token seller proves ownership history to the buyer by providing a chain of consignments from the genesis contract. The buyer validates each transition independently — without trusting a third party and without publishing data on the blockchain. This is a key difference from Ethereum: contract state never appears publicly.

Alice → Bob (RGB asset transfer): 1. Bob generates a UTXO "seal" (Bitcoin UTXO to which the RGB right will be attached) 2. Alice creates a state transition: "transfer N tokens to Bob's seal" 3. Alice creates a Bitcoin tx containing a commitment to the state transition 4. Alice sends Bob the consignment: state transition + history back to genesis 5. Bob validates: checks each transition, anchoring in Bitcoin 6. Bob confirms receipt 

Key point: the content of the state transition (how many tokens, to whom) never appears publicly. In the Bitcoin blockchain — only a 32-byte hash commitment. An external observer sees a Bitcoin transaction but doesn't know it contains an RGB transfer.

Why RGB is better than Ethereum for private tokens

RGB is justified when there are hard requirements for Bitcoin settlement and confidentiality; stable tokens without complex contract logic; Lightning-native applications; ideological requirement to work on Bitcoin. Compared to Ethereum, RGB wins in privacy (data is not public) and fees: for mass transfers, savings reach 100x due to no state publication cost. However, the ecosystem is still forming, and we take on all risks — we guarantee 3 months of support after delivery.

How to create an RGB20 token

RGB20 — standard for fungible tokens (analogous to ERC-20). Creating a new token via rgb-cli or programmatically via SDK:

use rgb_schemata::rgb20; use rgbstd::interface::rgb20::Rgb20; use rgbstd::stl::{Amount, Precision, RicardianContract}; let contract = rgb20::issue( ticker: "MYTKN", name: "My Token", precision: Precision::CentiMicro, // 8 decimal places issued_supply: Amount::from(1_000_000_00000000u64), seal: genesis_seal, terms: RicardianContract::new("Token Terms..."), )?; let contract_bytes = contract.to_strict_serialized::<{ u24::MAX as usize }>()?; 

For development, we use the RGB Core Library in Rust as the primary SDK. The high-level wrapper RGB Std provides interfaces for working with specific standards.

RGB21 — standard for unique assets with optional media attachments. Media files are stored off-chain, only the hash is in state.

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, )?; 

What's included in the work and guarantees

The process includes requirements analysis, security audit, schema design, contract development in Rust, Lightning integration (optional), wallet customization, testnet/mainnet deployment, documentation, and team training. We deliver:

• Source code of contracts (Rust) with tests
• Deployment and usage instructions
• Access to a private repository
• 2 hours of training for your developers
• 3 months of warranty support

Timelines: from 3 weeks for a basic token to 5 months for a custodial service with Lightning. Cost is calculated individually. Contact us — we will assess your project for free. Order an audit of your current prototype: we will find problems before production.

Wallet and state storage

To work with RGB assets, an RGB-aware wallet is required. A standard Bitcoin wallet does not see RGB balances. Existing implementations: Bitmask (web/mobile), BitLight (Lightning-first), MyCitadel (desktop from LNP/BP team). For server-side — integration via RGB Node or direct use of RGB Core.

RGB state is stored in a stash — the owner's local database. The stash contains all received consignments, history of state transitions, and necessary witness data.

let stash = RgbStash::new(stash_path, bitcoin_provider)?; let balance = stash.contract_state::<Rgb20>(contract_id)? .fungibles() .filter(|a| a.owner == my_seal) .sum(); 

Integration with Lightning Network: how it works

RGB-over-LN allows micropayments in RGB tokens over Lightning channels. Pay in USDC over Lightning in milliseconds — no bridges or wrapped tokens. Technically: HTLC is extended with an RGB state transition. During routing, the invoice encodes not only the satoshi amount but also the RGB asset transfer. Routing nodes see only regular HTLCs. Implementation: LDK with RGB extensions from Bitfinex (Iris project).

Comparison: RGB vs Ethereum for typical tasks

Tool table: what we use

Practical limitations and when to choose RGB

No public mempool visibility: RGB state is visible only to participants. This is a plus for privacy but a minus — no public block explorer. Verification works only with a full consignment. UTXO as seal: when spending a UTXO, you must explicitly transfer the RGB asset to a new output — a forgotten transfer means loss of asset. The ecosystem is still forming: tooling is less mature than Ethereum, documentation is incomplete. No EVM equivalent: AluVM is less expressive than Solidity; complex DeFi on RGB requires significant effort.

Choose RGB when: hard requirements for Bitcoin settlement and confidentiality; stable tokens (transfer, issuance, burn); Lightning-native applications; ideological choice of Bitcoin without sidechains. For DeFi, NFT marketplaces, DAO — Ethereum or L2 remain the right choice due to maturity.

Official RGB documentation: rgb.technology