接收方取得包含相关历史的 consignment，依据 genesis 与 schema 进行验证，并检查相应 state transitions 是否绑定到有效的 Bitcoin 交易。
RGB Protocol 建立在 Client-Side Validation 与 single-use seals 之上。Bitcoin 不复制合约的详细数据；参与者自行保存和验证，而 Bitcoin UTXO 与交易提供封条关闭的公开证据和防 double-spend 保障。 [6]
合约从 Genesis 操作开始，随后通过有向无环图中的 state transitions 演进。转换消耗先前的 owned state、创建新状态，并经由 anchor 将其 commitments 绑定到 Bitcoin witness transaction。 [3]
Schema 是业务逻辑的声明式模板：它规定数据类型、owned 与 global state、允许的操作和验证规则。Genesis 随后建立 schema 的具体实例，例如可替代或唯一资产的发行与初始分配。 [2]
转移时，发送方把含有 genesis、schema、相关历史和证明的 consignment 交给接收方。接收方在接受前，本地验证完整链条、anchors 及其与 Bitcoin 的关联；ticker 或钱包显示本身不是有效性证明。 [4]
公开发布页把 v0.10 标为稳定版，把 v0.11 系列标为预发布；beta 版也会提示 RGB 共识的变化，而非 Bitcoin 共识变化。因此生产使用需要整套客户端 stack 版本准确且彼此兼容，不能只凭笼统的“支持 RGB”。 [5]
RGB 这一名称脱离上下文并不明确。当前文档明确区分这里所述的 RGB Protocol on Bitcoin、尚未完成且不同的 v0.12 提案，以及 Nervos/CKB 上的 RGB++；缩写相同不代表架构相同或能够互操作。 [1]
隐私与扩展性伴随数据可用性成本。Bitcoin 无法从 commitment 重建遗失的 consignment；接收方必须取得完整的相关历史，所有者也必须安全备份 stash 及其他客户端数据。 [4]
评估 RGB 说法时，应核对协议与库的确切版本、schema 与 genesis、contract ID、commitment 类型、所支持层、consignment 完整性和审计状态。仅称 on Bitcoin 并不能证明互操作性、安全性或可恢复性。 [5]
要获得更完整的理解，请将本词条与以下词条结合阅读： Client-Side Validation, UTXO, Taproot, Lightning Network, Sidechain, Hash. 反向关联还来自： Taproot Assets, Runes.
01RGB 合约是否直接存储在 Bitcoin 区块链中？+
不是。Bitcoin 承载排序和关闭封条所需的交易与加密 commitments；详细状态和验证历史在客户端之间传递并由客户端保存。
02所有称为 RGB 的代币都彼此兼容吗？+
不会自动兼容。钱包必须支持具体的协议版本、schema、interface 与 commitment 流程。接受前应核验 contract ID 和完整 consignment，不能只看名称或 ticker。