Explaining RGB Protocol Exploring a New Second Layer for Bitcoin Asset Issuance

RGB Protocol is a new second layer for issuing Bitcoin assets.

Author: Bill, Waterdrip Capital; Marvin & Neo, Infinitas

Guiding Expert: Hong Shuning

Introduction:

About 4.5 billion years ago, the Earth was formed

• LST will replace ETH as the new underlying asset, and LSDFi may open up a 50x growth market.
• ETH skyrockets A discussion on the future trends of the inscription pathway
• Will Wall Street scare away crypto punks after showing interest in Bitcoin?

About 3.5 billion years ago, single-celled organisms began to move

About 300,000 years ago, Homo sapiens, as modern humans, began to appear

About 150 years ago, the underlying code of modern computers began to operate rapidly

About 14 years ago, the first block of the Bitcoin blockchain, the “Genesis Block,” was born, marking the beginning of the entire Bitcoin network

About a few months ago, GPT 4.0 was released, and at the same time, many core technologies behind Bitcoin have made substantial breakthroughs collectively

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 value, and trading volume, ignoring the technological innovation 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 the Taproot Assets v0.2 (formerly known as Taro) test network;

OmniBOLT went live on the Mainnet and implemented the function of sending and receiving USDT through the Lightning Network;

The RGB protocol launched a more powerful, flexible, and secure RGB v0.10 version.

…

Speaking of the RGB protocol, people may be both familiar and unfamiliar with it. The familiarity comes from the concept of RGB 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 have difficulty finding 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 idea of the RGB protocol is highly original and unique. The technology stack is quite extensive, and developers need to have a deep understanding of the principles of Bitcoin and smart contracts before they can easily get started. 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 shared ownership and is a Turing-complete, trustless distributed computing form that does not require the introduction of non-block, decentralized protocols for tokens.

The design purpose of RGB is to run scalable, robust, and private smart contracts on UTXO blockchains such as Bitcoin, to achieve endless possibilities. With RGB, developers can perform operations such as token issuance, NFT minting, DeFi, DAO, and more complex multi-category smart contracts.

The RGB protocol is based on the concepts of client-side validation and single-use seals proposed by Peter Todd in 2016, which are client-side state validation and smart contract systems that 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:

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 perform global execution; instead, it only requires the parties involved in specific state transitions to verify. With 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 the three main characteristics of a proof of receipt, non-disclosure proof, and membership proof. The first client-side validation system is the OpenTimeStamps protocol, which was also proposed and developed by Peter Todd between 2014 and 2016.

Single-use seals:

Can be compared to disposable seals used to protect shipping containers in the real world. The primitive of a single-use seal is a unique object that can only encapsulate a message once, ensuring that this message can only be used once and once used, it is permanently opened and cannot be resealed. In short, a single-use seal is an abstract mechanism used to prevent double spending.

2. RGB 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. In 2017, it was implemented by BHB Network in the original MVP and received support from the Poseidon Group.

In 2019, Maxim Orlovsk and Giacomo Zucco co-founded the LNP/BP Standard Association (https://www.lnp-bp.org) with the aim of advancing RGB from concept to practical application. The association is supported by Fulgur Ventures, Bitfinex, Hojo Foundation, LianGuaindora Prime, and DIBA.

(Maxim Orlovsk)

Starting in 2019, Dr. Maxim Orlovsky 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 computing and confidential smart contract system.

In 2021, the LNP/BP Standards Association successfully demonstrated that RGB is equipped with a Turing-complete virtual machine (AluVM), and RGB is also running on the Lightning Network, using a complete Rust reimplementation of the Lightning protocol conducted by Dr. Maxim Orlovsky in 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) used 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 the Lightning Network.

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. It is the result of long-term cross-industry collaboration among 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, which 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 trying to make them compatible with the Lightning Network, including 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 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 OmniLayer in 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 usually implemented with 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 protocols.

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 can be accommodated in the OP_RETURN output, generally 80 bytes, which is sufficient for encoding regular transaction data, but it may not be enough for more complex use cases.

