Author: Faust & Wuyue, BTCEden

In July 2024, CKB officially announced the launch of RGB++ Layer, marking that the previously released RGB++ protocol has completely changed from theory to engineering product, and will introduce more specific and practical application scenarios. With the vision of building a BTCFi ecosystem between BTC and pan-UTXO public chains such as CKB and Cardano, RGB++ Layer quickly became the focus of attention. In summary, RGB++ Layer is based on the RGB++ protocol, using isomorphic binding and Leap technology to provide a "cross-chain bridge-free" full-chain interactive experience for RGB++ native assets or inscriptions/runes between UTXO-type public chains such as BTC, CKB, and Cardano; using CKB's Turing-complete smart contract environment, it builds the necessary conditions for Bitcoin from asset issuance to the realization of complex DeFi functions. And because RGB++ Layer is backed by CKB's complete account abstraction ecosystem and is compatible with Bitcoin accounts and wallets, it can create a good experience for Bitcoin users and pave the way for the large-scale adoption of BTCFi. In the following, let us deeply understand the general working principle and characteristics of RGB++ Layer, and look forward to the changes it brings to the BTCFi ecosystem. Since its theoretical basis is built on the RGB++ protocol, we will start with the protocol itself.

RGB++ Protocol: Theoretical Foundation of RGB++ Layer

The RGB++ protocol was released in January this year. Its core concept is to replace the "client verification" of the RGB protocol with the form of verification on the CKB chain. The essence is to use CKB as a decentralized indexer, and to hand over tasks such as data storage and asset source verification to CKB, which will serve as the verification layer and DA layer of the RGB protocol to solve the shortcomings of the RGB protocol in UX and the defects that are not conducive to supporting Defi. In response to the concept of "one-time packaging", RGB++ introduced the concept of isomorphic binding, using the extended UTXO on the CKB chain, Cell, as the data carrier of inscription/rune assets, and then establish a binding relationship between Cell and UTXO on the Bitcoin/Cardano/Liquid chain, so that RGB++ assets will eventually inherit the security of UTXO public chains such as Bitcoin to prevent double payments. This idea of ​​"binding XXX to inherit XXX security" is similar to the binding of mobile phone numbers and ID cards to bank accounts in reality. For example, if Alice wants to transfer some TEST tokens to BOB, she can generate a statement to bind the Cell storing TEST asset information to Bob's Bitcoin UTXO. If Bob plans to transfer the TEST token to someone else, the bound Bitcoin UTXO will also be transferred. In this way, the Cell carrying the RGB++ asset data has a one-to-one binding relationship with the Bitcoin UTXO. As long as the Bitcoin UTXO is not double-spent, the bound RGB++ assets will not be double-spent.

Speaking of RGB++ Layer, it is actually the product of the engineering implementation of the RGB++ protocol. Its two main features include homogeneous binding and Leap bridgeless cross-chain. Let us take a deeper look at the technical implementation principles of homogeneous binding and Leap.

Isomorphic Binding and Leap: BTCFi’s Asset Issuance and Bridgeless Cross-Chain Layer

In order to truly understand the idea of ​​isomorphic binding and Leap, let's first briefly talk about CKB's Cell model. Cell is essentially an extended UTXO, with multiple fields such as LockScript, TypeScript, and Data. The role of LockScript is similar to Bitcoin's lock script and is used for permission verification; TypeScript is similar to smart contract code, and Data is used to store asset data.

If you want to issue RGB++ assets on the CKB chain, you must first create a Cell and write the token symbol and contract code in the relevant fields, such as TEST. You can then disassemble these Cells and distribute them to many people, just like the splitting and transfer of Bitcoin UTXO. Since Cell is similar in structure to Bitcoin UTXO, and CKB is compatible with the Bitcoin signature algorithm, users can use Bitcoin wallets to manipulate assets on the CKB chain. If you own a Cell, you can set the locking script so that the unlocking conditions are consistent with those of Bitcoin UTXO, so that you can use the private key of your Bitcoin account to manipulate the Cell on the CKB chain.

