RGB++ Protocol Light Paper (Translation)

Translated from RGB++ Protocol Light Paper


RGB++ is an extension protocol based on RGB, utilizing single-use seals and client-side validation technology to manage state changes and transaction verification. It maps Bitcoin UTXOs to Nervos CKB Cells via isomorphic bindings and uses script constraints on the CKB and Bitcoin chains to verify the correctness of state computation and the validity of ownership changes.

RGB++ addresses the technical challenges faced by the original RGB protocol in practical implementation and provides more possibilities, such as blockchain-enhanced client validation, transaction folding, shared states with ownerless contracts, and non-interactive transfers. It brings Turing-complete contract extensions and performance enhancements to Bitcoin without the need for cross-chain transfers or compromising security.

Single-use Seals

The concept of single use seals was first proposed by Peter Todd in July 2016, allowing you to lock a message with an electronic seal, ensuring that the message can only be used once. Specifically, we can use Bitcoin’s unspent transaction outputs (UTXOs) as seals for messages, and the consensus mechanism of the Bitcoin system ensures that these UTXOs can only be spent once, meaning these seals can only be opened once.

The RGB protocol utilizes this single use seal based on Bitcoin UTXOs to correspond RGB state changes with the ownership of Bitcoin UTXOs. Therefore, the Bitcoin system ensures the ownership of RGB states and can trace all state changes through the UTXO history. Single-use seals provide RGB protocol with security against double spending guaranteed by Bitcoin consensus and the ability to trace transaction branches.

Client-Side Validation

The user states included in the RGB protocol cannot be directly verified by Bitcoin consensus, and users must ensure that RGB state changes meet expectations through off-chain computation. Client-side validation technology allows users to only verify the branch history of UTXOs relevant to them, without concern for transaction histories unrelated to them. The security of RGB states is ensured through client-side validation, independent of any centralized third party.

Issues with the RGB Protocol

Despite the many advantages of the RGB protocol, particularly its ability to provide almost uncompromised contract extensions for Bitcoin, there are still several technical and product issues in practical applications.

DA Issues

How ordinary users generate or obtain proofs of transaction history?

When ordinary users use simple client products, they do not have the ability or resources to save all transaction histories, making it difficult to provide transaction proofs to transaction counterparts.

P2P Network Issues

RGB transactions, as an extension of Bitcoin transactions, rely on a P2P network for propagation. When users conduct transfer transactions, they also need to interact, and the receiving party needs to provide a receipt. All of these depend on a P2P network independent of the Bitcoin network.

Virtual Machine and Contract Languages

The virtual machine of the RGB protocol currently mainly adopts AluVM, as a new virtual machine, which currently lacks mature development tools and practical code.

Ownerless Contract Issues

The RGB protocol currently lacks a perfect interactive solution for ownerless (public) contracts. This makes it difficult to implement multi-party interactions.

RGB++ Isomorphic Binding


RGB++ solves the problems encountered by the RGB protocol through isomorphic binding technology and endows RGB with more possibilities.

In the RGB protocol, the two most important components are UTXOs used for ownership identification and commitments used for state management and one-time sealing. RGB++'s isomorphic binding maps Bitcoin UTXOs one-to-one to CKB Cells, synchronizes ownership using bitcoin utxo lock, and maintains state using cell data and type.

Blockchain-Enhanced Client Validation

All RGB++ transactions will appear on both the BTC and CKB chains. The former is compatible with RGB protocol transactions, while the latter replaces the client validation process. Users only need to check the relevant transactions on CKB to verify whether the state calculation of this RGB++ transaction is correct. However, users can also independently verify RGB++ transactions without using transactions on the CKB chain, using local historical transaction information of UTXOs. (Some functions such as transaction folding still rely on the block header hash of CKB for double spending verification.)

RGB++ Transaction Process


