G GOPNIK ACADEMY
Bitcoin 101 — Initiate · Lesson 4 of 5

RGB — Bitcoin-native tokens via client-side validation

5 min · read

Back to course

Bitcoin doesn't have a smart-contract VM the way Ethereum does. That means stablecoins, NFTs, and other tokens can't natively live on Bitcoin — unless you take a fundamentally different approach to validation.

RGB is that approach. Instead of every node validating every token transfer (the Ethereum model), each token's validity is checked client-side by the wallets holding it. The Bitcoin chain is used only to anchor which transitions happened; the actual asset state lives in off-chain consignments that the wallet validates.

This is a young protocol (production-ready around 2025), but it's the canonical answer to "Bitcoin tokens without the Liquid sidechain or wrapping."

How issuance works

When you issue an RGB token:

  1. You define a schema — the rules that govern transfers (RGB-20 for fungibles, RGB-21 for collectibles, RGB-25 for engineered behaviour)
  2. You bind the issuance to a Bitcoin UTXO via a genesis transaction — the on-chain tx becomes the issuance's permanent commitment
  3. You pre-sign a consignment describing the initial allocation — typically "all supply to me, the issuer"

After issuance, the token exists. Holders accept it by validating the consignment trail client-side; if the math + schema rules hold, they accept the asset as real.

This is fundamentally different from Ethereum's ERC-20. There's no contract address. There's no global state. There's a Bitcoin tx + a consignment trail, and any wallet can verify it independently.

How transfers work

A transfer:

  1. Recipient creates an RGB invoice — a string declaring "send me X of asset Y to this commitment"
  2. Sender's wallet builds a consignment describing the transition (input UTXOs spent, output amounts created)
  3. Sender signs + broadcasts a Bitcoin tx that anchors the transition (typically a small "vanilla" tx; the value is in the consignment, not the Bitcoin amount)
  4. Sender hands the consignment to the recipient via the indexer or a direct channel
  5. Recipient validates client-side and accepts

The Bitcoin chain doesn't see the asset amounts — only that a transition happened. This is also a privacy feature: an observer of the Bitcoin chain sees "wallet X did a small tx with wallet Y" but doesn't know what asset or amount moved.

Iter-F's RGB surface

Three operations:

  • List holdings. The wallet reads from the rgb-lib indexer (Bitfinex hosts a public one; production deploys self-host). Cached for 60 seconds; refresh on user click.
  • Issue. RGB-20 (fungible) or RGB-21 (collectible). The wallet binds the issuance to your BIP-84 UTXO, records the genesis tx_id, persists the issuance log.
  • Transfer. Consume a recipient's RGB invoice; produce a consignment + anchor on-chain.

The wallet does not in iter-F:

  • Issue RGB-25 (engineered schemas with custom logic) — pending validation of the schema-evaluation surface
  • Accept consignments from untrusted indexers — every consignment is validated against your local rgb-lib state
  • Participate in RGB Lightning payments — that protocol is still evolving

Risks specific to RGB

Indexer dependency. RGB read-side needs an indexer. If the indexer is malicious it can't make you accept invalid consignments (you still validate client-side), but it can hide ones that exist. Defence: cross-check with a second indexer for high-value transfers.

Asset-loss via UTXO mismanagement. RGB consignments are bound to specific Bitcoin UTXOs. If you spend the wrong UTXO with a non-RGB-aware tool, your RGB allocation tied to it is gone. The wallet's send code marks RGB-bound UTXOs as off-limits to the on-chain coin selector; never spend Bitcoin UTXOs from this wallet using an external tool unless you understand RGB.

Schema complexity. RGB-21 (collectibles) supports rich metadata. Reading metadata from an arbitrary issuer is a deserialisation surface — treat it with the same suspicion as an arbitrary JSON blob from the internet.

What you commit to

  • RGB is a client-side-validation protocol; Bitcoin only anchors that a transition happened, not what
  • The wallet supports RGB-20 + RGB-21 issuance + transfer; RGB-25 is deferred
  • RGB-bound UTXOs are reserved by the wallet; don't spend them externally
  • Indexer trust is partial (it can hide consignments but can't forge them)

The final lesson covers custody discipline — the cold / warm / hot tiering for Bitcoin holdings.