2) Token protocol nodes need to scan the entire blockchain and search for token transfers that may be relevant to users in the OP_RETURN output. The entire process will consume more resources as the size of the Bitcoin blockchain grows.

3) In terms of user privacy, all transaction data is visible to everyone.

2. RGB Solution: Off-chain Transfer

With the aim of optimizing this design, the RGB protocol proposes a more scalable, privacy-oriented, and future-oriented solution, which is 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, utilizing 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 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 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 that includes a commitment to a message, and the content of this message is the payment information of RGB, defining the inputs, which UTXO the tokens will be sent to, the asset’s ID, quantity, the 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 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 diagram), rather than 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.

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 be the same as the outputs of the Bitcoin transaction. Just like in the example above, the output of the RGB transaction (the #2 output of Bitcoin transaction C) can have no association with the Bitcoin transaction (transaction B) that commits to this RGB transaction. 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, the UTXO of Bitcoin serves as a one-time container for holding 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 verified by the latter to ensure compliance with the rules of the RGB protocol. As a result, blockchain observers will not be able to obtain any information about RGB user activity.

Verification loop:

However, receiving the payment information alone is not enough to ensure that the sender actually owns the assets they are sending to you. Therefore, in order to ensure the finality of the received transaction, 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 complete transaction history, you can guarantee that these 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 portion that is relevant to you. Additionally, the design where transactions are not broadcasted to the global ledger enhances privacy, as fewer people are aware of the existence of your transactions.

Blinding secret values:

To further enhance privacy, RGB also supports blinding of outputs. This means that when you send a payment request to the payer, you do not need to disclose the UTXO you are using to receive the tokens. Instead, you request 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. As a result, 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 on a “blacklist” of regulatory agencies, nor can they know 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 disclosed to the receiver so that they can verify the portion of the transaction history related to Bitcoin transactions. This means that when using RGB, you have complete privacy in the present, 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. 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 upgradability without the need for hard forks

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 is worth noting that when we mention the 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 and a non-block decentralized protocol.

III. The Infinite Possibilities of RGB v0.10

RGB v0.10 marks a major breakthrough, pushing RGB into the stage of soon-to-be-deployed commercial systems. It introduces the final change that breaks consensus, aiming to maintain full backward compatibility with future versions of RGB. In addition, it also unlocks the last set of features for implementing fully functional smart contracts, which can be customized by contract developers as desired.

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’s official materials. Readers who want to learn more detailed content can refer to the official RGB documentation and video introduction:

https://rgb.tech/blog/release-v0-10/ https://www.youtube.com/@LNPBP/videos

1. Interpretation of RGB v0.10

Overall, the v0.10 version of the RGB protocol resolves many issues 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, etc. 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 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 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 (such as wallets, etc.).

Contract interface

The interfaces introduced in this version represent a standardized way to pass various smart contracts through explicitly defined APIs. Interfaces can be compared to contract ABIs and ERCs in the Ethereum world. However, unlike Ethereum, they do not require mandatory standardization (like ERC) or separate distribution. Instead, they 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 contracts themselves.

The 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 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. Strict typing is a new functional data type system used for the representation and introspection of RGB contract states. It allows for compile-time guarantees on the size of any data, simplifying operations on RGB on 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 more secure. It will also enable asset issuers and contract developers to sign their assets or contracts with additional metadata, helping to verify the identity of the assets or contracts.

Writing Contracts in Rust

RGB smart contracts can now be written and compiled using Rust. With the presence of strict types, Rust data types can now be directly compiled into RGB contracts.

State Introspection

Contracts can introspect their own state in the verification 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 invoices encoded in Bech32m, which were very long, difficult to read, and could not be automatically opened by most software. The new format is shorter, easier for users to verify, and can be automatically opened as a link for pre-configured software.

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.

Tapret Descriptors and Custom Derivation

RGB uses Taproot-based OP_RETURN commitments (referred to as tapret), which requires support at the descriptor level so that wallets can consider transactions with adjusted outputs as belonging to wallet descriptors. 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 Dependencies

The RGB consensus layer now has 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 handling of 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 like 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?

As mentioned earlier, we believe that the lack of widespread attention and application of RGB is mainly due to several reasons after years of development. However, after studying RGB v0.10, we have reason to believe that this phenomenon is about to change, and change is already happening.

1. Why couldn’t independent developers engage in complex smart contract development in previous versions?

In versions prior to RGB v0.10, independent developers faced several challenges when engaging in complex smart contract development. This was primarily due to the following reasons:

1) Protocol instability: In earlier versions, the RGB protocol might 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 earlier versions, there might 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, among others.