1. Off-Chain Computation

  • Select the next one-time seal to be used, for example, btc_utxo#2
  • Off-chain computation and generate an RGB++ transaction to be sent to CKB: CKB_TX_B
  • Off-chain computation commitment = hash(CKB_TX_B | btc_utxo#1 | btc_utxo#2)

2. BTC Transaction Submission

  • Generate and send a Bitcoin transaction Bitcoin_TX_A, consume btc_utxo#1 as input, and output the commitment added by OP_RETURN above.

3. CKB Transaction Submission

  • Send the above CKB transaction CKB_TX_B
  • The user’s latest state is maintained by CKB_TX_B.output.data
  • The next change in state requires using btc_utxo#2, CKB_TX_B.output

4. On-Chain Verification

  • Bitcoin verifies that the relevant utxo can only be spent by the specified user

  • There is a Bitcoin light client on CKB, which can verify the relevant transactions on Bitcoin on the Bitcoin chain

  • Bitcoin’s relevant transactions are submitted as witnesses of the ckb transaction to assist in verification

  • CKB further verifies that the btc transaction spent the correct utxo

  • CKB further verifies that the btc transaction promised the correct commitment

  • CKB verifies that the state transition on CKB complies with the prescribed contract rules

RGB++ Client

Unlike the RGB protocol, all transactions of RGB++ are on CKB and verified by CKB script constraints. Therefore, RGB++ does not require an independent client. Users only need to access Bitcoin and CKB light clients to verify all transactions independently. The CKB light client also uses the PoW algorithm to verify that only a few recent block headers are needed to verify all historical transactions and states, and then use isomorphic binding to verify all RGB++ transactions.

Transaction Folding

The RGB++ protocol binds Bitcoin UTXOs to CKB Cells, realizing Turing-complete Bitcoin UTXO transactions supported by CKB Cell validation. If we further utilize the programmable capabilities of CKB Cells, we can correspond multiple CKB transactions to a single Bitcoin RGB++ transaction, thereby using the high-performance CKB chain to expand the low-speed and low-throughput Bitcoin chain.


Shared States and Ownerless Contracts

Simple Implementation of Shared States

Shared states have always been a challenge in UTXO systems. Here, we first discuss a simple implementation that does not consider multiple users simultaneously updating shared states, and then further discuss the solution that allows multiple users to operate shared states simultaneously.

Consider a global state Cell on CKB for managing shared states among multiple users. Typically, it can be a collateral contract for an algorithmic stablecoin, where users deposit volatile assets and receive a deposit certificate. The global state is managed by an ownerless contract, which means that anyone can change the state without requiring a specified digital signature provider to make changes. The implementation of the ownerless contract has a decisive role in the decentralization and censorship resistance of the protocol.

The simple implementation here refers to the risk of the Global-state cell being occupied by other users, so that the CKB TX cannot be established due to the absence of the specified Global state utxo. And Bitcoin TX needs to be sent before CKB TX, and it is calculated into the commitment, so subsequent verification cannot be performed.

State Contention Issues and Solutions

To solve the above problems, we introduce Intent Cells as intermediaries. Users deterministically write the actions they want to execute into Intent Cells, which can then interact with the global state Cell through the cooperation of third-party aggregators, batch calculate the intents of multiple parties, and merge the interaction results onto standard shadow cells.

Non-Interactive Transfers

One problem with the original RGB protocol is that the recipient needs to provide their own live utxo as an invoice to execute the transfer. This method requires the recipient to be online to complete a regular transaction, increasing user understanding difficulty and product complexity. RGB++ can take advantage of the Turing-complete environment by placing interactive behaviors within the ckb environment, implementing non-interactive transfer logic using a send-receive two-step operation.


When user A sends assets to user B, they only need to know B’s address and transfer to that address in the RGB++ transaction, without the need for the recipient to provide a utxo or invoice.




CKB’s lock contract has the ability to verify the digital signature corresponding to the btc address, so the recipient can construct Tx C on CKB to unlock the corresponding CKB Cell and transfer the assets to their own utxo#2. This completes non-interactive receipt.


The issuance of fungible assets on RGB++ requires corresponding data structure standards and consistency verification standards. We can use ckb’s xudt standard as its isomorphic binding protocol.


There are many ways to issue RGB++ coins, including but not limited to centralized distribution, airdrops, subscriptions, etc. The total amount of tokens can also choose between no upper limit and a preset upper limit. For tokens with a preset upper limit, the status sharing scheme can be used to verify that the issued total is less than or equal to the preset upper limit each time.


The transfer of RGB++ coins is very simple, only requiring the recipient and change utxos to correspond to the shadow cell on ckb. The transfer of coins can also be done by folding transactions only on CKB, committing the final result to BTC after multiple transactions.



xudt is a transparent token protocol, and we can also adopt a token protocol that supports amount privacy and flow privacy to strengthen the privacy protection features of RGB++ coins. For example, we can use bulletproof algorithm to blind the amount in the data into blinded amounts, and provide zero-knowledge proofs of consistent and non-negative amounts in each transfer transaction. In this way, only the parties to the transaction know the specific amount information of the current transaction, and third-party observers cannot obtain the amount data.

In addition, we can use ring signatures to blind the transfer flow. Users’ coins are transferred to a ring signature mixer on CKB, and then flow back to the address managed by the bitcoin utxo. This cuts off the historical trajectory of funds flow, thereby completing address privacy protection.



The issuance of NFT assets on RGB++ can also leverage existing NFT protocols on ckb, including but not limited to Spore, mNFT, and CoTA protocols. Taking Spore as an example, it preserves all metadata on-chain, achieving 100% safety of data availability. The CoTA protocol utilizes state compression technology to compress NFT information and holding data into a 32-byte SMT, providing extreme cost advantages.


The transfer of NFTs in RGB++ is also very simple, similar to the transfer of coins without change.

Lightning Network Interconnection

As a client verification protocol, RGB naturally supports state channels and lightning networks, but limited by the script computing power of Bitcoin, it is very difficult to implement non-BTC lightning networks on Bitcoin. Through the packaging of the RGB++ protocol, we can use the Turing-complete script system of CKB to realize the state channels and lightning networks of RGB++ assets based on CKB. This technology has tremendous commercial prospects. For example, a stablecoin payment system based on the lightning network can provide cost and performance advantages lower than centralized systems, while guaranteeing decentralization and censorship resistance.

Application Examples


Given a list of addresses and amounts, we can use RGB++ to implement a complete airdrop application. We assume that both the pending airdrop data and the list of claimed addresses are saved as information in the SMT cell data. Users can claim airdrops through their own addresses.


RGB++ can directly support UTXO-based asset exchange protocols without intermediaries. At the same time, using a grid order book design can realize an automated market maker model. Unlike the price curve market maker model of Uniswap, the grid market maker model can be more customizable and suitable for asset transactions based on UTXO structure.


The example above is a seller placing an order for RGB++ xudt, and the buyer using Bitcoin to purchase. The transaction structure involves the buyer providing a utxo containing sufficient Bitcoin and providing a PBST signature, and then the buyer constructs a transaction on CKB to meet the seller’s requirements. Finally, the buyer sends the constructed CKB transaction to the seller, and the seller completes the transaction by sequentially submitting the BTC transaction and the CKB transaction to the chain.


RGB++ inherits the core ideas of the RGB protocol, adopts different virtual machines and verification schemes, users do not need an independent RGB++ client, and only need to access Bitcoin and CKB light nodes to independently complete all verifications. RGB++ brings Turing-complete contract extensions and tens of times performance improvements to Bitcoin. It does not use any cross-chain bridges, but instead uses native client verification solutions to ensure security and censorship resistance.


This paper makes little to no sense.

RGB was designed to be a client-side-validated protocol, what you are instead turning it into is a other-chain-validated protocol, the security of which is then purely dependendent on the security of CKB chain. With that in mind I see no reason to actually even use bitcoin for commiting the transactions, if I need to fully trust CKB I might as well just transact directly on CKB. You are basically using CKB as DA layer for RGB, which is completely uneccessary and redundant.

RGB was made to inherit full security of bitcoin and not depend on any other security assumption, that’s why RGB commits to the off-chain state transitions in a bitcoin transaction, with the off-chain data kept by the transacting parties.

Let me go through the mentioned “Issues with the RGB Protocol”:

DA Isssues - the RGB was especially designed in such a way that there is no DA issue, the transacting parties keep the off-chain data themselves, they are incentivized to store this data because they need it to transact later. There is no need for general data availability and that’s how the system achieves great scalability & privacy.

P2P Network Issues - there really is no need for a P2P network, the off-chain data is sent directly between transacting parties (usually just 2 if we talk about a simple token/NFT transfer), no need to use P2P network for that, you can use tor hidden service, e-mail, whatsapp, telegram, proxy servers to pass the off-chain data to the recipient.

Virtual Machine and Contract Languages - I would agree with this, the question is how much more developed are the development tools on CKB? There really was a lot of thought put into building AluVM & contractum, that stuff really has to be rock solid to be usable in client-side-validated protocol (which of course is no issue for you because you are not a client-side-validated protocol)

Ownerless Contract Issues - yes, this is correct, you cannot have global state in the ethereum sense (AMMs like uniswap, lending pools, etc.), however I would argue that for most things you actually don’t need this and this also scales terribly (AMMs could be replaced by swap providers offering trustless scriptless atomic swaps between tokens, lending pools by lending providers offering a loan for a collateral locked in a DLC output)

In the end you are just shifting the DA and state verification to other blockchain (CKB) - which makes 0 sense, instead of letting it be fully off-chain (gaining all the scalability & privacy gains that RGB has to offer). The end goal of RGB is to kill blockchains and unlock infinite scalability (like in the Prime proposal by LNP/BP association), not adding more blockchains to the mix. You cannot solve issues of blockchains (the fact that everyone has to verify everything) by adding more blockchains.





1 Like

Hello, adambor, thank you for your reply. I’m not the author of RGB++; I just posted the translation here. However, I can try to answer your questions.

According to the original vision of RGB, solving problems through single-use-seal and client-side-validation is indeed possible, but it’s a huge challenge for user-oriented products.

Many of the above issues are present to some extent; otherwise, the Prime scheme would be unnecessary (LNP-BP/layer1: Paper on new bitcoin layer 1 design).

Regarding the scalability requirements, since RISC-V can support any cryptographic primitive, various verifiable computations can be used to compress transactions. Furthermore, integration with the Lightning Network is also possible.

Currently, due to engineering considerations, RGB++ is not compatible with RGB. If compatibility with RGB is needed, AluVM needs to be compiled to RISC-V to support validation of state transitions. I don’t know when they will advance on this point, but it’s possible.

There are inevitably trade-offs between RGB++ compare to RGB, but RGB++ is striving to explore some new possibilities for BTC ecosystem using the extended UTXO model and RISC-V virtual machine, based on single-use-seal and client-side-validation.


This is an additional security assumption actually - if I’m holding BTC I only need to keep my privkeys and assume the network replicates all the data.


Not sure if you can call it a security assumption because you are not trusting anyone but yourself with the off-chain data, same as you are trusting yourself with the private key.

The difference to CKB is obvious, whereas in RGB you only trust yourself with the off-chain data, in CKB you need to trust CKB blockchain to store and verify the data for you.

Maybe it’s better to say that there are no additional trust assumptions in RGB, but there is an additional trust assumption in CKB blockchain for RGB++.

I don’t understand this point. Transactions in RGB++ are exportable and support client-side validation in a purely off-chain manner. On-chain validation in CKB is merely a convenience for users. Users can verify data themselves and reject assets they do not recognize.

If I’m only receiving $20 in assets to buy a pizza, I might not bother with client-side validation. But if someone sends me $1 million, I would certainly prudently request transaction history for client-side validation.

1 Like

RGB++ is not a protocol dependent on chain validation.

Okay, that’s pretty interesting, that was not immediately clear from the writeup. So RGB++ can be used both ways, with off-chain & on-chain data stored on CKB.

In this case I think it would make a lot of sense to not re-invent the wheel and just use RGB and leave CKB acting as an optional indexer and DA layer. The reason for that is that there are already products being built on RGB, such as Bitmask, Bitlight, Kaleidoscope DEX, Iris wallet, and CKB can directly tap into that ecosystem, not fragment it even further (like what TapAss does). It also saves you a lot of development time (I would expect implementing RGB validation, even AluVM on CKB is much easier then re-building the whole RGB). Therefore, if CKB wants to be an indexer and DA layer for RGB, it can just use RGB and don’t re-invent a completely new standard which is incompatible with RGB.

How much value I personally see in that is debatable, it would certainly make sense for contracts with global state, but I am wondering if for that there isn’t some better approach (e.g. bitcoin inscriptions) without having to rely on external blockchains, such as CKB. But I guess we can let the market decide about that!

DA Issues: In some scenarios, DA issues do exist.

Yes, global state is tricky, there I see the value of using CKB as a public DA layer, however as stated in a prior paragraph, maybe there could be a better approach to that.

P2P Network Issues

Current status quo in RGB is to use proxy servers, where you upload encrypted off-chain data and the recipient downloads it from that very same server. The UX for that is great, because users don’t even know about it happening in the background (this is done by e.g. Iris wallet). There are of course also other ways one can send the data to the recipient, e.g. tor hidden service or wireguard with direct tunnels.

All those ways scale strictly better than having to put all of those data to a single CKB blockchain, so RGB++ doesn’t solve the P2P network issue, it just makes it even worse, whereas in RGB you can just send data to recipient, in RGB++ you need to send it to the whole P2P network. Again, this does makes sense for contracts with global state.

I would also argue that the UX of RGB++ also has its drawbacks, mainly the fact that you need to hold both BTC (to pay tx fee on bitcoin) and CKB (to pay tx fee on CKB).

Virtual Machine and Contract Languages

Okay, this is also interesting. No objection to that

Ownerless Contract Issues

Indeed, this makes sense, in that case data needs to be public, if people want to use CKB for DA so be it.

Many of the above issues are present to some extent; otherwise, the Prime scheme would be unnecessary

Prime solves none of the points you mentioned above:
DA Issues - there cannot be any DA on Prime, it’s purely just a single-use-seal layer (holds no data itself, only commitment to data).
P2P Network Issues - uses the same principle as RGB does, the off-chain data is passed from the sender to the recipient, transfer medium is out of scope for the Prime spec.
Virtual Machine and Contract Languages - Prime is also intended to use AluVM, but is also easily estensible to other VMs (without any softfork needed)
Ownerless Contract Issues - this isn’t solved in Prime at all, again Prime itself holds no data, only commitment to data compressed to a single merkle root per block.


Yes, it is possible to compile a BTC light node on the RISC-V virtual machine, while also compiling and deploying the VM used by RGB, thereby becoming an optional indexer and DA layer. However, firstly, this requires a significant amount of engineering effort, and secondly, the latest version of the RGB protocol has not been finalized, so I don’t know when RGB++ will complete this feature.

I don’t understand this point. Transactions in RGB++ are exportable and support client-side validation in a purely off-chain manner.

Yes now I get it, sorry, didn’t read your message first.

If I’m only receiving $20 in assets to buy a pizza, I might not bother with client-side validation. But if someone sends me $1 million, I would certainly prudently request transaction history for client-side validation.

Right, this makes sense. However what is already being explored in RGB is history compression (through SNARKs or STARKs), in that case the asset history will always be small enough to be verifiable by anyone (~500kB with STARKs).

Using zero-knowledge proofs in RGB, especially recursive zero-knowledge proofs, is a very promising direction. I notice you’re working hard to achieve this, which is great, as it will significantly reduce the cost for users to perform client-side validation

However, I have a slight concern regarding this. If the RGB protocol isn’t designed with enough abstraction and the VM used isn’t high-performance enough, will many new features require incompatible upgrades?

I believe a protocol should be designed with sufficient abstraction, for example, using RISC-V or WASM. This way, even if more powerful zero-knowledge proof solutions emerge in the future, they can be compiled and deployed as a contract within the protocol without requiring a hard fork. If you’re interested, you can take a look at this Blockchain Abstraction and Interoperability 2.0.

What mechanism does Prime use to resist double spending? Up until these seals are protected by Bitcoin.

That is a good objection to bring up to the LNP/BP association about RGB, however as AluVM is turing complete you can implement anything on top of it.

Prime is a chain of blockheaders (really small ones ~1kB), where the blockheader only contains merkle root of all the seals that were closed in that blockheader. Users are then required to store the proofs of either inclusion/non-inclusion of their seal inside the blockheaders (seal has a deterministic position inside the merkle tree, so proof of inclusion/non-inclusion is a single merkle path per blockheader). You can then reveal the proofs of non-inclusion for all blockheaders between the time the seal was defined and now, this proves that you haven’t closed your seal yet and the counterparty can accept your RGB state/assets. To commit a state transition you close the seal by including it in the blockheader’s merkle tree, get a proof of inclusion, and this way the RGB state transition is finalized. It is a super scalable singe-use-seal layer, with blocks (or as I call them, blockheaders) having constant size regardless of how many transaction are processed inside the block.

Prime is also designed to inherit full security of bitcoin through Bitcoin PoW anchoring.

1 Like

evm is aslo a Turing-complete vm, however, due to performance issues, it is very difficult to implement other cryptographic algorithms on it, such as BLS12-381, which must be added to the precompiled contract through a hard fork.

Prime sounds very interesting. It is also a compression scheme that can expand RGB. So do users need to transfer RGB assets to the UTXO hosted by Prime first? Without transferring authority to the UTXOs hosted by Prime, how can the commitment submitted by Prime represent the transfer of these assets? Are there security issues if permissions are transferred to Prime-hosted contracts? I may need to read further into the documentation to sort these out.

The performance of EVM is limited exactly due to the fact that it is a blockchain using it, so one computation in EVM needs to be re-run by all the 10k nodes in the ethereum network. This is not the case for AluVM, which only needs to be ran by the recipient, to my knowledge it has 16MB of available memory space, and the computation complexity is only bounded by the recipient executing it. So if you have more complex smart contract, you just need to tell the recipient to leave it running for longer - no hard fork required.

In RGB you can transfer assets between blockchains (this is already something up and coming in RGB v0.11 allowing users to freely transfer assets between Bitcoin & Liquid), the very same way you would be able to transfer and RGB assets between Prime & Bitcoin.

EDIT: As it is a client-side-validated protocol, you can freely transfer the assets between different single-use-seal layers. You can send an asset from a UTXO on Bitcoin to a UTXO on Liquid, or from a UTXO on Bitcoin to a seal on Prime.

Is there any relevant documentation on this? It sounds very interesting. As a UTXO chain, CKB can also be connected to the original RGB using this mechanism.

I think this needs to be tested. You can have confidence, but it depends on the actual situation.