The above features can also be realized between CKB, BTC and other UTXO public chains. For example, you can also use Cardano accounts to rewrite asset data on the CKB chain, and the control of RGB++ assets can also be transferred from BTC accounts to Cardano accounts without the need for cross-chain bridges. We will explain this topic below.

As we mentioned earlier, RGB++ assets need to be bound to UTXO on public chains such as Bitcoin, Cardano, and Liquid, similar to how a bank account in real life needs to be bound to a mobile phone number and ID card; secondly, RGB++ assets themselves are just a bunch of data, which require a storage medium such as a database, and the Cell on the CKB chain can serve as its database.

Then we can set up permission verification to allow people to use accounts on different public chains such as BTC and Cardano to rewrite the RGB++ asset data on the CKB chain. This is the core purpose of isomorphic binding.

The "Leap" and bridgeless cross-chain proposed by RGB++ Layer are actually based on isomorphic binding technology, which "rebinds" the UTXO bound to RGB++ assets. For example, if your assets were previously bound to Bitcoin UTXO, you can now rebind them to UTXO on Cardano, Liquid, Fuel and other chains. In this way, the asset control authority can be transferred from the BTC account to the Cardano account.

From the perspective of user perception, this is actually equivalent to cross-chain assets, and CKB plays a role similar to that of an indexer and database. However, unlike the traditional cross-chain method, "Leap" only changes the usage rights of asset data, and the data itself is still stored on the CKB chain. This method is simpler than the Lock-Mint mode and eliminates the reliance on the mapping asset contract. The above is just a description of the product effects of isomorphic binding and Leap. Let us understand their technical implementation ideas through specific cases.

How to implement isomorphic binding

Let's understand the technical implementation of isomorphic binding. Assume that Alice has 100 TEST tokens, the data is stored in Cell#0, and it is bound to UTX#0on the Bitcoin chain. Now, Alice wants to transfer 40 TEST tokens to Bob. First, she needs to split Cel#0into two new Cells, where Cel#1contains 40 TEST tokens and is transferred to Bob; Cel#2contains 60 TEST and is still controlled by Alice herself.

In this process, BTC UTX#0bound to Cel#0must also be split into UTX#1and UTXO#2, and bound to Cel#1and Cel#2respectively. When Alice transfers Cel#1to Bob, she can transfer BTC UTX#1to Bob with one click, and realize synchronous transactions on CKB and BTC chains.

We can have a deep understanding of isomorphic binding here. In fact, the core meaning of this concept is that CKB's Cell, Cardano's eUTXO and BTC UTXO are all UTXO models, and CKB is compatible with the Bitcoin/Cardano signature algorithm. The decomposition and transfer of UTXO on the latter two chains can also be synchronized 1:1 to the Cell on the CKB chain. In this way, when we operate on the BTC UTXO bound to the RGB++ asset, we can synchronize the operation results to the Cell on the CKB chain, just like the relationship between the entity and the shadow. In addition, we should also note that RGB++ assets are associated with the two entities of BTC UTXO and CKB Cell, both of which are components of RGB++ assets and are indispensable.

If we examine the case of Alice transferring money to Bob mentioned above, the general process is as follows:

1. Alice constructs a CKB transaction data locally (not on the chain yet). This transaction specifies that Cell#0, which records the asset data, will be destroyed, Cel#1will be generated and given to Bob, and Cel#2will be kept for herself;

2. Alice generates a statement locally, binds Cel#1to BTC UTXO#1, binds Cel#2to BTC UTXO#2, and sends both Cel#1and BTC UTX#1to Bob;

3. After that, Alice generates a Commitment (similar to hash) locally, and the corresponding original content includes the statement in step 2 + CKB transaction data generated in step 1. The data of the Commitment will be recorded on the Bitcoin chain later;