3) Protocol complexity: The design and implementation of the RGB protocol could be quite complex, which could pose challenges for independent developers. For example, the RGB protocol employs a novel validation mechanism called “client-side validation,” which might require developers to have a deep understanding and expertise to engage in complex smart contract development.

However, with the development of the RGB protocol, 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 engaging in complex smart contract development more easily. Additionally, this version provides more tools and resources to help developers understand and utilize the RGB protocol.

2. Enabling full smart contract support for the Lightning Network

Because RGB is built on top of Bitcoin, it is theoretically feasible to use the Lightning Network to transfer RGB assets. However, in previous versions, due to architectural limitations, RGB couldn’t be used in any existing Lightning Network nodes. In 2021, RGB developed its own architecture called LNP Node, written in Rust. It is not dependent on Bitcoin Core itself, but if users want to combine RGB with Taproot in the Lightning Network, they will need to wait for Rust-bitcoin to complete its support for Taproot.

Now, with the release of RGB v0.10, the LNP/BP Association announced their future focus, which is to plan for Lightning Network support to be completed in the coming months, enabling the transfer of RGB assets through 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 require frequent trading of RGB assets.

More importantly, RGB has the potential to bring full smart contract support to the Lightning Network.

The Lightning Network offers incredible speed, extremely low fees, and excellent security. However, because Bitcoin itself doesn’t support complex smart contracts, the Lightning Network is limited in terms of smart contract functionality.

RGB’s ability to support complex smart contract functionality is due to its well-thought-out design, specifically created to enable 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 intricate computational logic and data operations, thus enabling 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 take the Bitcoin and Lightning Network ecosystems 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. However, they are difficult to scale, lack privacy, and inherit the disadvantages 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.

3. OmniBOLT

OmniBOLT is a Lightning Network-compatible version of OmniLayer. OmniLayer has been briefly introduced in the previous text (interested readers can also read “DeFi Research on the Bitcoin Lightning Network” for more detailed information).

The trade-offs of OmniBOLT are very similar to RGB, but the difference is that these two protocols have different design goals. Compared with 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. The Mainnet was launched in June this year and has realized 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 only a specification, but on the other hand, Taro is backed by Lightning Labs, which raised $70 million 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 and whether there are incentive factors to make this interoperability happen, it is currently difficult to determine.

5. RGB Ecological Projects/Development Teams Worth Paying Attention To

1. Infinitas

Official website: https://www.iftas.tech/

Infinitas is one of the earliest projects to start the 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. As an innovative blockchain solution, Infinitas has been solidifying the idea of Bitcoin Turing-complete smart contracts based on RGB since 2021, fully leveraging the security and consensus mechanisms 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 core technology of the project is led by a top-level blockchain scientist team consisting of builders of the underlying Bitcoin code who were among the first to pay attention to the RGB protocol and carry out translation-related work. Infinitas will prioritize providing online IDEs, 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 full-chain games.

Project Features:

• Protection of network hash power: Inheriting the high security of the Bitcoin blockchain, Infinitas ensures that Infinitas assets are protected by the network hash power of the Bitcoin blockchain, enhancing asset security.
• Higher level of privacy protection: Infinitas 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 a comprehensive understanding of the complete state of Bitcoin, enhancing their awareness of asset status.
• Enriched global state: By improving and expanding RGB’s global state, it provides access interfaces for virtual machines and clients (such as wallets). It particularly strengthens trust in smart contract addresses, which is crucial for building 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, node automatic scaling technology, and autonomous capabilities when offline), it achieves higher transaction throughput while maintaining low-latency transaction confirmation times.
• Developer-friendly: Using the Rust language and the Schema layer as the development infrastructure, it allows ordinary people to participate in development.

