A recipient receives a consignment with the relevant history, validates it against the genesis and schema, and checks that the corresponding state transitions are bound to valid Bitcoin transactions.
RGB Protocol builds on Client-Side Validation and single-use seals. Bitcoin does not replicate the contract's detailed data; participants retain and validate it themselves, while Bitcoin UTXOs and transactions provide public evidence of seal closure and double-spend protection. [6]
A contract starts with a Genesis operation and then changes through state transitions in a directed acyclic graph. Transitions consume previous owned state, create new state, and bind their commitments through an anchor to a Bitcoin witness transaction. [3]
A schema is a declarative template for business logic: it defines data types, owned and global state, permitted operations, and validation rules. Genesis then creates a concrete instance of the schema, such as the issuance and initial allocations of a fungible or unique asset. [2]
For a transfer, the sender gives the recipient a consignment containing the genesis, schema, relevant history, and proofs. Before accepting it, the recipient locally validates the entire chain, its anchors, and its links to Bitcoin; a ticker or wallet display alone is not proof of validity. [4]
The public release overview labels v0.10 stable and the v0.11 line pre-release; beta releases also warn about changes to RGB consensus, not Bitcoin consensus. Production use therefore requires an exact, mutually compatible version of the whole client stack, not a generic claim of RGB support. [5]
The label RGB is ambiguous without context. Current documentation explicitly separates the described RGB Protocol on Bitcoin from the unfinished, different v0.12 proposal and from RGB++ on Nervos/CKB; the same acronym does not establish a common architecture or interoperability. [1]
Privacy and scaling come with a data-availability cost. Bitcoin cannot reconstruct a lost consignment from its commitment; the recipient must obtain the complete relevant history, and the owner must securely back up the stash and other client-side data. [4]
To assess an RGB claim, verify the exact protocol and library versions, schema and genesis, contract ID, commitment type, supported layer, consignment completeness, and audit status. The phrase on Bitcoin alone proves neither interoperability, safety, nor recoverability. [5]
For the clearest picture, read this entry together with Client-Side Validation, UTXO, Taproot, Lightning Network, Sidechain, Hash. The reverse links also lead from Taproot Assets, Runes.
01Are RGB contracts stored directly in the Bitcoin blockchain?+
No. Bitcoin carries the transactions and cryptographic commitments needed for ordering and seal closure; detailed state and validation history are transferred and stored client-side.
02Is every token called RGB mutually compatible?+
Not automatically. A wallet must support the specific protocol version, schema, interface, and commitment procedure. Before accepting it, verify the contract ID and full consignment rather than only a name or ticker.