4. Alice initiates a transaction on the Bitcoin chain, destroys UTXO#0, generates UTX#1and sends it to Bob, keeps UTX#2for herself, and writes Commitment to the Bitcoin chain in the form of OP_Return opcode;

5. After step 4 is completed, the CKB transaction generated in step 1 is sent to the CKB chain.

Some complicated details are omitted above. In fact, when Alice transfers her RGB++ assets to Bob, she must first go through a complex identity verification process to prove that she is indeed the owner of Cell#0. This involves:

1. Prove that Cel#0and BTC UTX#0are indeed bound;

2. Alice proves that she is the actual controller of Cel#0and BTC UTXO#0.

It should be noted that the Cell and Bitcoin UTXO with RGB++ asset data can be rewritten synchronously by the Bitcoin account. In the entire interactive process, one-click operation can be completed through the Bitcoin account. The above scenario is not limited to the isomorphic binding between Bitcoin and CKB, but can be expanded to Cardano, Liquid, Litecoin and other broad categories, and there is still a lot of room for imagination.

Leap's implementation principles and supported scenarios

As we mentioned earlier, the Leap function is actually to switch the UTXO bound to the RGB++ assets, such as changing it from Bitcoin to Cardano, and then you can use the Cardano account to control the RGB++ assets. After that, you can also transfer money on the Cardano chain, splitting the UTXO that controls the RGB++ assets and transferring them to more people. In this way, RGB++ assets can be transferred and distributed on multiple UTXO public chains, but it can bypass the traditional cross-chain bridge Lock-Mint model. In this process, the CKB public chain needs to play a role similar to an indexer to witness and process Leap requests. Assuming that you want to transfer the RGB++ assets bound to BTC to a Cardano account, the most core steps are nothing more than:

1. Release a Commitment on the Bitcoin chain, declaring that the Cell bound to the BTC UTXO will be unbound;

2. Publish a Commitment on the Cardano chain, declaring that the Cell will be bound to the Cardano UTXO;

3. Change the locking script of Cell to convert the Bitcoin UTXO associated with the unlocking condition into eUTXO on Cardano.

We can notice that in this whole process, the RGB++ asset data is still stored on the CKB chain, but the Bitcoin UTXO associated with the unlocking condition is changed to the eUTXO on the Cardano chain.

Of course, the specific execution process is much more complicated than what is described above, so I will not go into details here. In addition, there is an implicit premise in the leap plan, that is, the CKB public chain acts as a third-party witness, index, and DA facility.

As a public chain, its credibility is far superior to traditional cross-chain bridges such as MPC and multi-signature. In fact, based on the Leap function, very interesting scenarios can be realized, such as "full-chain transactions".

Suppose we build an indexer across Bitcoin, Cardano, and CKB, and construct a trading platform that allows buyers and sellers to trade RGB++ assets. Buyers can transfer their Bitcoin to sellers and then receive RGB++ assets in their Cardano accounts.

During this process, the data of the RGB++ assets is still recorded in the Cell, but this Cell will be transferred to the buyer, and then its unlocking authority will be changed from the seller's Bitcoin UTXO to the buyer's Cardano eUTXO.

Wrapper

Although Leap functionality is perfect for RGB++ assets, there are some bottlenecks:

For Bitcoin and Cardano, the essence of RGB++ assets is inscriptions/runes/colored coins based on the OP_RETURN opcode. These public chain nodes cannot perceive the existence of RGB++ assets, and CKB actually participates in the coordination as an indexer. In other words, for Bitcoin and Cardano, the RGB++ Layer mainly supports the Leap of inscriptions/runes/colored coins, rather than the cross-chain of native assets such as BTC and ADA.

