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

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

1) Prepare keys, addresses, and funding UTXO

2) Define the asset and create Genesis

3) Anchor the Genesis

4) Obtain a recipient invoice with a blinded seal

5) Create and send the transfer consignment

6) Receiver validates and accepts

7) Ongoing operations

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

Limitations / Considerations

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.