RGB++ Layer as Hub of BTCFi and UTXO: Four Main Characteristics

Author: Faust & Wuyue, from GeekWeb3 & BTCEden The announcement of the launch of the RGB++ Layer this month, July 2024, marks the complete transition of the previously released RGB++ protocol from theory to an engineered product. With its grand vision of building a BTCFi ecosystem on BTC, CKB, Cardano, and other pan-UTXO (unspent transaction output) public chains, the RGB++ Layer’s launch also helps introduce more specific and practical scenarios for the platform thus making it become the focus of attention for countless people. Based on the RGB++ protocol, the RGB++ Layer uses isomorphic binding and Leap to provide a "bridge-free" cross-chain interaction experience for RGB++ native assets or inscriptions/runes between BTC, CKB, Cardano, and other UTXO-type public chains. It leverages CKB's Turing-complete smart contract environment to build the necessary conditions for Bitcoin to issue assets and implement complex DeFi functions. Considering that CKB's comprehensive account abstraction ecosystem backs it, and is compatible with Bitcoin accounts and wallets, it also paves the way for the large-scale adoption of BTCFi. This piece is to help understand the general working principles and functional characteristics of the RGB++ Layer. It also highlights the changes the layer will bring to the BTCFi ecosystem based on its four distinctive characteristics. 1. RGB++ Protocol as the Theoretical Foundation of RGB++ Layer The RGB++ protocol was released in January to replace the "client-side verification" of the RGB protocol with the CKB on-chain verification. It uses CKB as a decentralized Indexer, delegating tasks such as data storage and asset source verification to CKB, with the latter serving as the verification layer and data availability (DA) layer for the RGB protocol. This is to help solve unspent transaction (UX) issues and unfavorable defects in DeFi scenarios in the RGB protocol. In line with the concept of "one-time encapsulation", RGB++’s isomorphic binding uses Cell—an extended UTXO on the CKB chain—as the data carrier for inscription/rune-type assets to establish a binding relationship with UTXOs on the Bitcoin chain to inherit Bitcoin's security. For example, if Alice wants to transfer some TEST tokens to Bob, she can generate a declaration that binds the Cell storing TEST asset information to one of Bob's Bitcoin UTXOs. If Bob wants to transfer the TEST tokens to someone else, the bound Bitcoin UTXO must also be transferred. In this way, there is a 1-to-1 binding relationship between the Cell carrying RGB++ asset data and the Bitcoin UTXO. As long as the Bitcoin UTXO is not double-spent, the bound RGB++ asset cannot be double-spent. With this mechanism, the RGB++ assets have inherited Bitcoin's security. The RGB++ Layer is a product of the engineering implementation of the RGB++ protocol. Its two main features are isomorphic binding and Leap bridge-free cross-chain. 2. Isomorphic Binding and Leap - Asset Issuance and Bridge-free Cross-chain Layer for BTCFi To understand the isomorphic binding and Leap approach, explaining CKB's Cell model is essential. A Cell is an extended UTXO with multiple fields such as LockScript, TypeScript, and Data. The LockScript functions similarly to Bitcoin's locking script, used for permission verification; TypeScript is similar to smart contract code, while Data is used to store asset data. If you want to issue RGB++ assets on the CKB chain, create a Cell first and write the token symbol and contract code in the relevant fields. Then you can break down the Cell and distribute it to many people, just like the splitting and transfer of Bitcoin UTXOs. With the Cell’s structural similarity to Bitcoin UTXOs, and CKB’s similarity with Bitcoin's signature algorithm, users can manipulate assets on the CKB chain using Bitcoin wallets. As the owner of a Cell, you can set its locking script so that its unlock condition is consistent with that of a Bitcoin UTXO, allowing you to directly manipulate Cells on the CKB chain using a Bitcoin account’s private key. The features highlighted above can also be implemented between CKB, BTC, and other UTXO public chains. For example, you can use a Cardano account to rewrite asset data on the CKB chain, and the control rights of RGB++ assets get transferred from a BTC account to a Cardano account without a cross-chain bridge. Remember that the binding of RGB++ assets to UTXOs on public chains such as Bitcoin, Cardano, Liquid, etc —similar to how bank accounts are bound to customers’ phone numbers and IDs in real-life cases—is to prevent double-spending. It should also be noted that RGB++ assets are a bunch of data that needs media storage like in a database. Cells on the CKB chain can serve as their database. Then the permission verification could be set to allow access to accounts from different public chains like BTC and Cardano to rewrite RGB++ asset data on the CKB chain. The "Leap" and bridge-free cross-chain proposed by RGB++ Layer are based on the isomorphic binding technology. They serve the purpose of "re-binding" for the UTXOs bound to RGB++ assets. For example, if your assets were previously bound to Bitcoin UTXOs, they can now be re-bound to UTXOs on Cardano, Liquid, Fuel, and other chains. As a result, asset control permissions are transferred from BTC accounts to Cardano or other accounts. From the user's perspective, this is equivalent to asset cross-chaining, with CKB playing a role similar to an indexer and database. However, unlike traditional cross-chain methods, "Leap" only changes the permission to modify asset data, while the data itself is still stored on the CKB chain. This method is more concise than the Lock-Mint model and eliminates the dependency on mapped asset contracts. Technical Implementation Approach of Isomorphic Binding Assuming Alice has 100 TEST tokens whose data is stored in Cell#0 and has a binding relationship with UTXO#0 on the Bitcoin chain. To transfer 40 TEST tokens to Bob, she needs to split Cell#0 into two new Cells, where Cell#1 contains 40 TEST tokens to be transferred to Bob and Cell#2 contains 60 TEST tokens still controlled by Alice. In this process, the BTC UTXO#0 bound to Cell#0 has to be split into UTXO#1 and UTXO#2 and then bound to Cell#1 and Cell#2 respectively. So when Alice transfers Cell#1 to Bob, she can transfer BTC UTXO#1 to Bob, too, with one click to achieve synchronous transactions on CKB and BTC chains. The core significance of isomorphic binding is its adaptability. This is particularly key since CKB's Cell, Cardano's eUTXO, and Bitcoin's UTXO are all UTXO models, and CKB is compatible with Bitcoin/Cardano signature algorithms. The operation methods of UTXOs on both the Bitcoin and Cardano chains also work for Cells on the CKB chain. This way, Bitcoin/Cardano accounts can directly be used to control both RGB++ assets on the CKB chain and their bound Bitcoin/Cardano UTXOs simultaneously, achieving 1:1 synchronous transactions. Going by the Alice transferring to Bob scenario above, the general workflow is as follows: Alice constructs a CKB transaction data locally (not on-chain yet), specifying that Cell#0 will be destroyed, Cell#1 to be sent to Bob is generated, and Cell#2 to be kept for herself; Alice generates a declaration locally, binding Cell#1 to UTXO#1 and Cell#2 to UTXO#2, and sending both Cell#1 and UTXO#1 to Bob; Then, Alice generates a Commitment (similar to a hash) locally, corresponding to the original content including the declaration from step 2 + the CKB transaction data generated in step 1; Alice initiates a transaction on the Bitcoin chain, destroys UTXO#0, generates UTXO#1 to be sent to Bob, keeps UTXO#2 for herself, and writes the Commitment to the Bitcoin chain in the form of an OP_Return opcode; After step 4 is completed, the CKB transaction generated in step 1 is sent to the CKB chain. Note that the Cell and the corresponding Bitcoin UTXO are isomorphically bound and can be directly controlled by Bitcoin accounts. That is, during the interaction process, users can perform one-click operations through Bitcoin accounts in the RGB++ wallet. Hence, RGB++ assets bound to Bitcoin UTXOs help solve the double-spending problem as assets on the RGB++ Layer inherit Bitcoin's security. The above scenario is not limited to isomorphic binding between Bitcoin and CKB but also applies to a broad scope of chains including Cardano, Liquid, Litecoin, etc. Implementation Principle and Supported Scenarios of Leap The Leap function is basically to switch the UTXO bound to RGB++ assets e.g. changing the binding from Bitcoin to Cardano, after which you can control RGB++ assets using Cardano accounts. In such an instance, a transfer could still be made on the Cardano chain afterward, splitting and transferring the UTXO controlling RGB++ assets to more people. While RGB++ assets can be transferred and distributed on multiple UTXO public chains, they can bypass the traditional cross-chain bridge Lock-Mint model. In this process, the CKB public chain plays a role similar to an indexer, witnessing and processing Leap requests. Suppose you want to transfer RGB++ assets bound to BTC to a Cardano account, the core steps to follow are: Publish a Commitment on the Bitcoin chain, declaring the unbinding of the Cell bound to the BTC UTXO; Publish a Commitment on the Cardano chain, declaring the binding of the Cell to the Cardano UTXO; Change the locking script of the Cell, changing the unlock condition from a Bitcoin account private key to a Cardano account private key Take note that the RGB++ asset data is still stored on the CKB chain throughout this process. The unlock condition is changed from a Bitcoin private key to a Cardano private key. Of course, the specific execution process is much more complex than described above but we won't elaborate on it here. In the leap to non-CKB public chains, the implicit premise is that the CKB public chain acts as a third-party witness, indexer, and DA facility. This is because, as a public chain, its credibility far exceeds traditional cross-chain bridge methods such as Multi-Party Computation (MPC) and multi-signature. Another interesting scenario that can be implemented based on the Leap function is "full-chain transactions". An example of this scenario is when an indexer is set up across Bitcoin, Cardano, and CKB to build a trading platform that allows buyers and sellers to trade RGB++ assets. In such an instance, buyers can transfer their bitcoins to sellers and receive RGB++ assets with their Cardano accounts. Throughout the process, the data of RGB++ assets is still recorded in Cells which are transferred to the buyer and their unlock permissions are changed from the seller's Bitcoin private key to the buyer's Cardano private key. Wrapper Although the Leap function is perfect for RGB++ assets, there are still some bottlenecks: For Bitcoin and Cardano, RGB++ assets are essentially inscriptions/runes/colored coins based on the OP_RETURN opcode. The nodes of these public chains cannot perceive the existence of RGB++ assets, as CKB participates in 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 like BTC and ADA. As a remedy, the RGB++ Layer introduced Wrapper, a bridge based on fraud proofs and over-collateralization. Taking the rBTC wrapper as an example, it bridges BTC to the RGB++ Layer. A set of smart contracts running on the RGB++ Layer monitors the guardians of the bridge. If the guardians act maliciously, their collateral will be slashed. If they collude to steal locked BTCs, rBTC holders will be made to receive full compensation. With the combination of Leap and Wrapper, various assets in the BTCFi ecosystem e.g. RGB++ native assets, BRC20, ARC20, runes, etc., can be bridged to other layers or public chains. The following diagram shows part of the usage process of LeapX. It supports the interoperability of almost all mainstream BTCFi assets to different ecosystems. There are corresponding processing flows for assets issued in different ways with some using either wrappers or Leap. 3. CKB-VM: The Smart Contract Engine for BTCFi Due to a lack of support for smart contracts in traditional BTCFi, only relatively simple decentralized applications (dApps) can be implemented in the evolving space. Some implementation methods may have certain centralization risks, while others are rather clumsy or inflexible. To have a blockchain-available smart contract layer, CKB introduced the CKB-VM through the RGB++ Layer. It aims to make it possible for any programming language that supports the RISC-V virtual machine to be used for contract development on the RGB++ Layer. It enables developers to use their preferred tools and languages to develop and deploy efficient and secure smart contracts under a unified smart contract framework and execution environment. Generally, the entry requirements for developers' smart contract development with RISC-V are relatively low because of its extensive language and compiler support. Of course, language is only one aspect of programming, and learning specific smart contract frameworks is inevitable. However, with the RGB ++ Layer, the logic can be easily rewritten in JavaScript, Rust, Go, Java, and Ruby, rather than learning a specific DSL language to write contracts. The diagram below shows a method for transferring user-defined tokens (UDT) with CKB using C language. Aside from the different languages, its basic logic is the same for general tokens. 4. Native AA Ecosystem: Seamlessly Connecting BTC and RGB++ Finally, since BTCFi is to essentially provide diverse DeFi experiences for native Bitcoin assets, understanding the account abstraction ecosystem behind RGB++ Layer along with its mainstream Bitcoin wallets is an important factor for the BTCFi peripheral facilities to consider. RGB++ Layer directly reuses CKB's native AA solution, which is compatible with main UTXO public chains like BTC and Cardano on both the developer and the user sides. With the RGB++ Layer, different signature algorithms can be used for authentication. That is, users can directly manipulate assets on the RGB++ Layer using BTC, Cardano, or even WebAuthn accounts, wallets, or authentication methods. An example is the wallet middleware, CCC, which can provide various public chains’ operability to CKB for wallets and dApps. The following image shows the connection window of CCC and how it supports mainstream wallet entries such as Unisat and Metamask. Another example is the implementation of WebAuthn with JoyID, a CKB ecosystem wallet, being a typical representative. JoyID users can directly authenticate their accounts through biometric methods (such as fingerprint or facial recognition) to achieve seamless and highly secure login and identity management. It can be said that the RGB++ Layer has a complete native AA solution, which can also accommodate the account standards of other public chains. This feature not only facilitates support for some key scenarios, but also clears obstacles for UXs. Summary This article introduced the core technologies of the RGB++ Layer without explaining several complex details. It highlights that the RGB++ Layer can be an important infrastructure for realizing full-chain interaction scenarios including for various meme coins and inscriptions/runes/colored coins. The layer’s RISC-V-based smart contract execution environment can also help create the soil for the complex business logic required by BTCFi to grow. As the RGB++ Layer progresses, a more thorough analysis of the series of technical solutions related to the project will be provided. Please stay tuned! Author: Faust & Wuyue, from GeekWeb3 & BTCEden Author: Faust & Wuyue, from GeekWeb3 & BTCEden The announcement of the launch of the RGB++ Layer this month, July 2024, marks the complete transition of the previously released RGB++ protocol from theory to an engineered product. With its grand vision of building a BTCFi ecosystem on BTC, CKB, Cardano, and other pan-UTXO (unspent transaction output) public chains, the RGB++ Layer’s launch also helps introduce more specific and practical scenarios for the platform thus making it become the focus of attention for countless people. Based on the RGB++ protocol, the RGB++ Layer uses isomorphic binding and Leap to provide a "bridge-free" cross-chain interaction experience for RGB++ native assets or inscriptions/runes between BTC, CKB, Cardano, and other UTXO-type public chains. It leverages CKB's Turing-complete smart contract environment to build the necessary conditions for Bitcoin to issue assets and implement complex DeFi functions. Considering that CKB's comprehensive account abstraction ecosystem backs it, and is compatible with Bitcoin accounts and wallets, it also paves the way for the large-scale adoption of BTCFi. This piece is to help understand the general working principles and functional characteristics of the RGB++ Layer. It also highlights the changes the layer will bring to the BTCFi ecosystem based on its four distinctive characteristics. 1. RGB++ Protocol as the Theoretical Foundation of RGB++ Layer The RGB++ protocol was released in January to replace the "client-side verification" of the RGB protocol with the CKB on-chain verification. It uses CKB as a decentralized Indexer, delegating tasks such as data storage and asset source verification to CKB, with the latter serving as the verification layer and data availability (DA) layer for the RGB protocol. This is to help solve unspent transaction (UX) issues and unfavorable defects in DeFi scenarios in the RGB protocol. In line with the concept of "one-time encapsulation", RGB++’s isomorphic binding uses Cell—an extended UTXO on the CKB chain—as the data carrier for inscription/rune-type assets to establish a binding relationship with UTXOs on the Bitcoin chain to inherit Bitcoin's security. For example, if Alice wants to transfer some TEST tokens to Bob, she can generate a declaration that binds the Cell storing TEST asset information to one of Bob's Bitcoin UTXOs. If Bob wants to transfer the TEST tokens to someone else, the bound Bitcoin UTXO must also be transferred. In this way, there is a 1-to-1 binding relationship between the Cell carrying RGB++ asset data and the Bitcoin UTXO. As long as the Bitcoin UTXO is not double-spent, the bound RGB++ asset cannot be double-spent. With this mechanism, the RGB++ assets have inherited Bitcoin's security. The RGB++ Layer is a product of the engineering implementation of the RGB++ protocol. Its two main features are isomorphic binding and Leap bridge-free cross-chain. 2. Isomorphic Binding and Leap - Asset Issuance and Bridge-free Cross-chain Layer for BTCFi To understand the isomorphic binding and Leap approach, explaining CKB's Cell model is essential. A Cell is an extended UTXO with multiple fields such as LockScript, TypeScript, and Data. The LockScript functions similarly to Bitcoin's locking script, used for permission verification; TypeScript is similar to smart contract code, while Data is used to store asset data. If you want to issue RGB++ assets on the CKB chain, create a Cell first and write the token symbol and contract code in the relevant fields. Then you can break down the Cell and distribute it to many people, just like the splitting and transfer of Bitcoin UTXOs. With the Cell’s structural similarity to Bitcoin UTXOs, and CKB’s similarity with Bitcoin's signature algorithm, users can manipulate assets on the CKB chain using Bitcoin wallets. As the owner of a Cell, you can set its locking script so that its unlock condition is consistent with that of a Bitcoin UTXO, allowing you to directly manipulate Cells on the CKB chain using a Bitcoin account’s private key. The features highlighted above can also be implemented between CKB, BTC, and other UTXO public chains. For example, you can use a Cardano account to rewrite asset data on the CKB chain, and the control rights of RGB++ assets get transferred from a BTC account to a Cardano account without a cross-chain bridge. Remember that the binding of RGB++ assets to UTXOs on public chains such as Bitcoin, Cardano, Liquid, etc —similar to how bank accounts are bound to customers’ phone numbers and IDs in real-life cases—is to prevent double-spending. It should also be noted that RGB++ assets are a bunch of data that needs media storage like in a database. Cells on the CKB chain can serve as their database. Then the permission verification could be set to allow access to accounts from different public chains like BTC and Cardano to rewrite RGB++ asset data on the CKB chain. The "Leap" and bridge-free cross-chain proposed by RGB++ Layer are based on the isomorphic binding technology. They serve the purpose of "re-binding" for the UTXOs bound to RGB++ assets. For example, if your assets were previously bound to Bitcoin UTXOs, they can now be re-bound to UTXOs on Cardano, Liquid, Fuel, and other chains. As a result, asset control permissions are transferred from BTC accounts to Cardano or other accounts. From the user's perspective, this is equivalent to asset cross-chaining, with CKB playing a role similar to an indexer and database. However, unlike traditional cross-chain methods, "Leap" only changes the permission to modify asset data, while the data itself is still stored on the CKB chain. This method is more concise than the Lock-Mint model and eliminates the dependency on mapped asset contracts. Technical Implementation Approach of Isomorphic Binding Assuming Alice has 100 TEST tokens whose data is stored in Cell#0 and has a binding relationship with UTXO#0 on the Bitcoin chain. To transfer 40 TEST tokens to Bob, she needs to split Cell#0 into two new Cells, where Cell#1 contains 40 TEST tokens to be transferred to Bob and Cell#2 contains 60 TEST tokens still controlled by Alice. In this process, the BTC UTXO#0 bound to Cell#0 has to be split into UTXO#1 and UTXO#2 and then bound to Cell#1 and Cell#2 respectively. So when Alice transfers Cell#1 to Bob, she can transfer BTC UTXO#1 to Bob, too, with one click to achieve synchronous transactions on CKB and BTC chains. The core significance of isomorphic binding is its adaptability. This is particularly key since CKB's Cell, Cardano's eUTXO, and Bitcoin's UTXO are all UTXO models, and CKB is compatible with Bitcoin/Cardano signature algorithms. The operation methods of UTXOs on both the Bitcoin and Cardano chains also work for Cells on the CKB chain. This way, Bitcoin/Cardano accounts can directly be used to control both RGB++ assets on the CKB chain and their bound Bitcoin/Cardano UTXOs simultaneously, achieving 1:1 synchronous transactions. Going by the Alice transferring to Bob scenario above, the general workflow is as follows: Alice constructs a CKB transaction data locally (not on-chain yet), specifying that Cell#0 will be destroyed, Cell#1 to be sent to Bob is generated, and Cell#2 to be kept for herself; Alice generates a declaration locally, binding Cell#1 to UTXO#1 and Cell#2 to UTXO#2, and sending both Cell#1 and UTXO#1 to Bob; Then, Alice generates a Commitment (similar to a hash) locally, corresponding to the original content including the declaration from step 2 + the CKB transaction data generated in step 1; Alice initiates a transaction on the Bitcoin chain, destroys UTXO#0, generates UTXO#1 to be sent to Bob, keeps UTXO#2 for herself, and writes the Commitment to the Bitcoin chain in the form of an OP_Return opcode; After step 4 is completed, the CKB transaction generated in step 1 is sent to the CKB chain. Alice constructs a CKB transaction data locally (not on-chain yet), specifying that Cell#0 will be destroyed, Cell#1 to be sent to Bob is generated, and Cell#2 to be kept for herself; Alice constructs a CKB transaction data locally (not on-chain yet), specifying that Cell#0 will be destroyed, Cell#1 to be sent to Bob is generated, and Cell#2 to be kept for herself; Alice generates a declaration locally, binding Cell#1 to UTXO#1 and Cell#2 to UTXO#2, and sending both Cell#1 and UTXO#1 to Bob; Alice generates a declaration locally, binding Cell#1 to UTXO#1 and Cell#2 to UTXO#2, and sending both Cell#1 and UTXO#1 to Bob; Then, Alice generates a Commitment (similar to a hash) locally, corresponding to the original content including the declaration from step 2 + the CKB transaction data generated in step 1; Then, Alice generates a Commitment (similar to a hash) locally, corresponding to the original content including the declaration from step 2 + the CKB transaction data generated in step 1; Alice initiates a transaction on the Bitcoin chain, destroys UTXO#0, generates UTXO#1 to be sent to Bob, keeps UTXO#2 for herself, and writes the Commitment to the Bitcoin chain in the form of an OP_Return opcode; Alice initiates a transaction on the Bitcoin chain, destroys UTXO#0, generates UTXO#1 to be sent to Bob, keeps UTXO#2 for herself, and writes the Commitment to the Bitcoin chain in the form of an OP_Return opcode; After step 4 is completed, the CKB transaction generated in step 1 is sent to the CKB chain. After step 4 is completed, the CKB transaction generated in step 1 is sent to the CKB chain. Note that the Cell and the corresponding Bitcoin UTXO are isomorphically bound and can be directly controlled by Bitcoin accounts. That is, during the interaction process, users can perform one-click operations through Bitcoin accounts in the RGB++ wallet. Hence, RGB++ assets bound to Bitcoin UTXOs help solve the double-spending problem as assets on the RGB++ Layer inherit Bitcoin's security. The above scenario is not limited to isomorphic binding between Bitcoin and CKB but also applies to a broad scope of chains including Cardano, Liquid, Litecoin, etc. Implementation Principle and Supported Scenarios of Leap The Leap function is basically to switch the UTXO bound to RGB++ assets e.g. changing the binding from Bitcoin to Cardano, after which you can control RGB++ assets using Cardano accounts. In such an instance, a transfer could still be made on the Cardano chain afterward, splitting and transferring the UTXO controlling RGB++ assets to more people. While RGB++ assets can be transferred and distributed on multiple UTXO public chains, they can bypass the traditional cross-chain bridge Lock-Mint model. In this process, the CKB public chain plays a role similar to an indexer, witnessing and processing Leap requests. Suppose you want to transfer RGB++ assets bound to BTC to a Cardano account, the core steps to follow are: Publish a Commitment on the Bitcoin chain, declaring the unbinding of the Cell bound to the BTC UTXO; Publish a Commitment on the Cardano chain, declaring the binding of the Cell to the Cardano UTXO; Change the locking script of the Cell, changing the unlock condition from a Bitcoin account private key to a Cardano account private key Publish a Commitment on the Bitcoin chain, declaring the unbinding of the Cell bound to the BTC UTXO; Publish a Commitment on the Bitcoin chain, declaring the unbinding of the Cell bound to the BTC UTXO; Publish a Commitment on the Cardano chain, declaring the binding of the Cell to the Cardano UTXO; Publish a Commitment on the Cardano chain, declaring the binding of the Cell to the Cardano UTXO; Change the locking script of the Cell, changing the unlock condition from a Bitcoin account private key to a Cardano account private key Change the locking script of the Cell, changing the unlock condition from a Bitcoin account private key to a Cardano account private key Take note that the RGB++ asset data is still stored on the CKB chain throughout this process. The unlock condition is changed from a Bitcoin private key to a Cardano private key. Of course, the specific execution process is much more complex than described above but we won't elaborate on it here. In the leap to non-CKB public chains, the implicit premise is that the CKB public chain acts as a third-party witness, indexer, and DA facility. This is because, as a public chain, its credibility far exceeds traditional cross-chain bridge methods such as Multi-Party Computation (MPC) and multi-signature. Another interesting scenario that can be implemented based on the Leap function is "full-chain transactions". An example of this scenario is when an indexer is set up across Bitcoin, Cardano, and CKB to build a trading platform that allows buyers and sellers to trade RGB++ assets. In such an instance, buyers can transfer their bitcoins to sellers and receive RGB++ assets with their Cardano accounts. Throughout the process, the data of RGB++ assets is still recorded in Cells which are transferred to the buyer and their unlock permissions are changed from the seller's Bitcoin private key to the buyer's Cardano private key. Wrapper Although the Leap function is perfect for RGB++ assets, there are still some bottlenecks: For Bitcoin and Cardano, RGB++ assets are essentially inscriptions/runes/colored coins based on the OP_RETURN opcode. The nodes of these public chains cannot perceive the existence of RGB++ assets, as CKB participates in 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 like BTC and ADA. As a remedy, the RGB++ Layer introduced Wrapper, a bridge based on fraud proofs and over-collateralization. Taking the rBTC wrapper as an example, it bridges BTC to the RGB++ Layer. A set of smart contracts running on the RGB++ Layer monitors the guardians of the bridge. If the guardians act maliciously, their collateral will be slashed. If they collude to steal locked BTCs, rBTC holders will be made to receive full compensation. With the combination of Leap and Wrapper, various assets in the BTCFi ecosystem e.g. RGB++ native assets, BRC20, ARC20, runes, etc., can be bridged to other layers or public chains. The following diagram shows part of the usage process of LeapX. It supports the interoperability of almost all mainstream BTCFi assets to different ecosystems. There are corresponding processing flows for assets issued in different ways with some using either wrappers or Leap. 3. CKB-VM: The Smart Contract Engine for BTCFi Due to a lack of support for smart contracts in traditional BTCFi, only relatively simple decentralized applications (dApps) can be implemented in the evolving space. Some implementation methods may have certain centralization risks, while others are rather clumsy or inflexible. To have a blockchain-available smart contract layer, CKB introduced the CKB-VM through the RGB++ Layer. It aims to make it possible for any programming language that supports the RISC-V virtual machine to be used for contract development on the RGB++ Layer. It enables developers to use their preferred tools and languages to develop and deploy efficient and secure smart contracts under a unified smart contract framework and execution environment. Generally, the entry requirements for developers' smart contract development with RISC-V are relatively low because of its extensive language and compiler support. Of course, language is only one aspect of programming, and learning specific smart contract frameworks is inevitable. However, with the RGB ++ Layer, the logic can be easily rewritten in JavaScript, Rust, Go, Java, and Ruby, rather than learning a specific DSL language to write contracts. The diagram below shows a method for transferring user-defined tokens (UDT) with CKB using C language. Aside from the different languages, its basic logic is the same for general tokens. 4. Native AA Ecosystem: Seamlessly Connecting BTC and RGB++ Finally, since BTCFi is to essentially provide diverse DeFi experiences for native Bitcoin assets, understanding the account abstraction ecosystem behind RGB++ Layer along with its mainstream Bitcoin wallets is an important factor for the BTCFi peripheral facilities to consider. RGB++ Layer directly reuses CKB's native AA solution, which is compatible with main UTXO public chains like BTC and Cardano on both the developer and the user sides. With the RGB++ Layer, different signature algorithms can be used for authentication. That is, users can directly manipulate assets on the RGB++ Layer using BTC, Cardano, or even WebAuthn accounts, wallets, or authentication methods. An example is the wallet middleware, CCC, which can provide various public chains’ operability to CKB for wallets and dApps. The following image shows the connection window of CCC and how it supports mainstream wallet entries such as Unisat and Metamask. Another example is the implementation of WebAuthn with JoyID, a CKB ecosystem wallet, being a typical representative. JoyID users can directly authenticate their accounts through biometric methods (such as fingerprint or facial recognition) to achieve seamless and highly secure login and identity management. It can be said that the RGB++ Layer has a complete native AA solution, which can also accommodate the account standards of other public chains. This feature not only facilitates support for some key scenarios, but also clears obstacles for UXs. Summary This article introduced the core technologies of the RGB++ Layer without explaining several complex details. It highlights that the RGB++ Layer can be an important infrastructure for realizing full-chain interaction scenarios including for various meme coins and inscriptions/runes/colored coins. The layer’s RISC-V-based smart contract execution environment can also help create the soil for the complex business logic required by BTCFi to grow. As the RGB++ Layer progresses, a more thorough analysis of the series of technical solutions related to the project will be provided. Please stay tuned!