From RGB to RGB++, Reimagining the Potential of CKB as a Bitcoin Layer2 and Off-Chain Settlement Layer
TechFlow Selected TechFlow Selected
From RGB to RGB++, Reimagining the Potential of CKB as a Bitcoin Layer2 and Off-Chain Settlement Layer
RGB++ essentially trades privacy for usability, while enabling scenarios that the RGB protocol cannot achieve.
Navigating Web3 tides with focused insightsAuthor: Shew, Faust, Geek web3
Advisor: CyberOrange, Unipass
Abstract (lengthy): RGB is a promising BTC scaling protocol, essentially a off-chain computation system that adopts a concept similar to the Lightning Network: users personally verify and authorize asset changes related to themselves ("Verify by yourself"), then submit the results or commitments accepted by transaction initiators onto the Bitcoin chain.
-
RGB leverages ideas partially resembling those of Colored Coins and Mastercoin, associating "parasitic assets" with Bitcoin UTXOs. It stores Commitments of off-chain transaction data on the Bitcoin blockchain, rather than publishing full DA data like the Ordinals protocol. Based on commitment values recorded on-chain, RGB clients can verify whether the historical RGB data provided by other clients is valid.
-
Moreover, hash/commitment alone cannot reconstruct the underlying preimage; outsiders cannot directly observe the off-chain data corresponding to on-chain commitments, thus protecting privacy. Compared to inscriptions, storing only commitments saves space. From a third-party perspective, it's unclear what exactly RGB clients are doing.
-
RGB also exploits Bitcoin’s one-time spendable UTXO property through a mechanism called “one-time seal,” linking ownership of RGB assets to Bitcoin UTXOs. This leverages Bitcoin’s strong security to prevent double-spending of RGB assets (as long as Bitcoin UTXOs aren’t double-spent, RGB assets won’t be either).
-
However, as an off-chain smart contract system built atop Bitcoin, RGB relies on individual clients locally storing historical data, with each client holding only data relevant to itself and unable to see others’ asset states. While this “data silo” protects privacy, it creates challenges for large-scale adoption, making RGB more akin to a P2P network composed of OTC traders.
-
The idea behind RGB++ is to use Cells on the CKB chain to represent ownership relationships of RGB assets. It moves asset data originally stored locally in RGB clients onto the CKB chain via Cells, establishing a one-to-one mapping between these Cells and Bitcoin UTXOs. CKB acts as a public database and off-chain pre-settlement layer for RGB assets, replacing individual RGB clients to enable more reliable data custody and contract interactions. This “isomorphic binding” trend is emerging among UTXO-based Layer2 solutions.
-
The original RGB protocol only supports interactive transfer flows requiring frequent communication between parties, making DeFi scenarios difficult to support and hindering RGB asset issuance. With CKB replacing standalone clients, non-interactive RGB transactions become possible, facilitating DeFi deployment, airdrops, and enabling BTC assets to interact directly with CKB chain assets without cross-chain bridging.
-
RGB++ essentially trades privacy for usability while enabling new use cases impossible under the original RGB protocol. Users prioritizing simplicity and functionality will favor RGB++; those valuing privacy and “Verify by yourself” security will stick to traditional RGB—ultimately a matter of personal preference. (In theory, RGB++ could later address privacy concerns using ZK methods.)
Principles, Advantages, and Disadvantages of the RGB Protocol
The RGB protocol is inherently complex. We’ll explain how it works using a concrete example of an RGB asset transfer.
Suppose there exists a token compliant with the RGB standard called TEST. Alice wants Bob to send her 100 TEST tokens—in other words, create a Bob→Alice token transfer.
First, understand that RGB uses a concept known as “one-time encapsulation.” Although superficially described as Bob sending to Alice, it actually means Bob controls Bitcoin UTXO A, which is linked via certain mechanisms to some RGB assets.
If Bob declares he wishes to assign part of the RGB assets tied to UTXO A to Alice, he might state: transfer 30 TEST tokens associated with UTXO A to be linked with UTXO B. Since Alice owns UTXO B, she gains control over those 30 TEST tokens.
(Image source: Discoco Labs)
In reality, Bitcoin records ownership through UTXOs. Declaring that UTXO B qualifies to control a certain amount of RGB assets equates to saying its owner controls that quantity—an attribute unique to Bitcoin and other UTXO-based blockchains, differing from conventional account-address models.
With this understanding, we now examine the workflow of the RGB protocol and highlight differences from earlier UTXO parasitic asset schemes such as Colored Coins and Mastercoin:
1. According to RGB principles, Alice must first issue an invoice specifying her intent. The invoice includes the following information:
-
Contract ID: Specifies which RGB asset contract Alice intends to interact with
-
Interface: Allows Bob to understand all interaction interfaces of the contract
-
Operation: Indicates which contract interface function Bob should invoke
-
State: The contract state Bob needs to modify—in this case, the number of tokens Bob sends to Alice
-
Seal: A UTXO used for one-time sealing, simply understood as the UTXO Alice uses to receive authorization for RGB assets from Bob.
Finally, Alice receives an invoice structured as follows:
This invoice follows the format below:
2. Alice must send this invoice to Bob. Bob checks the invoice details and generates a new RGB transaction according to Alice’s request, transferring the RGB assets to her.
Crucially, Bob must prove he actually owns some TEST assets. Why? Because the RGB protocol assumes no globally visible asset state record—unlike Ethereum, where a public custodial contract tracks everyone’s balances.
Under RGB, different clients store only data relevant to themselves—their current balance and transaction history—and each holds slightly different records. Thus, no one can independently verify another’s holdings, necessitating proof during P2P trades.
To put it vividly: you’re trading paper cash, but don’t know if the bills are counterfeit. You demand the counterparty explain their origin and transfer path to confirm legitimacy.
Once both parties mutually acknowledge validity, they can transact confidently. Each RGB transaction requires only mutual consent—fully peer-to-peer (similar to OTC).
Clearly, this model enhances privacy—individual asset positions and transaction histories remain hidden from outside observers. What you do with your counterparty stays private, much like cash being more anonymous than bank transfers. However, this comes at the cost of user experience.
In the Alice-Bob scenario above, after receiving Alice’s invoice and understanding her intent, Bob selects relevant historical TEST transaction records from his local client storage (Stash), combines them with the newly generated Bob→Alice transfer, and submits everything to Alice for validation—proving the legitimacy of the proposed ownership change.
Typically, local client data is referred to as “Stash,” containing past RGB asset data. Think of Stash as a logbook for RGB asset contracts.
3. Upon receiving data and the new Bob→Alice transaction declaration from Bob, Alice verifies its validity. If verified successfully, Alice generates a “confirmation signature” and returns it to Bob.
4. After receiving Alice’s confirmation signature, Bob broadcasts the Commitment of the Bob→Alice transaction to the BTC network, eventually writing it onto the BTC chain to achieve finality.
(Commitment structure diagram—essentially a Merkle root)
If the Bob→Alice transfer declares that the owner of UTXO B will possess 30 TEST tokens, then Alice can use these tokens once she proves ownership of UTXO B.
5. In the future, when Alice wants to transfer TEST tokens to someone else, she provides their historical provenance. The recipient can verify against the commitment value on the Bitcoin chain whether Alice’s data matches the on-chain commitment, preventing forgery.
The advantage of the RGB protocol lies in supporting complex smart contract computations off-chain. It essentially shifts computation off the BTC chain, recording only Commitments on-chain, thereby protecting privacy while declaring associations between Bitcoin UTXOs and RGB asset ownerships—leveraging Bitcoin to timestamp and enforce RGB ownership changes.
Since all transaction declarations require verification and authorization by involved parties, its security model rests on the “rational actor assumption”: as long as participants act rationally and Bitcoin remains secure, RGB asset ownership remains “basically secure.”
However, RGB has obvious drawbacks (previously mentioned issues around data silos and fragmented storage). First, to send funds, recipients often need prior agreement and confirmation—both parties typically need to be online simultaneously.
Second, due to lack of globally visible data logging, even contract publication takes unusual forms—users must obtain interface details directly from creators via email or QR codes. (Based on current official statements, posting code on a homepage or pinning tweets may also work.)
Now let’s explore RGB contract states. Within RGB, the initial contract state (Genesis) is set by the creator upon creation—for instance, token name and total supply in an RGB-20 contract. Subsequently, contract states evolve incrementally with ongoing RGB transactions, but this evolution is nonlinear, forming a Directed Acyclic Graph (DAG).
(Owner1 sees blue and green sections; Owner2 sees blue and yellow sections)
For example, when Bob transfers to Alice, he only reveals the transaction history from contract initialization up to his receipt of tokens—a narrow data path. Alice likewise only learns about this branch’s transactions, not others’. While this protects user privacy, it causes problems: users struggle to grasp global contract states, such as who holds how many RGB assets—leading to complications.
For instance, once the final step of a Bob→Alice transfer is irreversible on-chain, Bob may delete local data—if he transferred all his TEST tokens, he can remove related local data to reduce storage burden.
Meanwhile, Alice must retain complete data involved in the transaction. (What if Bob deletes his TEST data and Alice’s node suffers catastrophic failure? Her assets would be permanently frozen—unless backed up beforehand—since no other place stores her TEST asset data.)
This fundamentally boils down to DA and data storage issues: RGB-generated data lacks a reliable, globally visible dissemination method, causing clients to become isolated “data islands.” Earlier Plasma solutions in the Ethereum ecosystem suffered similarly and were ultimately abandoned due to unresolved DA problems.
Additionally, RGB requires extensive communication between parties, often relying on centralized infrastructure. Details here remain immature—even suggesting email as a viable option.
Clearly, RGB’s design isn’t user-friendly for casual, long-tail users. Wealthy users with high privacy demands may willingly maintain backups and run clients, but average users find these burdens excessive, severely limiting mass adoption. To date, few notable RGB assets have emerged.
Below is a flowchart illustrating the RGB asset transfer process, helping readers better understand the overall procedure.
In short, RGB leverages Bitcoin UTXOs to manage RGB asset ownership changes, securing off-chain data integrity by publishing Commitments on-chain so clients cannot privately alter data. Effectively, RGB’s “one-time seal” links Bitcoin UTXOs with RGB asset ownerships off-chain, harnessing Bitcoin’s robust security to protect RGB assets. However, due to DA and data storage limitations, the original RGB protocol suffers poor usability, UX, and risks asset freezing from data loss.
RGB++: Enhanced RGB Protocol Based on CKB
Earlier, we summarized RGB’s strengths and weaknesses. Data silos and lack of global contract visibility are the primary factors affecting usability.
Indeed, RGB’s pros and cons are clear-cut. Privacy-conscious users will prefer running their own clients and maintaining backups, while casual users clearly lack such patience (e.g., most Lightning Network users rely on third-party nodes rather than self-hosting).
Given this, Nervos co-founder Cipher proposed RGB++, aiming to delegate RGB asset state management, contract publishing, and transaction validation to the CKB blockchain. CKB serves as a third-party data custodian and computing platform, eliminating the need for users to run RGB clients.
CKB uses an extended UTXO model (Cell), allowing RGB off-chain information to be written into Cells and establishing one-to-one mappings between Cells and Bitcoin UTXOs—creating a CKB-based RGB data custody and verification solution addressing usability issues as an enhancement to the original RGB scheme.
This may sound complicated—let’s elaborate further:
As previously noted, RGB links Bitcoin UTXOs with RGB asset ownership via on-chain commitments and off-chain declarations. But RGB contract data is fragmented across clients’ local storages, lacking a unified global view.
RGB++ uses CKB’s extended UTXO—Cell—to directly display the mapping between Bitcoin UTXOs and corresponding RGB assets on-chain. CKB replaces users’ P2P clients, validating every RGB transfer’s legitimacy.
With globally visible RGB data records, many scenarios previously unfeasible under RGB become achievable.
(RGB++ transaction flow: write RGB asset info into Cell, link Cell with Bitcoin UTXO, include both the RGB++ transaction on CKB and the associated Bitcoin UTXO in the Commitment, then write the Commitment to Bitcoin chain)
Some might immediately think of EVM. Can EVM host RGB state and validation? Answer: It’s cumbersome. RGB assets inherently parasitize Bitcoin UTXOs, maintaining strict one-to-one mappings. Technically, linking Bitcoin UTXOs with EVM contract data is awkward compared to choosing a native UTXO chain.
Furthermore, “assets” on Ethereum are typically pool-based public goods, with one contract tracking countless users’ balances. Contract owners wield absolute power—an approach conflicting sharply with Bitcoin UTXO and RGB philosophies, which emphasize complete asset privatization and individual control (think cash vs. WeChat Pay). This avoids recurring Ethereum/EVM issues: contract owner abuse, bugs leading to fund losses, and complex data migration procedures.
(From previous Geek web3 article: "Tech Circle Celebrity Xiangma: High-performance Public Chains Struggle to Innovate, Smart Contracts Involve Power Distribution")
Thus, expressing smooth mappings between Bitcoin UTXOs and off-chain RGB assets is best achieved via a UTXO chain. CKB supports extended UTXO—Cell—and its VM instruction set is RISC-V based, making it easier than EVM to support diverse cryptographic algorithms—including Bitcoin’s public-private key verification—making it ideal for implementing RGB++’s technical vision.
Technical Implementation of RGB++
RGB++ utilizes CKB’s extended UTXO—Cell. A Cell contains the following fields:
Capacity indicates the on-chain storage size of the Cell; data refers to the dataset within the Cell, readable or modifiable.
Type binds program code to the Cell, restricting conditions under which data can be modified. For example, if your Cell holds data for 100 TEST tokens, attempting to transfer 110 TEST violates Type-defined rules and gets rejected.
Lock represents ownership verification logic—akin to Bitcoin UTXO’s unlocking script.
Think of Cell as an upgraded UTXO, enhanced with Type and Capacity fields, customizable data types, and ownership changes handled similarly to Bitcoin UTXO—via unlock scripts.
The core idea of RGB++ is using Cells on the CKB chain to express RGB asset ownerships. It relocates asset data formerly stored locally in RGB clients onto the CKB chain as Cells, turning CKB into a public database for RGB assets. These RGB-representing Cells maintain one-to-one mappings with Bitcoin UTXOs—explicitly shown in the Cell’s Lock field.
For example, suppose an RGB asset links to Bitcoin UTXO A. The corresponding mapped Cell sets its ownership verification condition identical to UTXO A (i.e., configuring the Lock script to match UTXO A’s unlocking conditions). If you control UTXO A, you can operate the mapped Cell on CKB—though CKB verifies your ownership of UTXO A.
CKB implements a Bitcoin light node syncing Bitcoin block headers. When claiming an RGB transaction involving operations on a Cell representing RGB assets, you must first prove control over Bitcoin UTXO A—achieved in two steps:
-
Prove existence of UTXO A on the Bitcoin chain to CKB’s embedded Bitcoin light node—requiring a Merkle Proof;
-
Provide a digital signature proving ownership of UTXO A.
Under RGB++, after a user declares an RGB asset transfer on the frontend, a transaction triggers on CKB modifying the Cell storing RGB asset data—changing ownership. Previously controlled by the holder of Bitcoin UTXO 1, the Cell becomes owned by the controller of Bitcoin UTXO 2—all visible on CKB.
Note: Commitment-related workflows still occur on the BTC mainnet—RGB++ continues to publish Commitments on Bitcoin chain linking to RGB transaction records on CKB. This aspect remains unchanged from traditional RGB.
But unlike traditional RGB—where clients handle off-chain tasks individually—CKB takes over responsibilities: verifying asset provenance, storing asset data locally, publishing contracts via third-party channels. All these burdens shift to CKB, freeing users from running clients.
This resolves RGB’s data silo problem and the lack of globally visible contract states. Additionally, RGB contracts can now be deployed directly on CKB—globally visible and referenceable by RGB Cells—eliminating the quirky procedures required in standard RGB contract publishing.
In summary, leveraging programmability of Cell scripts, CKB first confirms that the RGB transfer initiator indeed controls the Bitcoin UTXO linked to the RGB asset. Upon successful verification, the user may transfer the Cell (holding RGB asset data) to another party via transaction.
Simply put, CKB acts as a public data custodian for RGB assets, providing data storage, globally visible contract publication, ownership verification, and computational capabilities. More concisely: CKB replaces RGB clients and solves associated problems along the way.
Of course, since RGB++ enables globally visible data publishing, privacy is necessarily reduced compared to the original RGB protocol. The trade-off brings massive improvements in usability.
Thus, RGB++ fundamentally trades privacy for usability, unlocking new use cases impossible under standard RGB. Users valuing simplicity and completeness will prefer RGB++; those prioritizing privacy and “Verify by yourself” security will opt for traditional RGB—depending entirely on personal choice (similar to Vitalik’s comments on Ethereum Layer2: choose Rollups for security, Validium/Optimium for lower costs). That said, per the RGB++ whitepaper, future versions could implement privacy-preserving transactions on CKB hiding identities and amounts.
Additional Features of RGB++
Non-Interactive Transactions (Very Important)
A major flaw in the original RGB protocol is that recipients must first send a message (the aforementioned invoice) specifying binding one of their UTXOs to the RGB asset before any transfer proceeds. This forces multiple interactive communications between sender and receiver to complete a basic transaction—increasing cognitive load and product complexity. RGB++, leveraging CKB as a data custodian and computation platform, allows asynchronous, non-interactive transfers between counterparties.
When A sends to B, A only needs B’s address, declares the transfer—no requirement for recipient to be online or provide data. Later, B claims the asset independently. CKB’s script code verifies whether B is indeed the intended recipient. Clearly, this aligns better with common habits, enabling previously unsupported patterns like airdrops and reward distributions—facilitating RGB asset issuance.
Moreover, RGB’s operational model naturally resists DeFi applications. Classic multi-to-multi, non-interactive pools like Uniswap are nearly impossible under original RGB. RGB++ enables non-interactive transactions and globally verifiable states. By using Cells to implement “ownerless contracts”—where anyone meeting conditions can modify state—many DeFi use cases become feasible.
Naturally, ownerless contracts open to modification by all risk state contention/write conflicts—multiple actors trying to update state simultaneously causing chaos. To mitigate this, RGB++ plans to use an on-chain Intent Cell as a “sequencer” to order different requests.
Transaction Folding (Aggregating Commitments of Multiple Transactions)
Transaction folding is straightforward: treat CKB as an “off-chain pre-settlement layer.” After multiple RGB transfers occur, aggregate them into a batch, generate a single Commitment representing the entire batch, and publish it once on the Bitcoin chain.
Specifically illustrated in the following flowchart:
BTC Assets Interact Directly with CKB Chain Assets Without Cross-Chain
After establishing association mappings between Bitcoin UTXOs and CKB Cells, direct interoperability becomes possible without asset bridging. You can declare an RGB++ transaction transferring your Bitcoin UTXO to someone, while they transfer ownership of their CKB assets to you. This opens vast possibilities. Combined with transaction folding (batch processing), theoretically enables BTC–CKB asset interoperability without moving BTC assets across chains.
Conclusion
RGB++ expresses asset data previously scattered across individual RGB clients as Cells on the CKB chain, linking these Cells with Bitcoin UTXOs. Users can interact between their Bitcoin accounts/assets and RGB++ assets on CKB. This approach is clean and resolves numerous RGB pain points: pre-communication requirements, lack of global state visibility, fragmented data storage, and unfriendliness toward smart contracts and DeFi.
RGB++ enables BTC–CKB interoperability without cross-chain bridging, facilitates integration of RGB assets with DeFi, and greatly improves usability. Yet for privacy-focused niche users, RGB++ trades privacy for convenience—the choice depends on individual priorities. Theoretically, privacy could later be addressed on CKB using ZK techniques.
Overall, RGB++ demonstrates CKB’s potential as a Bitcoin off-chain settlement/computation layer. This paradigm will likely gain increasing adoption among Bitcoin Layer2s and asset protocols. The competition among third-party Bitcoin off-chain settlement layers may soon intensify. CKB, emphasizing POW and UTXO with years of technical development, may showcase distinct advantages in this modular blockchain race.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@godrealmx