In response to this, RGB++ Layer officially introduced Wrapper, which can be simply understood as a bridge based on fraud proof and over-collateralization. Taking rBTC wrapper as an example, it bridges BTC to RGB++ Layer, and a set of smart contracts running on RGB++ Layer monitor the guardians of the bridge. If the guardians act maliciously, their collateral will be slashed. If the guardians collude to steal the locked BTC, rBTC holders can get full compensation.

After combining Leap and Wrapper, various assets in the BTCFi ecosystem such as RGB++ native assets, BRC20, ARC20, runes, etc. can cross to other layers or public chains.

The following figure is part of the usage process of LeapX. It can be seen that it supports the interoperability of almost all BTCFi mainstream assets to different ecosystems. And there are corresponding processing processes for assets with different issuance methods, some of which use wrappers and some use leap.

CKB-VM: BTCFi’s Smart Contract Engine

Above we mainly explained the isomorphic binding of RGB++ Layer and the concept of Leap. Let's examine other key points. In traditional BTCFi, due to the lack of support for smart contracts, only some relatively simple Dapps can be implemented. Some implementation methods will have certain centralization risks, while others are clumsy and inflexible.

In order to realize the smart contract layer available on the blockchain, CKB provides CKB-VM for RGB++ Layer. Any programming language that can support RISC-V virtual machine can be used for contract development on RGB++ Layer. Developers can use their preferred tools and languages ​​to achieve efficient and secure smart contract development and deployment in a unified smart contract framework and execution environment.

The following is a transfer method of a user-defined token UDT in CKB implemented in C language. It can be seen that except for the different languages, its basic logic is the same as that of general tokens. Since RISC-V has a wide range of language and compiler support, the entry requirements for developers to develop smart contracts are relatively low. We can easily rewrite this logic in JavaScript, Rust, Go, Java and Ruby, instead of having to learn a certain DSL language to write contracts. Of course, language is only one aspect of programming, and learning a specific smart contract framework is inevitable.

Native AA Ecosystem: Seamlessly Connecting BTC and RGB++

Finally, let's take a brief look at the native AA and account abstraction ecology behind the RGB++ Layer. Since the essence of BTCFi is to provide a diverse Defi experience for native Bitcoin assets, compatibility with mainstream Bitcoin wallets will be an important factor that BTCFi's peripheral facilities need to consider. The RGB++ Layer directly reuses CKB's native AA solution, which can be compatible with important UTXO public chains such as BTC and Cardano as much as possible on both the developer side and the user side. In the RGB++ Layer, users can use different signature algorithms for authentication. For example, users can use accounts, wallets or authentication methods such as BTC, Cardano, or even WebAuthn to directly manipulate assets on the RGB++ Layer. Let's take the wallet middleware CCC below as an example. It can provide wallets and dApps with various public chains for CKB operability. The figure below is the connection window of CCC. We can see that it supports mainstream wallet entrances such as Unisat and Metamask.

Another example is the implementation of WebAuthn, of which JoyID, the CKB ecosystem wallet, is a typical example. Through JoyID, users can authenticate directly through biometrics (such as fingerprint or facial recognition) to achieve seamless and highly secure login and identity management.

It can be said that the basis for the establishment of isomorphic binding and Leap is that RGB++ Layer has a complete native AA solution, which can be well compatible with the account standards of other public chains. This feature not only facilitates the support of some key scenarios, but also clears obstacles for UX.

Summarize

In the above, we have examined the overall picture of RGB++ Layer, which can serve as an important infrastructure for various Memecoins such as inscriptions/runes/dyed coins, and realize the scenario of full-chain interaction. The smart contract execution environment built by RGB++ Layer based on RiscV can create soil for the complex business logic required by BTCFi.

Due to space limitations, this article only briefly introduces the core technology of RGB++ Layer, and does not systematically introduce many complex details. In the future, we will continue to pay attention to the progress of RGB++ Layer and conduct a more thorough and in-depth analysis of a series of technical solutions related to this project. Please stay tuned!