In-depth Explanation of RGB Protocol Paving a New Path for Bitcoin Asset Issuance on Layer 2
Explanation of RGB Protocol Paving the Way for Bitcoin Asset Issuance on Layer 2
Author: Bill, Waterdrip Capital; Marvin & Neo, Infinitas; Advisor: Hong Shuning
Approximately 4.5 billion years ago, the Earth was formed.
Approximately 3.5 billion years ago, single-celled organisms began to move.
Approximately 300,000 years ago, Homo sapiens, as modern humans, began to appear.
- Money Games, Social Currency, and Cultural Industry Sorting Out the...
- Money games, social currencies, and cultural industries, sorting ou...
- LST will replace ETH as the new underlying asset, and LSDFi may ope...
Approximately 150 years ago, the underlying code of modern computers began to operate rapidly.
Approximately 14 years ago, the first block of the Bitcoin blockchain, the “Genesis Block,” was born, marking the beginning of the entire Bitcoin network.
Several months ago, GPT 4.0 was released. At the same time, many core technologies behind Bitcoin have made substantial breakthroughs.
At this moment, as you read these words, you may be curious and confused about RGB.
In the world of encrypted assets, Bitcoin is undoubtedly the most well-known existence. However, when people talk about Bitcoin, they often only focus on its price, market capitalization, and trading volume, while neglecting the technological innovations and application potential behind it. 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 Taproot Assets v0.2 (formerly known as Taro) testnet;
OmniBOLT went live on the Mainnet and achieved the function of sending and receiving USDT through the Lightning Network;
The RGB protocol released a more powerful, flexible, and secure version, RGB v0.10.
Speaking of the RGB protocol, people may be both familiar and unfamiliar with it. The concept derived from RGB was 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 to be 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 was highly original and unique. The technical stack is quite extensive, and developers need to have a deep understanding of the principles of Bitcoin and smart contracts to be able to use it efficiently. However, with the continuous development and improvement of the RGB protocol, this situation is changing.
1. Getting to Know RGB
1. What is RGB
RGB is a scalable and confidential Bitcoin and Lightning Network smart contract system 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 privacy-preserving smart contracts on UTXO blockchains such as Bitcoin, to achieve endless possibilities. With RGB, developers can execute complex multi-category smart contracts such as token issuance, NFT minting, DeFi, DAO, and more.
The RGB protocol is based on the concepts of client-side validation and single-use-seals proposed by Peter Todd in 2016, which enable client-side state validation and smart contract systems to run 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 is a paradigm proposed by Peter Todd in 2016. The core idea is that in a distributed system, state validation does not require all participants in the decentralized protocol to globally execute; instead, only the parties involved in specific state transitions need to perform validation. By adopting this approach, state transitions are not published to the global network, but transformed into a short cryptographic commitment using cryptographic hash functions, which needs to be part of some “proof-of-publication” medium and has three main characteristics: 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.
Can be compared to disposable seals used to protect cargo containers in the real world. The primitive of single-use-seals is a unique object that can only be used to seal a message once, ensuring that the message can only be used once and once used, it is permanently opened and cannot be sealed again. In short, single-use-seals are an abstract mechanism used to prevent double spending.
2. History of RGB
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. In 2017, BHB Network implemented it in the original MVP and received support from the Poseidon Group.
In 2019, Maxim Orlovsk and Giacomo Zucco co-founded the LNP/BP Standards Association (https://www.lnp-bp.org) with the aim of promoting RGB from concept to practical application. The association is supported by Fulgur Ventures, Bitfinex, Hojo Foundation, LianGuaindora Prime, and DIBA.
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 undergone rethinking and redesign in terms of design and protocol peer review, becoming a general-purpose computation and privacy-preserving smart contract system.
In 2021, the LNP/BP Standards Association successfully demonstrated that RGB has a Turing-complete virtual machine (AluVM). At the same time, RGB started running on the Lightning Network, using a Rust reimplementation of the complete lightning protocol by Dr. Maxim Orlovsky at the Association (LNP Node).
In 2022, the LNP/BP Standards Association launched a new website (contractum.org) for Contractum language (a new high-level language) to write RGB smart contracts for Bitcoin and Lightning Network. Contractum is a functional declarative programming language designed specifically for developing smart contracts using RGB technology on Bitcoin and Lightning Network.
This year, in April 2023, the LNP/BP Association announced the release of RGB v0.10, which is another important milestone in the development of the RGB protocol. It brings full support for smart contracts to Bitcoin and the Lightning Network. It is the result of long-term cross-industry collaboration among these Bitcoin developers, contributors, and related companies, as well as over four years of extensive development work. (RGB v0.10 can be downloaded and installed at https://rgb.tech. The website also contains many user and developer guides. The RGB source code can be found at https://github.com/RGB-WG.)
2. Understanding RGB:
For many years, some projects and teams have been researching protocols for issuing tokens on Bitcoin and trying to make them compatible with the Lightning Network. Examples include OmniBOLT, Taproot, and RGB.
One well-known protocol for issuing tokens on Bitcoin is OmniLayer, which works by inserting metadata into Bitcoin transactions to “color” them and 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 coin. In the Omni protocol, USDT exists as Tether tokens, represented by specific transaction types in the Bitcoin transaction using the Omni protocol. Specifically, when a user initiates a USDT transaction on the Omni protocol, they add a special data field from 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 USDT holders can use Bitcoin addresses to receive, send, and store USDT tokens.
This signaling mechanism is typically implemented using the OP_RETURN opcode, where outputs with this opcode are ignored by regular Bitcoin nodes but can be interpreted by nodes that are aware of these token protocols and enforce the validation rules of the token protocol.
Although this design is efficient, it has certain limitations:
1) The amount of information related to token transfers is limited to the number of bytes that can fit within an OP_RETURN output, typically 80 bytes. While this space is sufficient for encoding regular transaction data, it is not enough for more complex use cases.
2) Token protocol nodes need to scan the entire blockchain and search for token transfers that may be related to users in the OP_RETURN outputs. The entire process consumes more resources due to the growth of the Bitcoin blockchain.
2. RGB 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, based on the concepts of client-side validation and single-use seals proposed by Peter Todd in 2016.
The core idea of the RGB protocol is to call the Bitcoin blockchain only when necessary, using proof of work and network decentralization to achieve double-spending protection and censorship resistance. The validation of all token transfers is removed from the global consensus layer and placed off-chain, only to be verified by the client of the receiving party.
How it works:
In a contract in RGB, the genesis tokens belong to a Bitcoin UTXO (whether pre-existing or temporarily created), and to transfer tokens, you need to spend this UTXO. When spending this UTXO, the Bitcoin transaction must add an additional output, which includes a commitment to a message, the content of which is the payment information of RGB, defining the inputs, which UTXO the tokens will be sent to, the asset ID, quantity, the spent transaction, and other additional data.
If you have tokens that belong to the #1 output of Bitcoin transaction A, to transfer these tokens, you need to create an RGB transaction and a Bitcoin transaction that spends the #1 output of transaction A, and this Bitcoin transaction commits to the RGB transaction. As you can see, 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 figure), instead of transferring them to Bitcoin transaction B. In most cases, we can expect that the #0 output of transaction B is the change address, in order to send the remaining funds back to the original owner after deducting the miner’s fee; at the same time, the #1 output is to commit to the RGB transaction to avoid double spending.
To transfer RGB tokens that belong to a Bitcoin transaction, a Bitcoin transaction needs to be initiated. However, the outputs of the RGB transfer do not need to be the same as the outputs of the Bitcoin transaction. Just like the example above, the output of the RGB transaction (the #2 output of Bitcoin transaction C) can have no association with the Bitcoin transaction that commits to this RGB transaction (transaction B). This means that RGB tokens can be “transferred” from one UTXO to another UTXO without leaving any trace in the Bitcoin transaction graph, greatly enhancing privacy.
In this design, the role of Bitcoin’s UTXO is to serve as a one-time container for 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 dedicated communication channels, from the payer’s client to the receiver’s client, and the latter verifies that it does not violate the rules of the RGB protocol. In this way, blockchain observers will not be able to obtain any information about RGB user activity.
However, receiving the payment information is not enough to ensure that the sender actually owns the assets they want to send to you. Therefore, in order to ensure that the received transaction is final, you must also receive the complete transaction history of these tokens from the payer, from the current transaction all the way back to the initial issuance transaction. By verifying the entire transaction history, you can ensure that these assets have not been inflated and that all spending conditions attached to the assets have been met.
This design also benefits scalability because you don’t need to verify the entire history of these assets, only the part relevant to you. Moreover, the design of not broadcasting transactions to the global ledger also enhances privacy because fewer people know about the existence of your transactions.
Blinding secret value:
To further enhance privacy, RGB also supports blinding of outputs, which means that when you send a payment request to the payer, you don’t need to publicly reveal the UTXO used to receive the tokens. Instead, you ask the payer to send the tokens to a hash value, which is generated by concatenating the target UTXO with a randomly generated blinding secret value. In this way, the payer cannot know which UTXO the tokens will be sent to. Therefore, exchanges and other service providers cannot know whether users are withdrawing to UTXOs that are “blacklisted” by regulatory agencies, nor can they know how these tokens will be spent in the future. It should be noted that when the tokens are spent, the blinding secret value must be revealed to the receiver so that the receiver can verify the part of the transaction history related to Bitcoin transactions. This means that when using RGB, you have complete privacy at the moment, but future token holders will be able to see all the UTXOs in the transfer history of the tokens they hold. Therefore, although you can achieve perfect privacy when receiving and holding RGB tokens, the confidentiality of past financial activities will gradually degrade as the tokens are continuously transferred, eventually approaching the same level of privacy as our Bitcoin transaction history.
3. The main features of RGB
Based on the understanding of the above content, we can summarize the main features of RGB as follows:
1. High confidentiality, security, and scalability
2. No congestion in the Bitcoin time chain, as transactions only retain homomorphic commitments that require additional storage
3. Future upgradable without a hard fork
4. Higher resistance to censorship compared to Bitcoin: miners cannot see the flow of assets in transactions
5. No concept of blocks and chains
It’s worth noting that when we mention blockchain, it generally involves the concepts of blocks and chains. However, RGB does not have the concept of blocks and chains because it is a client-side validation technology, a non-block decentralized protocol.
III. Unlimited possibilities of RGB v0.10
RGB v0.10 marks a major breakthrough, pushing RGB into the phase of imminent commercial deployment. It introduces the final change that breaks consensus, aiming to maintain full backward compatibility for future versions of RGB. Additionally, it unlocks the final set of features for implementing fully functional smart contracts that 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 RGB official materials. Readers who want more detailed information can refer to the RGB official documentation and video introductions:
1. Interpretation of RGB v0.10
In general, the v0.10 version of the RGB protocol addresses many issues found in previous versions, including limitations in smart contract development, touchpoints of the consensus layer, limitations of encoding formats, dependencies on Rust Bitcoin, lack of WASM compatibility, global state and context management issues, integration with the Lightning Network, inflexibility in the backup process, and insufficient support for mobile wallets. These improvements make the RGB protocol more powerful, flexible, secure, and lay a solid foundation for future development. Specifically, the RGB v0.10 version introduces the following feature supports for RGB:
Global state in RGB contracts
RGB introduces the concept of global state, which is a brand-new feature that is crucial for building complex applications on top of RGB, such as synthetic assets and algorithmic stablecoins. Now, each RGB contract has a global state that can be accessed by virtual machines and clients (like wallets).
The interfaces introduced in this version represent a standardized way of passing various smart contracts through explicitly defined APIs. The interfaces can be compared with contract ABIs and ERCs in the Ethereum world. However, unlike Ethereum, they do not require mandatory standardization (like ERC) or separate distribution, but are always bundled with the contracts. By using interfaces, wallets and other software can provide users with a semantically aware user interface for interacting with contracts. Contract developers can also add more interfaces to their existing contracts over time without updating the immutable contracts themselves.
Basic components of RGB smart contracts: RGB smart contracts consist of Genesis, State, and Transitions. Genesis defines the basic properties and rules of the contract, State represents 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, which is a new functional data type system used for representing and introspecting the state of RGB contracts. It allows for compile-time guarantees on the size of any data, simplifying RGB operations on low-end and limited memory devices such as hardware wallets. The entire RGB consensus layer is now compiled as strict types, enabling formal proofs of binary compatibility between releases.
In other words, this new encoding format will make the use of RGB simpler and safer. It will also allow asset issuers and contract developers to sign their assets or contracts with additional metadata, which helps verify the identity of assets or contracts.
Writing Contracts in Rust
RGB smart contracts can now be written and compiled using Rust. With the existence of strict types, Rust data types can be directly compiled into RGB contracts.
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, DLCs, and other complex data.
URL-based Invoice Format
Previously, RGB used Bech32m-encoded invoices, which were very long, difficult to read, and most software couldn’t automatically open them. The new format is shorter, easier for users to verify, and can be automatically opened as a link for pre-configured software.
The RGB standard library can run without I/O and file system access, meaning it can run in web pages or browser plugins.
Tapret Descriptors and Custom Derivations
RGB uses Taproot-based OP_RETURN commitments (referred to as “tapret”), which require support at the descriptor level so that wallets can recognize transactions with adjusted outputs as belonging to wallet descriptors. The new version also introduces custom derivation indexes to prevent non-RGB wallets from inadvertently consuming outputs with RGB assets (thus breaking the assets).
The RGB consensus layer now has fewer dependencies, improving API stability. LNP/BP has abandoned dependencies from the Grin project’s custom bulletproofs implementation.
Many operations that previously required multiple API calls and handling complex data structures across different languages can now be done with a single API call. RGB contract states are represented as JSON objects, allowing for serialization between different languages without cumbersome operations.
Simplified User Experience
Previously, when using RGB, wallets or users had to run RGB nodes and interact with the interface through RPC (or CLI tools) – and use many other libraries and command-line tools to perform most operations such as PSBT. In the new version, this complex stack is replaced by a single API library and the “rgb” command-line tool.
2. What are the major breakthroughs in RGB v0.10?
In the previous section, we mentioned the main reasons we believe RGB has not received widespread attention and adoption despite several years of development. However, after studying RGB v0.10, we have reason to believe that this phenomenon is about to change, or even change is already happening.
1. Why couldn’t independent developers perform complex smart contract development in previous versions?
In versions prior to RGB v0.10, independent developers faced several challenges when it came to complex smart contract development. This was mainly due to the following reasons:
1) Protocol instability: In earlier versions, the RGB protocol could undergo significant changes, which could render previously developed smart contracts incompatible with the new protocol version. This instability could hinder developers from engaging in complex smart contract development.
2) Lack of tools and resources: Earlier versions may have lacked sufficient tools and resources to assist developers in complex smart contract development. This includes a lack of detailed documentation, tutorials, or development tools.
3) Complexity of the protocol: The design and implementation of the RGB protocol can be quite complex, posing a challenge for independent developers. For example, the RGB protocol utilizes 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 continues to evolve, these issues are being addressed. For example, the introduction of a new type system called “strict types” in RGB v0.10 can assist developers in easier complex smart contract development. Additionally, this version provides more tools and resources to help developers understand and utilize the RGB protocol.
2. Enabling full support for smart contracts on the Lightning Network
Because RGB is built on top of Bitcoin, it is theoretically possible to use the Lightning Network to transfer RGB assets. However, in previous versions, RGB could not be utilized within any existing Lightning Network nodes due to architectural limitations. In 2021, RGB developed its own architecture called LNP Node, written in Rust. It is independent of Bitcoin Core, and if users want to combine RGB with Taproot on 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 future focus, which is to plan 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 enhance 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 particularly useful for users who frequently trade RGB assets.
Furthermore, RGB may bring full support for smart contracts to the Lightning Network.
The Lightning Network offers amazing speed, extremely low fees, and excellent security. However, due to the fact that Bitcoin itself does not support complex smart contracts, the Lightning Network has been limited in terms of smart contract capabilities.
RGB’s ability to support complex smart contract functionality is due to its thoughtful design specifically created for implementing smart contracts on the Lightning Network. Firstly, RGB adopts a Turing-complete virtual machine called AluVM, which is a powerful computing engine that allows for the execution of complex smart contracts on the Lightning Network. AluVM enables RGB to handle complex computational logic and data operations, thus facilitating various types of smart contracts.
RGB fully considers the characteristics and needs of the Lightning Network in its design and may bring the ability to fully support complex smart contracts to the Lightning Network, whether it is DeFi, NFT, GameFi, or SocialFi, RGB may be implemented on the Lightning Network.
This unparalleled combination may not only make the Lightning Network a shining star but also make other blockchains pale in comparison. With more and more funds and developers pouring into the development of the Bitcoin Lightning Network and RGB, it is expected to bring the Bitcoin and Lightning Network ecosystem to new heights.
IV. Comparison with Other Solutions
1. Token Protocols Based on Altcoins
Most token protocols based on altcoins (such as ERC-20) provide smart contracts with a global unowned state, which makes it easy to deploy decentralized exchanges and other financial applications, but they are difficult to scale, lack privacy, and inherit the drawbacks of these altcoins, such as high operating costs for running nodes, lower decentralization, and resistance to censorship.
2. Liquid Assets
Liquid is a federated sidechain of Bitcoin that provides some interesting features, such as native asset support and confidential transactions (which can hide the ID of the transferred assets and the amount paid). However, the federated model also has the problem of low decentralization and weak resistance to censorship.
OmniBOLT is a version of the Lightning Network compatible with OmniLayer. OmniLayer has been briefly introduced earlier in this document (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, but the difference lies in the different design goals of these two protocols. Compared to RGB, OmniBOLT is relatively weaker in terms of privacy because, like Bitcoin, token-related data is stored on the chain. However, OmniBOLT has unique advantages in stablecoin payment business and has been tested over time. In June of this year, the Mainnet has been launched, and it has achieved the function of sending and receiving USDT through the Lightning Network.
4. Taproot (Taro)
Taro was released at the Bitcoin 2022 Miami conference. Taro is backed by the Lightning Labs team, and the goal of the protocol is to bring assets to the Lightning Network. According to the released technical specifications, the entire design is very similar to RGB, and the features and trade-offs are basically the same.
The main differences between RGB and Taro seem to be:
1) RGB is earlier and has published auditable code, but lacks funding and operational personnel.
2) Taro is currently just a specification, but on the other hand, Taro is backed by Lightning Labs, which 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.
If Taro and RGB can ultimately interact with each other, it is currently impossible to determine whether there are any incentive factors that enable such interoperability to occur.
5. RGB Ecological Projects/Development Teams Worth Paying Attention to
Infinitas is one of the earliest projects to start building a Turing-complete smart contract track based on Bitcoin. As a Bitcoin application ecosystem network that combines the RGB protocol and the Lightning Network, it aims to achieve higher privacy protection, excellent throughput, and outstanding low-latency transaction processing. Infinitas, as an innovative blockchain solution, has been solidifying the idea of Bitcoin’s 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, and hoping to bring users an excellent trading experience. The project’s technical core is led by a top-level blockchain scientist team consisting of Bitcoin core code builders who were among the earliest to pay attention to the RGB protocol and carry out related translation work. Infinitas will prioritize providing online IDE, data browsers, and access to mainstream wallets to allow developers and users to participate in the ecosystem and truly support the implementation of large-scale commercial applications such as RWA and whole-chain games.
Full Network Hash Power Protection: Inherits the high security of the Bitcoin blockchain, ensuring that Infinitas assets are protected by the full network hash power of the Bitcoin blockchain, enhancing asset security.
Higher Level of Privacy Protection: Achieves a higher level of privacy protection for Infinitas assets and introduces a trustless Bitcoin anchoring mechanism to further enhance user privacy.
Adapter Technology: Through Infinitas’ adapter technology, users can gain an understanding of the complete state of Bitcoin, enhancing their awareness of asset status.
Rich Global State: By improving and extending the global state of RGB, providing access interfaces to virtual machines and clients (such as wallets). Special enhancements are made, particularly in terms of trust in smart contract addresses, which crucially support the construction of complex applications in the RGB ecosystem. This measure also enables different systems to understand and interpret each other’s states, further promoting the development of the entire ecosystem.
Optimized Lightning Network: By improving the Lightning Network (such as lightweight block technology, automatic node scaling technology, and autonomous capabilities when offline), it achieves higher transaction throughput while maintaining low-latency transaction confirmation times.
Developer-Friendly: Uses the Rust language and the Schema layer as a development infrastructure, allowing ordinary people to participate in development.
It is reported that Infinitas will have its native economic incentive scheme, which will initially be produced in the market through mining to promote the long-term development of the ecosystem. As a priority project in the industry to build a Turing-complete Bitcoin application ecosystem, it may become a phenomenon-level ignition point for Bitcoin asset applications and a major leap forward in promoting the large-scale adoption of Crypto. The testnet is currently not online, so stay tuned.
COSMINMART is a new Bitcoin application ecosystem based on the Lightning Network and compatible with protocols such as RGB, supporting smart contracts.
COSM Wallet: COSMINMART’s core product, with wide applicability in the entire Bitcoin ecosystem network, currently supports Bitcoin mainnet and Lightning Network transfers, RGB protocol asset transfers, etc., and will gradually support ecosystems such as Stacks and Rootstock.
COSM Market: It is one of the earlier platforms that support the aggregation of Bitcoin derivative assets, and will gradually expand its support range to provide convenience for various types of Bitcoin derivative asset transactions.
COSM LaunchLianGuaid: Aims to screen Bitcoin ecosystem projects with high-quality potential and is committed to the sustainable development of the Bitcoin ecosystem.
COSMINMART takes the lead in defining the concept of Web4, actively promotes the formulation of the new RGB protocol standard, issues stablecoins on the Lightning Network, combines advantages of protocols such as Nostr and Lightning Network trading, deeply integrates traditional apps with the Lightning Network, and hopes to lead the new era of Lightning Applications.
It is reported that COSMINMART plans to launch public testing products at the end of this year, so stay tuned.
3. LianGuaindora Prime Inc
LianGuaindora Prime is a Swiss company headquartered in Verify Valley, Naxaltel Canton, and is also a founding member of LNP/BP.
LianGuaindora Prime is committed 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 scaled to the level of VISA/MasterCard in terms of transaction throughput through the Lightning Network. In addition, they provide convenient facilities for exchanging these assets without the need for 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 LianGuaindora Network, among others.
MyCitadel is a brand of LianGuaindora Prime. MyCitadel is the first graphical user interface wallet that supports RGB, created by RGB developers in 2021. It provides cross-platform desktop wallets and iOS/iLianGuaid wallets. The mobile wallet can handle fungible RGB assets.
RGB Explorer is the first browser developed by LianGuaindora Prime that provides RGB asset registration and smart contracts. It currently supports RGB20, RGB21, and RGB25, and can display four types of assets: LNPBP, RGBTC, dCHF, and RGBEX.
DIBA (DIGITAL BITCOIN ART)
DIBA is committed to enhancing the development of the community by helping people understand, own, and use non-custodial digital assets built on top of Bitcoin. It hopes to shape digital art and asset economy with decentralized and inclusive empowerment principles.
DIBA is the first market (referred to as DIBA) to trade Bitcoin NFTs using the RGB smart contract protocol and the Lightning Network. Currently, DIBA BETA is running on the Bitcoin testnet and will soon be launched on the Bitcoin mainnet. Stay tuned for updates.
Created by DIBA, Bitmask is the first NFT wallet in the RGB ecosystem that can run in a web browser and interact with RGB contracts similar to MetaMask on Ethereum.
4. IRIS Wallet
IRIS Wallet is the first Android wallet developed by the Bitfinex team, 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, wrapping all the functionalities in a familiar wallet application and abstracting technical details as much as possible. Currently, this is still an experimental application and is recommended for use with small amounts of Bitcoin and low-value assets.
The RGB ecosystem is actively exploring DEX solutions to address the liquidity issue of RGB assets. In the demonstration and conceptual verification of Bitswap, “SWAPS” is introduced to the DEX, but there is currently no AMM or LP. It is still in the verification stage and is very early, but it is also worth paying attention to.
6. Review and Outlook
The RGB protocol has evolved over nearly 6 years from its initial conception. Although the RGB protocol has not yet received widespread attention and application, historical experience tells us that people often overestimate the rapid popularity of new ideas while underestimating the disruptive impact and speed that these ideas may eventually be widely accepted. In fact, with the release of RGB protocol version 0.10, we are at a new starting point, witnessing a future with infinite possibilities, just like Bitcoin.
The new version of the RGB protocol introduces a series of important updates, which not only allows for the issuance and transfer of various assets on the Bitcoin network and Lightning Network, but also has the ability to support more complex smart contracts. Although the RGB protocol has not yet achieved full compatibility with the Lightning Network, we firmly believe that the LNP/BP Association and related development teams are expected to make more significant progress in the coming months. With the expectation of a perfect integration between the RGB protocol and the Lightning Network, this will be a milestone for the RGB protocol and Bitcoin.
These 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 through them. In this unknown territory, Bitcoin is no longer just a simple means of payment, but a powerful platform capable of hosting complex applications. And the RGB protocol has become the cornerstone of building this platform, possibly leading us to a brand new crypto world.