Original Author: Bill, Waterdrip Capital; Marvin & Neo, Infinitas;
Guiding Expert: Hong Shuning
In the world of crypto assets, Bitcoin is undoubtedly the most well-known presence. However, when people talk about Bitcoin, they often only focus on its price, market value, and trading volume, while ignoring its technological innovation and application potential. Many core technologies mentioned in our "DeFi Research on the Bitcoin Lightning Network" released last year have made substantial breakthroughs in the first half of this year, such as:
Lightning Labs launched the Taproot Assets v0.2 (formerly known as Taro) test network;
OmniBOLT went live on the Mainnet and achieved the sending and receiving of USDT through the Lightning Network;
The RGB protocol introduced a more powerful, flexible, and secure RGB v0.10 version.
……
Speaking of the RGB protocol, people may be both familiar and unfamiliar with it. Familiarity comes from the concept of RGB being proposed as early as 2016, and many people are aware of the existence of the RGB protocol. However, after several years of development, it has not received widespread attention and application, and people seem unable to find specific use cases for the RGB protocol.
After conducting research and analysis, we believe that the main reason for this phenomenon is that in the early versions of the RGB protocol, its functionality was relatively limited, and the concept of the RGB protocol is highly original and unique, with a considerable technical stack. Developers need to have a deep understanding of the principles of Bitcoin and smart contracts before they can easily use it. However, with the continuous development and improvement of the RGB protocol, this situation is changing.
I. Getting to Know RGB
1. What is RGB
RGB is a scalable and confidential smart contract system for Bitcoin and the Lightning Network developed by the LNP/BP Standards Association. It adopts the concepts of private and common ownership and is a Turing-complete, trustless distributed computing form that does not require the introduction of non-block decentralized protocols.
The design purpose of RGB is to run scalable, robust, and private smart contracts on UTXO blockchains (such as Bitcoin) to achieve all possibilities. Through RGB, developers can execute tasks such as token issuance, NFT minting, DeFi, DAO, and more complex multi-category smart contracts.
The RGB protocol is based on the concept of client-side validation and single-use seals proposed by Peter Todd in 2016, and it runs client-side state validation and smart contract systems on the second and third layers (off-chain) of the Bitcoin ecosystem. (Below is a brief introduction to these two concepts. Interested readers can refer to Peter Todd's original paper: https://petertodd.org/2017/scalable-single-use-seal-asset-transfer)
Client-side validation:
Client-side validation is a paradigm proposed by Peter Todd in 2016. The core idea is that in a distributed system, state validation does not require all parties participating in the decentralized protocol to globally execute; instead, only the parties involved in specific state transitions need to verify. Using this method, state transitions are not published to the global network but are transformed into a short encrypted commitment through the use of cryptographic hash functions, which needs to be part of some form of "proof-of-publication" medium and possess the three main characteristics of receipt proof, non-publication proof, and membership proof. The first client-side validation system is the OpenTimeStamps protocol, also proposed and developed by Peter Todd between 2014 and 2016.
Single-use seals:
Analogous to the disposable seals used to protect shipping containers in the real world. The primitive of single-use seals is a unique object that can only encapsulate a message once, ensuring that the message can only be used once and once used, it is permanently opened and cannot be resealed. In short, single-use seals are an abstract mechanism used to prevent double spending.
2. RGB Brief History
The initial conception of RGB can be traced back to 2016, when Giacomo Zucco (BHB Network) proposed it based on Peter Todd's early ideas about client-side validation and single-use seals. It was implemented by BHB Network in the original MVP in 2017 and received support from the Poseidon Group.
In 2019, Maxim Orlovsk and Giacomo Zucco jointly established the LNP/BP Standards Association (https://www.lnp-bp.org) with the aim of promoting RGB from the conceptual stage to practical application. The association received support from Fulgur Ventures, Bitfinex, Hojo Foundation, Pandora Prime, and DIBA.
(Maxim Orlovsk)
Since 2019, Dr. Maxim Orlovsky has served as the main designer and chief contributor of the RGB protocol, designing and implementing the current form of the RGB protocol. Since 2019, RGB has been rethought and redesigned in terms of design and protocol peer review, becoming a universal computing and confidential smart contract system.
In 2021, the LNP/BP Standards Association successfully demonstrated that RGB was equipped with a Turing-complete virtual machine (AluVM), and RGB also began to run on the Lightning Network, using a complete Rust reimplementation of the Lightning protocol conducted by Dr. Maxim Orlovsky at the association (LNP Node).
In 2022, the LNP/BP Standards Association launched a new website (contractum.org) for the Contractum language (a new high-level language), which is used to write RGB smart contracts for Bitcoin and the Lightning Network. Contractum is a functional declarative programming language designed specifically for developing smart contracts using RGB technology on Bitcoin and the Lightning Network.
This year, in April 2023, the LNP/BP Association announced the release of RGB v0.10, another important milestone in the development of the RGB protocol, bringing full support for smart contracts to Bitcoin and the Lightning Network. This is the result of long-term cross-industry collaboration between Bitcoin developers, contributors, related companies, and over four years of extensive development work. (RGB v0.10 can be downloaded and installed at https://rgb.tech, and the website also contains many user and developer guides. The RGB source code can be found at https://github.com/RGB-WG.)
II. Understanding RGB:
1. Background
For many years, some projects and teams have been researching protocols for issuing tokens on Bitcoin and attempting to make them compatible with the Lightning Network, including representatives such as OmniBOLT, Taproot, and RGB.
We are familiar with protocols for issuing tokens on Bitcoin, such as OmniLayer, which work by "coloring" Bitcoin transactions with metadata to indicate that the transaction should be understood as a token transfer. USDT (Tether) in the Omni protocol can be seen as a form of colored coins. In the Omni protocol, USDT exists in the form of Tether tokens, and it is represented by using specific transaction types of the Omni protocol in Bitcoin transactions. Specifically, when a user initiates a USDT transaction on the Omni protocol, they add a special data field of the OmniLayer to the Bitcoin transaction to indicate that the transaction involves the transfer of USDT tokens. This allows Bitcoin transactions to represent the transfer of USDT tokens, and holders of USDT can use Bitcoin addresses to receive, send, and store USDT tokens.
This signaling mechanism is usually implemented using the OP_RETURN opcode, and outputs with this opcode are ignored by regular Bitcoin nodes but can be interpreted by nodes that are aware of these token protocols, which implement the validation rules of the token protocol.
Although this design is efficient, it also has certain limitations:
1) The amount of information related to token transfers is limited to the number of bytes that the OP_RETURN output can accommodate, generally around 80 bytes, which is sufficient for encoding regular transaction data, but it is difficult to meet the needs of more complex application scenarios.
2) Token protocol nodes need to scan the entire blockchain and search for token transfers related to users in OP_RETURN outputs, and the entire process becomes more resource-intensive due to the growth of the Bitcoin blockchain.
3) In terms of user privacy, all transaction data is visible to everyone.
2. RGB's Solution: Off-chain Transfer
With the aim of optimizing this design, the RGB protocol proposes a more scalable, more private, and more future-oriented solution, the cornerstone of which is the concept of client-side validation and single-use seals proposed by Peter Todd in 2016.
The core concept of the RGB protocol is to call the Bitcoin blockchain only when necessary, using proof of work and decentralized network to achieve double spending protection and censorship resistance. The validation work for all token transfers is removed from the global consensus layer and placed off-chain, verified only by the client of the receiving party.
Operation Principle:
In an RGB contract, the genesis tokens belong to a Bitcoin UTXO (whether existing or temporarily created). To transfer tokens, you need to spend this UTXO. When spending this UTXO, the Bitcoin transaction must include an additional output containing a commitment to a message, which is the RGB payment information defining the input, where the tokens will be sent, asset ID, quantity, spending transaction, and other additional data.
If you have tokens belonging to the #1 output of Bitcoin transaction A, to transfer these tokens, you need to create an RGB transaction and a Bitcoin transaction spending the #1 output of transaction A, with the Bitcoin transaction committing to the RGB transaction. As seen, the RGB transaction transfers the tokens from the #1 output of Bitcoin transaction A to the #2 output of Bitcoin transaction C (not shown in the diagram), rather than transferring to Bitcoin transaction B. In most cases, transaction B's #0 output is expected to be the change address, to return the remaining funds to the original owner after deducting miner fees, while the #1 output is to commit to the RGB transaction to avoid double spending.
Privacy Protection:
To transfer RGB tokens belonging to a Bitcoin transaction, a Bitcoin transaction needs to be initiated. However, the outputs of RGB transfers do not need to match the outputs of the Bitcoin transaction. In the example above, the output of the RGB transaction (the #2 output of Bitcoin transaction C) can be unrelated to the Bitcoin transaction committing to the RGB transaction (transaction B). This means that RGB tokens can be "transferred" from one UTXO to another without leaving any trace in the Bitcoin transaction graph, greatly enhancing privacy.
In this design, Bitcoin's UTXO acts as a one-time container for loading RGB assets. To transfer assets, you only need to open a new container and close the old one.
The specific payment information of RGB tokens is transmitted off-chain through a dedicated communication channel from the payer's client to the receiver's client, and is verified by the latter to ensure compliance with the rules of the RGB protocol. As a result, blockchain observers cannot obtain any information about RGB user activity.
Verification Loop:
However, verifying the received payment information is not enough to ensure that the sender actually owns the assets they want to send to you. To ensure that the received transactions are final, you must also receive the entire transaction history of these tokens from the payer, from the current transaction all the way back to the initial issuance. By verifying the entire transaction history, you can ensure that the assets have not been inflated and that all spending conditions attached to the assets have been met.
This design also benefits scalability, as you do not need to verify the entire history of these assets, only the part relevant to you. Additionally, the design of not broadcasting transactions to the global ledger also enhances privacy, as fewer people are aware of your transactions.
Blinding Secret Values:
To further enhance privacy, RGB also supports blinding of outputs, meaning that when you request a payment from the payer, you do not need to reveal the UTXO used to receive the tokens, but instead request the payer to send the tokens to a hash value. This hash value is generated by concatenating the target UTXO with a randomly blinded secret value. This way, the payer cannot know which UTXO the tokens will be sent to, and exchanges and other service providers cannot know if the user is withdrawing to a UTXO "blacklisted" by some regulatory agencies, or how these tokens will be spent in the future. It is important to note that when the tokens are spent, the blinding secret value must be revealed to the receiver so that they can verify the part related to the Bitcoin transaction in the transaction history. This means that when using RGB, you have complete privacy at the moment, but the confidentiality of past financial activities will degrade as the tokens are transferred, eventually approaching the same level of privacy as our Bitcoin transaction history.
3. Main Features of RGB
From the understanding of the above content, we can summarize the main features of RGB as follows:
- High confidentiality, security, and scalability
- No congestion of the Bitcoin time chain, as transactions only retain homomorphic commitments that require additional storage
- Future upgradability without the need for hard forks
- Higher censorship resistance than Bitcoin: miners cannot see the movement of assets in transactions
- No concept of blocks and chains
It is worth noting that when we mention blockchain, it generally involves the concepts of blocks and chains, but RGB does not have the concept of blocks and chains, as it is a client-side validation technology and a non-block decentralized protocol.
III. The Infinite Possibilities of RGB v0.10
The release of RGB v0.10 marks a major breakthrough, pushing RGB into the phase of a system ready for commercial deployment. It introduces the final breaking change of consensus, aimed at maintaining full backward compatibility for future versions of RGB. Additionally, it unlocks the final set of features for fully functional smart contracts, which can be customized by contract developers.
The release of RGB v0.10 includes the consensus layer, standard library (for wallet/exchange integration, etc.), and command-line tools. The table below summarizes the main differences between the new and old versions, based on official RGB materials. For more detailed information, readers can refer to the official RGB documentation and video introductions:
https://rgb.tech/blog/release-v0-10/https://www.youtube.com/@LNPBP/videos
1. Understanding RGB v0.10
In general, the v0.10 version of the RGB protocol addresses many issues present in older versions, including limitations in smart contract development, reaching the consensus layer, encoding format restrictions, Rust Bitcoin dependencies, lack of WASM compatibility, global state and context management, integration with the Lightning Network, inflexible backup processes, and inadequate support for mobile wallets. These improvements make the RGB protocol more powerful, flexible, and secure, laying a solid foundation for future development. Specifically, the RGB v0.10 version introduces the following feature support:
Global State in RGB Contracts
RGB introduces the concept of global state, which is crucial for building complex applications on RGB (such as synthetic assets, algorithmic stablecoins, etc.). Now, each RGB contract has global state accessible to the virtual machine and clients (such as wallets).
Contract Interfaces
The interfaces introduced in this version represent a standardized way to pass various smart contracts through a clearly defined API. Interfaces can be compared to contract ABIs and ERCs in the Ethereum world, but unlike Ethereum, they do not require mandatory standardization (such as ERC) or separate distribution, but are always packaged with the contract. By using interfaces, wallets and other software can provide users with a semantically aware user interface for handling contracts. Contract developers can also add more interfaces to their existing contracts over time without updating the immutable contract itself.
Basic Structure of RGB Smart Contracts
RGB smart contracts consist of Genesis, State, and Transitions. Genesis defines the basic properties and rules of the contract, State is the current state of the contract, and Transitions are the transitions between states. RGB v0.10 introduces a new smart contract model that is more flexible and powerful, capable of supporting various complex application scenarios.
Strict Type System
The new encoding format refers to the "strict types" system, a new functional data type system for representing and introspecting the state of RGB contracts. It allows for compile-time guarantees of the size of any data, simplifying operations on RGB in low-end and limited memory devices (such as hardware wallets). The entire RGB consensus layer is now compiled as strict types, allowing for formal proofs of binary compatibility between releases.
In other words, this new encoding format will make the use of RGB simpler and safer, and will also allow asset issuers and contract developers to use additional metadata to sign their assets or contracts, which will help verify the identity of assets or contracts.
Writing Contracts in Rust
Contracts can be written and compiled in Rust for RGB smart contracts. With the existence of strict types, Rust data types can now be directly compiled into RGB contracts.
State Introspection
Contracts can introspect their own state in the validation code used by the virtual machine, opening up possibilities for writing complex contract forms that interact with Bitcoin transactions, DLC, and other complex data.
URL-based Invoice Format
Previously, RGB used invoices encoded in Bech32m, which were very long, difficult to read, and most software could not automatically open them. The new format is shorter, easier for users to verify, and can be automatically opened as a pre-configured software link.
WASM Support
The RGB standard library can run without I/O and file system access, meaning it can run in web pages or browser plugins.
Taproot Descriptors and Custom Derivation
RGB v0.10 Breakthroughs
RGB uses Taproot-based OP_RETURN commitments (referred to as tapret), which need to be supported at the descriptor level so that wallets can consider transactions with adjusted outputs as belonging to the wallet descriptor. The new version also introduces custom derivation indexes to prevent non-RGB wallets from accidentally spending outputs with RGB assets (thus breaking the assets).
Simplified Dependency
The RGB consensus layer now uses fewer dependencies, improving the stability of the API. LNP/BP has abandoned the dependency on a custom bulletproofs implementation from the Grin project.
Simplified Integration
Many operations that previously required multiple API calls and complex cross-language encoding of data structures can now be completed with a single API call. RGB contract states are represented as JSON objects, allowing serialization between different languages without cumbersome operations.
Simplified User Experience
Previously, when using RGB, wallets or users had to run an RGB node and interact with the interface through RPC (or CLI tools), using many other libraries and command-line tools to perform most PSBT operations. In the new version, this complex stack is replaced by a single API library and the rgb command-line tool.
2. Major Breakthroughs of RGB v0.10
As mentioned earlier, we believe that the main reason why RGB has not received widespread attention and application despite several years of development is due to the challenges faced by independent developers in complex smart contract development. However, with the research on the RGB v0.10 version, we have reason to believe that this phenomenon is about to change, and change is already happening.
1. Why Couldn't Independent Developers Develop Complex Smart Contracts in Previous Versions?
In previous versions before RGB v0.10, independent developers faced some challenges in developing complex smart contracts. This was mainly due to the following reasons:
1) Protocol instability: In the early versions, the RGB protocol may undergo significant changes, which could render previously developed smart contracts unable to run on the new version of the protocol. This instability could hinder developers from engaging in complex smart contract development.
2) Lack of tools and resources: In the early versions, there may have been a lack of sufficient tools and resources to assist developers in complex smart contract development. This includes a lack of detailed documentation, tutorials, or development tools.
3) Protocol complexity: The design and implementation of the RGB protocol may be quite complex, which could pose a challenge to independent developers. For example, the RGB protocol uses a novel validation mechanism called "client-side validation," which may require developers to have a deep understanding and specialized knowledge to engage in complex smart contract development.
However, as the RGB protocol has evolved, these issues are being addressed. For example, the new type system introduced in the RGB v0.10 version, called "strict types," can help developers engage in complex smart contract development more easily. Additionally, this version provides more tools and resources to help developers understand and use the RGB protocol.
2. Enabling Full Support for Smart Contracts in the Lightning Network
Because RGB is built on Bitcoin, theoretically, it is feasible to use the Lightning Network to transfer RGB assets. However, in previous versions, due to architectural limitations, RGB could not be used in any existing Lightning nodes. In 2021, RGB developed its own architecture, called LNP Node, and implemented it in Rust. It does not depend on Bitcoin Core itself, and if users want to combine RGB with Taproot in the Lightning Network, they need to wait for Rust-bitcoin to complete its support for Taproot.
Now, with the release of RGB v0.10, the LNP/BP Association has announced its focus on completing support for the Lightning Network in the coming months, allowing RGB assets to be transferred via the Lightning Network.
If RGB achieves compatibility and support for the Lightning Network, it can improve the liquidity and availability of RGB assets. Through the Lightning Network, users can transfer RGB assets quickly and inexpensively without waiting for confirmations on the Bitcoin mainnet. This is very useful for users who need to frequently trade RGB assets.
More importantly, RGB may bring full support for complex smart contracts to the Lightning Network.
The Lightning Network offers amazing speed, extremely low fees, and excellent security. However, because Bitcoin itself does not support complex smart contracts, the Lightning Network has been somewhat limited in terms of smart contracts.
RGB's ability to support complex smart contract functionality is due to its carefully designed protocol, specifically created to implement smart contracts on the Lightning Network. First, RGB adopts the Turing-complete virtual machine (AluVM), a powerful computing engine that allows complex smart contracts to run on the Lightning Network. AluVM enables RGB to handle complex computational logic and data operations, enabling various types of smart contracts.
RGB fully considers the characteristics and requirements of the Lightning Network, and may bring the ability to fully support complex smart contracts to the Lightning Network, whether it's DeFi, NFT, GameFi, or SocialFi, RGB has the potential to be implemented on the Lightning Network.
This unparalleled combination may not only make the Lightning Network a shining star, but also overshadow other blockchains. With more funds and developers entering the development of the Bitcoin Lightning Network and RGB, it is expected to take the Bitcoin and Lightning Network ecosystem to new heights.
3. Comparison with Other Solutions
1. Token Protocols Based on Altcoins
Most token protocols based on altcoins (such as ERC-20) provide smart contracts with global unowned state, making it easy to deploy decentralized exchanges and other financial applications. However, they are difficult to scale, lack privacy, and inherit the disadvantages of altcoins, such as high operating costs for running nodes and lower decentralization and censorship resistance.
2. Liquid Assets
Liquid is a Bitcoin federated sidechain that offers interesting features such as native asset support and confidential transactions (which can hide the ID and quantity of transferred assets). However, the federated model also has issues with low decentralization and weak censorship resistance.
3. OmniBOLT
OmniBOLT is a Lightning Network-compatible version of OmniLayer. OmniLayer has been briefly introduced earlier (interested readers can also read "DeFi Research on the Bitcoin Lightning Network" for a more detailed introduction).
The trade-offs of OmniBOLT are very similar to RGB, with the difference being the design goals of these two protocols. Compared to RGB, OmniBOLT is relatively weaker in terms of privacy, as token-related data, like Bitcoin, is stored on the chain. However, OmniBOLT has a unique advantage in stablecoin payment business and has been tested over time. In June of this year, the Mainnet was launched, enabling the sending and receiving of USDT via the Lightning Network.
4. Taproot (Taro)
At the Bitcoin 2022 Miami conference, Taro was released. Taro is backed by the Lightning Labs team, and the protocol aims to bring assets to the Lightning Network. According to the released technical specifications, the entire design is very similar to RGB, with similar features and trade-offs.
The main difference between RGB and Taro seems to be:
1) RGB is earlier and has published auditable code, but lacks funding and operational personnel.
2) Taro is currently only a specification, but on the other hand, Taro is backed by Lightning Labs. The team raised $70 million in funding in April last year and launched the Taproot Assets v0.2 (formerly known as Taro) testnet in May this year.
It is currently unclear whether there are incentive factors for interoperability between Taro and RGB.
5. Notable RGB Ecosystem Projects/Development Teams
1. Infinitas
Website: https://www.iftas.tech/
Infinitas is one of the earliest projects to open the track of building Turing-complete smart contracts based on Bitcoin. As a Bitcoin application ecosystem network that integrates the RGB protocol and the Lightning Network, it aims to achieve higher privacy protection, superior throughput, and excellent low-latency transaction processing. Infinitas, as an innovative blockchain solution, has been solidifying the idea of Bitcoin Turing-complete smart contracts based on RGB since 2021, fully leveraging the security and consensus mechanism of Bitcoin, allowing for the creation of more complex applications and smart contracts on the Bitcoin network, with the hope of providing users with an excellent trading experience. The project's technical core is led by a team of top blockchain scientists who are the builders of the underlying code of Bitcoin, and were the earliest to focus on the RGB protocol and conduct related work. Infinitas will prioritize providing online IDE, data browsers, and access to mainstream wallets to allow developers and users to participate in the ecosystem, truly supporting the landing of large-scale commercial applications such as RWA and whole-chain games.
Project Features:
Protection of the entire network's hash power: Inherits the high security of the Bitcoin blockchain, ensuring that Infinitas assets are protected by the entire network's hash power, enhancing the security of the assets.
Higher-level privacy protection: Achieves higher-level privacy protection for Infinitas assets and introduces a trustless Bitcoin anchoring mechanism, further strengthening user privacy.
Adapter technology: Through Infinitas adapter technology, users can gain a comprehensive understanding of the complete state of Bitcoin, enhancing their awareness of asset status.
Rich global state: By improving and expanding the global state of RGB, it provides access interfaces for virtual machines and clients (such as wallets). Special emphasis is placed on trust in smart contract addresses, which critically supports the construction of complex applications in the RGB ecosystem. This measure also enables different systems to understand and interpret each other's states, further driving the development of the entire ecosystem.
Optimized Lightning Network: Through improvements to the Lightning Network (such as light block technology, automatic node scaling technology, and autonomous capabilities when offline), it achieves higher transaction throughput while maintaining low-latency transaction confirmation times.
Developers Friendly: Using the Rust language and the Schema layer as a development infrastructure can allow ordinary people to participate in development.
It is reported that Infinitas will have its native economic incentive program, and will initially use mining to produce output in the market to promote the long-term development of the ecosystem. As a priority in the industry to build a Turing-complete Bitcoin application ecosystem project, it may become a phenomenon-level ignition point for Bitcoin asset applications and a major leap forward in promoting large-scale adoption of Crypto. The testnet is not yet online, but can be kept under observation.
2. COSMINMART
COSMINMART is a new Bitcoin application ecosystem based on the Lightning Network, compatible with protocols such as RGB, and supports smart contracts.
COSM Wallet: The core product under COSMINMART, widely applicable in the entire Bitcoin ecosystem, now supports Bitcoin mainnet and Lightning Network transfers, RGB protocol asset transfers, and will gradually be compatible with ecosystems such as Stacks and Rootstock.
COSM Market: It is currently one of the early platforms supporting aggregated trading of Bitcoin derivative assets and will gradually expand its support to provide convenience for various types of Bitcoin derivative asset trading.
COSM Launchpad: Aims to select Bitcoin ecosystem projects with high potential and is committed to the sustainable development of the Bitcoin ecosystem.
COSMINMART has pioneered the concept of Web4, actively promoted the new RGB protocol standard, issued stablecoins on the Lightning Network, combined with protocols such as Nostr, and leveraged the advantages of the Lightning Network for transactions, deeply integrating traditional apps with the Lightning Network, hoping to lead a new era of Lightning Applications.
It is planned that COSMINMART will launch a public beta product by the end of this year, and can be kept under observation.
3. Pandora Prime Inc
https://pandoraprime.ch/
Pandora Prime is a Swiss company headquartered in Verify Valley, Nastattel, and is also a founding member of LNP/BP.
Pandora Prime is dedicated to pioneering Bitcoin finance using the combination of RGB smart contracts and the Lightning Network. They start with programmable assets on Bitcoin (RGBTC and CHFN), which can be extended to VISA/MasterCard-level transaction throughput via the Lightning Network. Additionally, they provide facilities for exchanging these assets without cumbersome KYC procedures for transactions below 1,000 Swiss francs (in compliance with Swiss law). Currently, their products include MyCitadel (wallet), RGB Explorer (browser), and Pandora Network.
MyCitadel
MyCitadel is a brand of Pandora Prime and is the first graphical user interface wallet that supports RGB, created by RGB developers in 2021. It provides cross-platform desktop wallets and iOS/iPad wallets. The mobile wallet can handle fungible and non-fungible RGB assets.
RGB Explorer
https://rgbex.io/
RGB Explorer is the first browser developed by Pandora Prime to provide RGB asset registration and smart contracts. It currently supports RGB20, RGB21, RGB25, and can display assets such as LNPBP, RGBTC, dCHF, and RGBEX.
4. DIBA (DIGIT ALBITCOIN ART)
https://diba.io/
DIBA is committed to promoting community development by helping people understand, own, and use non-custodial digital assets built on Bitcoin. It aims to shape digital art and asset economies based on decentralized and inclusive empowerment principles.
DIBA is the first market to trade Bitcoin NFTs using the RGB smart contract protocol and the Lightning Network (referred to as DIBA). Currently, the DIBA BETA is running on the Bitcoin testnet and will soon be launched on the Bitcoin mainnet, and can be kept under observation.
Bitmask
The wallet created by DIBA is the first NFT wallet in the RGB ecosystem, which can run in a web browser and interact with RGB contracts similar to MetaMask on Ethereum.
5. IRIS Wallet
https://play.google.com/store/apps/details?id=com.iriswallet.testnet&pli=1
IRIS Wallet, the first Android wallet developed by the Bitfinex team, is dedicated to RGB integration and RGB-related tools. It supports fungible and non-fungible assets. Iris Wallet supports RGB asset operations from issuance to spending and receiving, packaging all functions in a familiar wallet application and abstracting technical details as much as possible. This is currently an experimental application and is recommended for use with small amounts of Bitcoin and low-value assets.
6. Bitswap-BiFi
https://github.com/BitSwap-BiFi/Bitswap-core
The RGB ecosystem is actively exploring DEX solutions to address the liquidity issues of RGB assets. In the Bitswap demonstration and concept verification, it demonstrates how to introduce "SWAPS" into DEX, but currently does not have AMM or LP. It is currently in the verification stage, very early, and also worth keeping an eye on.
Review and Outlook
The RGB protocol has evolved over nearly 6 years from its initial conception to the present. Although the RGB protocol has not yet received widespread attention and application, historical experience tells us that people often overestimate the rapid spread of new ideas and underestimate the disruptive impact and speed that these ideas may have when widely accepted. In fact, with the release of the RGB protocol v0.10, we are standing at a new starting point, witnessing a future with infinite possibilities, much like Bitcoin.
The new version of the RGB protocol introduces a series of important updates, enabling the RGB protocol not only to issue and transfer multiple assets on the Bitcoin network and Lightning Network but also to support more complex smart contracts. Although the RGB protocol has not fully achieved compatibility with the Lightning Network, we firmly believe that in the coming months, the LNP/BP Association and related development teams are expected to make significant progress. With the expectation of the perfect integration of the RGB protocol with the Lightning Network, this will be a manifestation of another important milestone for the RGB protocol and Bitcoin.
The new features and improvements brought by the RGB protocol, especially the full compatibility with the Lightning Network, have ignited a beacon for the future of Bitcoin. These changes have opened the door to unknown territories, allowing us to see the infinite potential of Bitcoin. In these unknown territories, Bitcoin is no longer just a simple means of payment but a powerful platform capable of supporting complex applications. The RGB protocol has become the cornerstone of building this platform and may lead us into a new era of the Crypto world.
References:
https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
https://medium.com/@FedericoTenga/understanding-rgb-protocol-7dc7819d3059
https://www.contractum.org/
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