According to reports, Infinitas will have its native economic incentive scheme, which will initially adopt mining to promote the long-term development of the ecosystem in the market. As a project to prioritize the construction of 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.

2. COSMINMART

https://cosminmart.com/

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, has wide applicability in the entire Bitcoin ecosystem network, and 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 earliest platforms to support Bitcoin derivative asset aggregation trading, and will gradually expand its support range to provide convenience for various types of Bitcoin derivative asset transactions.

COSM LanuchLianGuaid: Aiming to select Bitcoin ecosystem projects with high-quality potential and dedicated to the sustainable development of the Bitcoin ecosystem.

COSMINMART takes the lead in defining the Web4 concept, actively promoting the formulation of the new RGB protocol standard, issuing stablecoins on the Lightning Network, combining advantages of protocols such as Nostr and Lightning Network transactions, deeply integrating traditional apps with the Lightning Network, and hoping to lead the new era of Lightning Applications.

It is reported that COSMINMART plans to launch its public test product at the end of this year, so stay tuned.

3. LianGuaindora Prime Inc

https://pandoraprime.ch/

LianGuaindora Prime is a Swiss company based in Verify Valley, Naters, 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 with transactions below 1,000 Swiss francs without cumbersome KYC procedures (in compliance with Swiss legal regulations). Currently, their products include MyCitadel (wallet), RGB Explorer (browser), and LianGuaindora Network, etc.

• MyCitadel

https://mycitadel.io/

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

https://rgbex.io/

RGB Explorer is the first browser developed by LianGuaindora Prime that provides RGB asset registration and smart contracts. Currently, it supports RGB20, RGB21, and RGB25, and can display four types of assets: LNPBP, RGBTC, dCHF, and RGBEX.

• DIBA (DIGITAL BITCOIN ART)

https://diba.io/

DIBA aims to enhance the development of the community by helping people understand, own, and use non-custodial digital assets built on 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.

• Bitmask

https://bitmask.app/

This wallet, created by DIBA, 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.

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 both 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 recommended for 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 issue of RGB assets. In the demonstration and concept verification of Bitswap, “SWAPS” is introduced to DEX, but there is currently no AMM or LP. It is still in the verification stage and is very early, but it is worth paying attention to.

6. Review and Outlook

The RGB protocol has gone through nearly 6 years of evolution from its initial concept. Although the RGB protocol has not 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 v0.10, we are standing at a new starting point, witnessing a future with unlimited possibilities, just like Bitcoin.

The new version of the RGB protocol introduces a series of important updates, which not only enable the issuance and transfer of various assets on the Bitcoin network and the Lightning Network but also have the ability to support more complex smart contracts. Although the RGB protocol has not fully achieved 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 the perfect integration of the RGB protocol and the Lightning Network, this will be a milestone for the RGB protocol and Bitcoin to move forward together.

The new features and improvements brought by the RGB protocol, especially its full compatibility with the Lightning Network, have ignited a beacon of hope for the future of Bitcoin. These changes have opened the doors to unknown territories, allowing us to see the infinite potential of Bitcoin. In this unknown realm, Bitcoin is no longer just a simple means of payment, but a powerful platform capable of supporting complex applications. The RGB protocol serves as the cornerstone of this platform, potentially leading us towards a brand new Crypto world.

References:

https://rgb.techhttps://rgbfaq.com

https://lnp-bp.orghttps://twitter.com/lnp_bp

https://www.youtube.com/@LNPBP/videos

https://blueprint.rgb.network

https://petertodd.org/2017/scalable-single-use-seal-asset-transfer

https://medium.com/@FedericoTenga/understanding-rgb-protocol-7dc7819d3059

https://www.contractum.org/

We will continue to update Blocking; if you have any questions or suggestions, please contact us!