Abstract / Overview
RGB is a client-side validation protocol for issuing and transferring digital assets anchored to Bitcoin transactions. State is held and verified by the participants, not by global consensus. Bitcoin acts as a commitment layer that timestamps and seals state transitions. Off-chain proofs called consignments carry all data required to validate an asset’s history. Taproot commitments and blinded outpoints preserve privacy and scalability.
This article explains the model, shows a practical end-to-end workflow for issuing and transferring an RGB20-style fungible asset, provides code and JSON snippets, and lists failure modes with fixes. Assumption: no keywords or hashtags were provided; proposed ones are appended.
Conceptual Background
Bitcoin UTXO model. Bitcoin tracks unspent outputs. RGB binds asset state to specific UTXOs, then updates state only when the bound UTXO is spent in a Bitcoin transaction that carries a cryptographic commitment to the new state.
Client-side validation. Every participant stores and validates the full history for the assets they hold. There is no global RGB mempool or miner enforcement. Validation checks: schema conformance, cryptographic signatures, and that the committed anchor appears on Bitcoin as required.
Single-use seals. An RGB assignment is bound to a seal, typically a Bitcoin UTXO. Spending that UTXO closes the seal exactly once. The new state binds to a new seal. This enforces non-duplication without global consensus.
Deterministic commitments. A state transition includes a commitment that is inserted into a Bitcoin transaction output or Taproot structure. The commitment lets verifiers prove that a particular Bitcoin transaction anchors a specific RGB transition without revealing the entire state on-chain.
Schemas and interfaces. Common schemas include fungible tokens (RGB20-style) and non-fungible collectibles (RGB21-style). A schema defines fields, rights, and transitions. Interfaces define how wallets expose those features.
Consignments. The sender delivers an off-chain package that includes genesis, all intermediate transitions, and anchors sufficient for the recipient to verify the chain of custody. Delivery can use any transport: file, message bus, or direct API.
Blinded UTXOs. The receiver advertises a blinded seal. It hides the exact outpoint that will hold the asset while allowing the sender to commit to it. This reduces linkability and front-running.
Lightning compatibility. RGB designs support anchoring transitions to transactions funding or updating Lightning channels. This enables fast settlement while anchoring finality to Bitcoin.
Diagram: lifecycle of an RGB
![Untitled diagram _ Mermaid Chart-2025-08-28-153934]()
Step-by-Step Walkthrough
Goal: issue a fungible asset on the Bitcoin testnet and transfer units to a recipient using blinded UTXOs. Tools are representative. Replace with your wallet or node tooling.
Assumptions
You operate a Bitcoin testnet node or a reliable testnet API.
You control a Taproot-capable wallet.
You can run an RGB-compatible CLI or library.
File system is available for consignments.
1) Prepare keys, addresses, and funding UTXO
2) Define the asset and create Genesis
Choose a fungible schema (RGB20-style). Decide ticker, name, precision, total supply, and issuer’s allocation.
The wallet or CLI will produce:
genesis: the initial state and rights.
contract_id: unique identifier derived from genesis.
anchor: a commitment plan to embed in a Bitcoin transaction.
3) Anchor the Genesis
4) Obtain a recipient invoice with a blinded seal
Receiver creates a blinded UTXO (for example a not-yet-revealed Taproot output tweaked with a secret).
Receiver sends an invoice containing contract_id, requested amount, and blinded seal.
5) Create and send the transfer consignment
Sender constructs a state transition that assigns amount to the receiver’s blinded seal.
Sender anchors the transition in a Bitcoin transaction and exports a consignment file.
Sender delivers the consignment to the receiver out-of-band.
6) Receiver validates and accepts
7) Ongoing operations
Backup stashes and consignments regularly. Without them you cannot prove ownership.
For further transfers, repeat steps 4–6 with new blinded seals.
Code / JSON Snippets
Minimal JSON for a fungible asset genesis (RGB20-style)
This illustrates fields often present in an RGB20-like schema. Adjust to your tool’s exact format.
{
"schema": "rgb20",
"genesis": {
"name": "Acme Credits",
"ticker": "ACME",
"precision": 2,
"description": "Utility credits for Acme services",
"contract_id": "c1f0...ab12",
"issued_supply": "1000000",
"allocations": [
{
"to_seal": "TXID0:0",
"amount": "1000000"
}
],
"terms": {
"reissue": false,
"burnable": true
}
}
}
Example of a blinded invoice (recipient → sender)
A typical invoice references the asset and a blinded seal.
{
"type": "rgb_invoice",
"contract_id": "c1f0...ab12",
"chain": "testnet",
"amount": "2500",
"blinded_seal": "VBlinded:1:tp1q...p7k",
"expiry_utc": "2025-12-31T23:59:59Z",
"note": "Payment for ticket #4821"
}
Example transfer plan (sender-side)
The sender plans a transition and an anchor. The anchor_psbt gets completed, signed, and broadcast.
{
"type": "rgb_transfer_plan",
"contract_id": "c1f0...ab12",
"inputs": [
{ "seal": "TXID0:0", "amount": "1000000" }
],
"outputs": [
{ "to_blinded_seal": "VBlinded:1:tp1q...p7k", "amount": "2500" },
{ "change_to_self": "TXID1:1", "amount": "997500" }
],
"anchor_psbt": "cHNidP8BAHECAAAAAf//////...",
"commitment_scheme": "taproot",
"expected_vsize_vb": 150,
"max_fee_sats": 9000
}
Minimal consignment outline (sender → receiver)
The consignment carries the proof chain needed to validate ownership.
{
"type": "rgb_consignment",
"format_version": "1",
"contract_id": "c1f0...ab12",
"genesis": { "...": "..." },
"transitions": [
{
"txid_anchor": "aabbcc...55",
"commitment_proof": "taproot-commitment-proof",
"assignments": [
{ "to_blinded_seal": "VBlinded:1:tp1q...p7k", "amount": "2500" }
],
"signatures": ["sig1..."]
}
],
"validation_index": {
"anchors": ["aabbcc...55"],
"utxo_graph": ["TXID0:0", "TXID2:0"]
}
}
Minimal Python sketch to compute a Taproot tweak for a commitment
This illustrates the pay-to-contract idea behind embedding an RGB commitment. Replace placeholders with your library calls.
# Requires a secp256k1 and BIP340-capable library; example uses pseudocode.
from hashlib import sha256
def tagged_hash(tag: str, msg: bytes) -> bytes:
t = sha256(tag.encode()).digest()
return sha256(t + t + msg).digest()
def tap_tweak(internal_pubkey: bytes, rgb_commitment: bytes) -> bytes:
tweak = int.from_bytes(tagged_hash("TapTweak", internal_pubkey + rgb_commitment), "big")
return tweak.to_bytes(32, "big")
# Example usage
internal_pubkey = bytes.fromhex("0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798")
rgb_commitment = sha256(b"RGB-state-transition-id").digest()
tweak = tap_tweak(internal_pubkey, rgb_commitment)
print(tweak.hex())
Diagram: data artifacts and flows
![Untitled diagram _ Mermaid Chart-2025-08-28-154137]()
Use Cases / Scenarios
Private fungible tokens for businesses. Loyalty points, credit units, or internal settlement instruments with off-chain privacy and on-chain finality.
NFTs with provenance anchored to Bitcoin. Unique collectibles or licenses where the art/data stays off-chain or in a content store, while the proof of ownership is client-validated.
Bitcoin-anchored DeFi primitives. Options, vouchers, or structured notes encoded as RGB rights and governed by off-chain contracts, anchored to Bitcoin transactions.
Lightning-accelerated settlement. Route payments with RGB assets over Lightning, where channels carry Taproot commitments to RGB updates. Finality anchors arrive with channel closes or periodic commits.
Supply chain attestations. Each handoff creates an RGB transition that attests custody with selective disclosure via consignments.
Limitations / Considerations
Operational maturity. Wallets, node software, and standards evolve. Test thoroughly on the testnet before mainnet use.
Backup burden. You must back up stashes and consignments. Losing them can make assets unspendable despite on-chain anchors.
Data transport. RGB relies on off-chain delivery of consignments. Plan for authenticated, reliable channels and retries.
Interoperability. Different wallets may lag in features or schema support. Prefer published interfaces and reference schemas.
Fee volatility. Anchors require Bitcoin transactions. High fee rates affect cost and timing.
Audit processes. Because validation is local, auditors need your consignments and stash. Establish export procedures for compliance.
Privacy tradeoffs. Blinded seals reduce linkability, but network metadata and timing still leak. Use Tor or private relays where appropriate.
Key management. Taproot keys and tweaks must be managed carefully. Mis-derivation breaks spendability.
Conclusion
RGB applies client-side validation, single-use seals, and deterministic commitments to move complex asset logic off-chain while anchoring to Bitcoin for immutability. The model scales by shifting computation and data to the endpoints and minimizes on-chain footprint without sacrificing verifiability. The operational burden moves to wallets and transports, so robust tooling, backups, and process discipline are essential. Use testnet to formalize your issuance and transfer pipelines, bake in audits and disaster recovery, and only then move to mainnet with controlled exposure. The result is asset issuance and transfer on Bitcoin with strong privacy, efficient fees, and verifiable provenance.