RGB
- Name: RGB
- URL: https://rgb.tech/
- Category: bitcoin client-side validation smart-contract protocol / asset-and-rights infrastructure
- Tags: bitcoin-ecosystem
- Summary: RGB is worth cataloging not as just another Bitcoin asset layer, colored-coins reboot, or generic
smart contracts on Bitcoinslogan, but as the mechanism-rich reference stack for client-side-validated contracts on Bitcoin and Lightning. Its core move is to shift contract state and validation to contract participants, bind state transitions to Bitcoin outputs through single-use seals and deterministic commitments, and keep Bitcoin L1 mainly as a proof-of-publication and anti-double-spend ordering layer instead of a globally replicated contract VM. That makes RGB a useful comparison point because the real control surfaces become contract-history custody, commitment anchoring, schema and interface design, virtual-machine validation rules, and Lightning-channel update semantics rather than one flattenedtoken protocolstory. - What it does:
- Implements client-side-validated contracts and digital rights on top of Bitcoin, where each contract is effectively sharded and validated only by its participants rather than by every full node
- Uses single-use seals, anchors, and deterministic Bitcoin commitments such as Tapret/Opret-style commitments to tie offchain state transitions to Bitcoin transactions
- Provides a smart-contract stack with schemas, interfaces, global state, strict typing, and AluVM-based validation logic instead of limiting the system to simple fungible-asset issuance
- Treats privacy and scalability as consequences of moving contract state and history offchain, with only compact commitments needing to be reflected in Bitcoin transactions
- Extends the model to Lightning by letting RGB state transitions ride channel funding, commitment, and HTLC outputs so assets can move across channels with Bitcoin-backed unilateral-close and revocation semantics
- Ships a reference implementation and surrounding libraries so the protocol is not just a design paper but an implemented standards-oriented stack
- Key claims:
- RGB clears the bar because it exposes the full contract architecture beneath later Bitcoin asset apps. Without it, too many downstream systems get flattened into
Bitcoin tokenizationorLightning assetswithout showing where validation, state custody, and publication actually sit. - The most durable mechanism is the client-side-validation split itself: counterparties keep and validate relevant contract history, while Bitcoin provides publication ordering and single-use-seal enforcement rather than full semantic execution.
- The single-use-seal plus deterministic-commitment layer matters because it defines how offchain contract state inherits Bitcoin security properties. That layer is analytically more important than the product labels built on top of it.
- RGB is broader than a privacy or asset-transfer protocol because it adds contract schemas, interfaces, global state, and AluVM execution. That makes it a useful comparison point for
Bitcoin smart contractsclaims that otherwise hide whether a system is really a narrow asset format or a more expressive contract environment. - The Lightning compatibility docs are especially useful because they make channel-carried asset state legible: RGB balances move by updating commitment transactions and HTLC outputs, while the underlying satoshi amounts can stay economically minimal so long as they preserve spendability above dust.
- The project’s own release and repository materials also make protocol ossification an explicit theme: RGB v0.10 is described as the last consensus-breaking milestone before backward-compatible
fast-forwardevolution, and the core library frames v1 as an ossified protocol accepting only bug fixes. That governance posture is analytically important because client-side-validated upgrades are coordination-heavy even when they avoid L1 forks.
- RGB clears the bar because it exposes the full contract architecture beneath later Bitcoin asset apps. Without it, too many downstream systems get flattened into
- Whitepaper: The canonical primary paper is the
RGB Blackpaperathttps://black-paper.rgb.tech/. Supporting primary-source notes are collected in../whitepapers/rgb-primary-sources-2026-05-15.md. - Sources:
- https://rgb.tech/
- https://black-paper.rgb.tech/
- https://docs.rgb.info/
- https://docs.rgb.info/distributed-computing-concepts/client-side-validation
- https://docs.rgb.info/rgb-over-lightning-network/lightning-network-compatibility
- https://github.com/RGB-WG/rgb-core
- https://raw.githubusercontent.com/RGB-WG/rgb-core/master/README.md
- https://rgb.tech/blog/release-v0-10/
Internal linkages
-
Best comparison points: taproot-assets, mercury-layer, and ark.
-
Last reviewed: 2026-05-15 UTC