RGB is best understood as a post-blockchain smart-contract system rather than a narrow token layer. The blackpaper explicitly frames it as a client-side-validation architecture that separates contract state and operations from consensus.
The protocol’s core mechanism is that each contract is effectively its own shard, held and validated by participants rather than replayed by every node. Bitcoin remains the publication and anti-double-spend substrate through commitment anchoring and single-use seals.
The docs make the scalability/privacy argument unusually clean. Only compact commitments need to hit Bitcoin, while the contract history and state stay offchain with counterparties. That makes RGB a useful baseline for any later Bitcoin system that claims privacy or throughput by moving semantics away from L1.
RGB is broader than a simple asset protocol because the stack includes schemas, interfaces, global state, strict typing, and AluVM-based validation. The project materials are explicit that the target surface includes tokens, NFTs, DeFi, DAOs, and other rights-bearing contracts.
The Lightning docs are especially analytically useful: RGB state transitions can be embedded in funding and commitment transactions and associated HTLC outputs, so channel updates move RGB balances while inheriting unilateral-close and punishment semantics from Lightning. The satoshi amounts can be economically small, but they still anchor spendable outputs above dust.
The repository and release notes also surface a governance property worth keeping: RGB aims at ossification. The v0.10 post describes it as the last consensus-breaking milestone, and the core library README says RGBv1 is intended to become immutable except for bug fixes accepted under broad consensus.
Specific source signals worth retaining
black-paper.rgb.tech: best concise statement of RGB’s full ambition — client-side-validated contracts, standalone contract shards, Bitcoin/L2 compatibility, privacy by keeping history offchain, and AluVM programmability.
docs.rgb.info overview: useful for the layered decomposition of the protocol into distributed-computing concepts, commitment layer, contract operations, schemas, and Lightning compatibility.
client-side-validation page: strongest explanation of why RGB treats L1 as proof-of-publication plus ordering, and why recipients only need the shard of history relevant to them.
lightning-network-compatibility page: important because it makes the RGB-over-Lightning control surface concrete: funding UTXOs, RGB allocations to commitment outputs, revocation-based punishment, and HTLC-carried asset routing.
rgb-core README: clarifies that RGB is tied to consensus-critical libraries around client-side validation, Bitcoin commitments, and AluVM, and that the project sees itself as standards-oriented and moving toward ossification.
release-v0-10 post: useful for release-history context, explicit discussion of interfaces/global state/strict types, and the project’s own stated upgrade path through backward-compatible fast-forward evolution.
Why this entry belongs in the corpus
RGB gives the corpus the reference mechanism page for Bitcoin client-side-validated contracts rather than leaving the topic scattered across downstream wallets, asset issuers, or comparison notes.
It sharpens comparison against Shielded CSV, zkCoins, Mercury Layer, Taproot-anchored asset systems, and Lightning-adjacent payment layers by making participant-held history, seal-closing, commitment anchoring, contract expressiveness, and Lightning update semantics explicit.
The durable insight is that Bitcoin smart contracts can be decomposed into at least five separate layers: who stores history, who validates state transitions, how state is committed into Bitcoin, how contract logic is expressed, and whether offchain transport like Lightning carries state updates between publication events.