RGB Ecological 4D Research Report: Leading the Large-scale Adoption of Crypto and Brightening the Future of Bitcoin

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

Instructor: Hong Shuning

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 transaction volume, but ignore the technological innovation and application potential behind it. Many of the core technologies we mentioned in the "DeFi Research on Bitcoin Lightning Network" released last year have all made substantial breakthroughs in the first half of this year, such as:

Lightning Labs, launched Taproot Assets v 0.2 (formerly known as Taro) testnet;

OmniBOLT, launched Mainnet, and realized the function of sending, receiving and transferring USDT through Lightning Network;

RGB protocol, launched a stronger, more flexible and safer RGB v 0.10 version.

……

Speaking of the RGB protocol, people may be both familiar and unfamiliar with it. The concept of familiarity stemming from RGB was proposed as early as 2016. Many people know the existence of the RGB protocol, but after several years of development, it has not been widely adopted. Attention and application, it seems that you can't find a specific application case of the RGB protocol.

After research and analysis, we believe that the main reason for this phenomenon is that in the early version of the RGB protocol, its functions are relatively limited, and the idea of the RGB protocol is highly original and unique, and the technology stack is quite large. Developers need to It is easy to use after a deep understanding of the principles of Bitcoin and smart contracts. However, this is changing as the RGB protocol continues to evolve and improve.

1. Getting to know RGB for the first time

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 form of distributed computing that does not require the introduction of tokenized non-block decentralized protocols.

RGB is designed to run scalable, robust and private smart contracts on UTXO blockchains (like Bitcoin) to enable all possibilities. Through 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, on the second and third layers of the Bitcoin ecosystem (chain Outside) running client state verification and smart contract systems. (The following is a brief introduction to these two concepts. Interested readers can check out Peter Todd's original paper: )

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 verification does not need to be performed globally by all parties participating in the decentralized protocol; instead, only parties participating in a specific state transition need to be verified. With this approach, state transitions are not published to the global network, but are converted into a short cryptographic commitment through the use of cryptographic hash functions, etc., which needs to be some kind of "Proof-of-Publication" medium It has three main features: Proof of Receipt, Proof of Non-Publishing, and Proof of Membership. The first client-side authentication system was the OpenTimeStamps protocol, also proposed and developed by Peter Todd in 2014-2016.

Single-use-seals:

An analogy to the disposable seals used to protect shipping containers in the real world. A one-time-sealed primitive is a unique object that encapsulates a message only once, ensuring that the message can only be used once, and once used it is permanently unsealed and cannot be resealed. In a nutshell, a one-time seal is an abstract mechanism used to prevent double spending.

2. A Brief History of RGB

RGB was originally conceived back in 2016 by Giacomo Zucco (BHB Network) based on Peter Todd's early ideas on client-side validation and one-time sealing, implemented by BHB Network in the original MVP in 2017, and supported by the Poseidon Group .

In 2019, Maxim Orlovsk and Giacomo Zucco co-founded the LNP/BP Standards Association (aims to promote the stage of RGB from conception to practical application. The association is supported by Fulgur Ventures, Bitfinex, Hojo Foundation, Pandora Prime and DIBA.

（Maxim Orlovsk）

Starting in 2019, Dr. Maxim Orlovsky served as the main architect and lead contributor to the RGB protocol, designing and implementing the current form of the RGB protocol. Since 2019, RGB has been reimagined and redesigned in terms of design and protocol peer review to become a general-purpose computing and confidentiality smart contract system.

In 2021, the LNP/BP Standards Association successfully demonstrated that RGB is equipped with a Turing-complete virtual machine (AluVM). At the same time, RGB also started running on the Lightning Network, using the complete Lightning protocol developed by Dr. Maxim Orlovsky in the association. Rust reimplementation (LNP Node).

In 2022, the LNP/BP Standards Association launched a new website (contractum.org) on the Contractum language (a new high-level language) for writing RGB smart contracts for Bitcoin and LightningNetwork. Contractum is a functional, declarative programming language designed for the development of smart contracts running on Bitcoin and the Lightning Network using RGB technology.

This year, in April 2023, the LNP/BP Association announced the release of RGB v 0.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 culmination of a long-term cross-industry collaboration and more than four years of extensive development work between these Bitcoin developers, contributors, and related companies. (RGB v 0.10 can be downloaded and installed at , which also contains a number of user and developer guides. RGB source code can be found at .)

2. Understand RGB:

1. Background

For many years, some projects and teams have been researching the protocol for issuing tokens on Bitcoin and trying to break through to make it compatible with the Lightning Network, including OmniBOLT, Taproot, and RGB.

The well-known protocols for issuing tokens on Bitcoin, such as OmniLayer, work by inserting metadata into Bitcoin transactions to "color" 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 coins. In the Omni protocol, USDT exists in the form of Tether tokens, which are represented by specific transaction types using the Omni protocol in Bitcoin transactions. Specifically, when a user initiates a USDT transaction on the Omni protocol, they add OmniLayer's special data field to the Bitcoin transaction to indicate that the transaction involves the transfer of USDT tokens. This approach enables Bitcoin transactions to represent the transfer of USDT tokens, and USDT holders can use Bitcoin addresses to receive, send, and store USDT tokens.

Such a signaling mechanism is usually implemented with the OP_RETURN opcode, the output with this opcode will be ignored by ordinary Bitcoin nodes, but can be interpreted by nodes that are aware of these token protocols, and these nodes will implement the code. The verification rules of the currency protocol.

Although this design is very efficient, it also has certain limitations:

1. The amount of information related to token transfer is limited to the number of bytes that OP_RETURN output can hold, generally 80 bytes, this space is enough for ordinary transaction data encoding, but more complex The application scenario is difficult to be satisfied.

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 output. The entire process will consume more resources due to the increase in the volume of the Bitcoin blockchain.

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

2. RGB solution: off-chain transfer

With the purpose of optimizing this design, the RGB protocol proposes a more scalable, more private, and more future-proof solution, the cornerstone of which is the client-side validation proposed by Peter Todd in 2016. The concept of single-use-seals.

The core idea of the RGB protocol is to only call the Bitcoin blockchain when necessary, which is to use the proof of work and the decentralization of the network to achieve double spending protection and anti-censorship. All verification of token transfers is removed from the global consensus layer, placed off-chain, and only verified by the client of the party receiving the payment.

working principle:

In one of RGB's contracts, the genesis tokens belong to a Bitcoin UTXO (whether existing or temporarily created), and in order to transfer tokens, you need to spend this UTXO. When spending this UTXO, the Bitcoin transaction must add an additional output, which contains a commitment to a message. The content of this message is the payment information of RGB, which defines the input, which UTXO these tokens will be sent to , asset id, quantity, spent transaction and other data that need to be attached.

If you have a token that is attributed to output #1 of Bitcoin transaction A, to transfer those tokens you need to create an RGB transaction and a Bitcoin transaction that spends the #1 output of transaction A, and the bitcoin Coin transactions commit to RGB transactions. As you can see, the RGB transaction is transferring tokens from output #1 of Bitcoin transaction A to output #2 of Bitcoin transaction C (this transaction is not shown in the diagram), not to Bitcoin transaction B . In most cases, we can expect the #0 output of transaction B to be the change address, in order to send the remaining funds back to the original owner after subtracting the miner's fee; while the #1 output is to commit the RGB transaction , to avoid double spending.

Privacy Protection:

In order to transfer RGB tokens attributed to a Bitcoin transaction, a Bitcoin transaction needs to be initiated. However, the output of the RGB transfer does not need to be the same as the output of the Bitcoin transaction. Like our example above, the output of the RGB transaction (output #2 of Bitcoin transaction C) can have no relationship to the Bitcoin transaction (transaction B) that committed the RGB transaction. This means that RGB tokens can be "transferred" from one UTXO to another without leaving any trace in the Bitcoin transaction graph, which greatly improves privacy.

In this design, Bitcoin's UTXO acts as a one-time container for RGB assets. To transfer assets, you only need to open a new container and close the old container.

The specific payment information of RGB tokens is transmitted under the chain through a dedicated communication channel, from the payer to the receiver's client, and the latter will verify that it does not violate the rules of the RGB protocol. As a result, blockchain observers will not be able to obtain any information about RGB user activity.

Verification closed loop:

However, verifying the sent payment information is not enough to ensure that the sender actually owns the asset to send you, so in order to ensure the finality of the sent transaction, you must also receive all the tokens from the payer. The history of the transaction, from the current one all the way back to its original issuance. By verifying all 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 is also good for scalability, because you don't need to verify the entire history of this asset, only the parts that are relevant to you. Moreover, the design that the transaction will not be broadcast to the global ledger also improves privacy, because fewer people know the existence of your transaction.

Blinding secret value:

In order to further improve privacy, RGB also supports blinding of outputs, which means that when you send a payment request to the payer, you do not need to disclose the UTXO you use to receive tokens, you only need to ask the payer to Send the token to a hash value, which is generated by splicing a random blinded secret value with the target UTXO itself. In this way, the payer cannot know which UTXO the token will be sent to, so the exchange and other service providers cannot know whether the user is withdrawing to the UTXO that has been "blacklisted" by some regulators, and cannot know these tokens How the future is spent. Note that when tokens are spent, the blinded secret value must be disclosed to the recipient so that the latter can verify the portion of the transaction history associated with the Bitcoin transaction. This means that when using RGB, you have complete privacy in the moment, but future token holders will be able to see all UTXOs in the transfer history of their tokens. So, while you get perfect privacy when receiving and holding RGB tokens, the confidentiality of a user's past financial activity will degrade as tokens are transferred and eventually tends to be tied to our Bitcoin transaction history. Same privacy.

3. The main characteristics of RGB

Through the understanding of the above content, we can conclude that RGB has the following main characteristics:

1. High confidentiality, security and scalability

2. There is no congestion in the Bitcoin time chain, because transactions only retain homomorphic commitments that require additional storage

3. It can be upgraded in the future without hard fork

4. Higher censorship resistance than Bitcoin: Miners cannot see the asset flow in the transaction

5. There is no concept of block and chain

It is worth noting that when we refer to the blockchain (Blockchain), the two concepts of block (Block) and chain (Chain) are generally involved, but there is no concept of block and chain in RGB, because it is A client verification technology, which is a non-block decentralized protocol.

3. Infinite Possibilities of RGB v 0.10

RGB v 0.10 release marks a major breakthrough, advancing RGB to the stage of systems that are ready for commercial use. It introduces the last consensus-breaking change intended to maintain full backwards compatibility with future RGB versions. In addition, it also unlocks the last batch of functions for implementing fully functional smart contracts that can be customized by contract developers at will.

Release of RGB v 0.10, which includes a consensus layer, standard library (for wallet/exchange integration, etc.), and command-line tools. The following table is the main difference between the old and new versions that we have compiled and summarized based on RGB official materials. Readers who want to know more detailed content can view RGB official documents and video introductions:

/blog/release-v0-10/

1. Interpretation of RGB v 0.10

In general, the v0.10 version of the RGB protocol solves many problems existing in the old version, including the limitation of smart contract development, the touch of the consensus layer, the limitation of the encoding format, the dependency problem of Rust Bitcoin, the lack of compatibility of WASM, the global State and context management issues, integration issues with Lightning Network, inflexible backup process, insufficient support for mobile wallets, etc. These improvements make the RGB protocol stronger, more flexible, and more secure, and lay a solid foundation for future development. Specifically, RGB v 0.10 release introduces support for the following features for RGB:

Global state in RGB contract

RGB introduces the concept of Global State, a brand new feature that is very important for building complex applications on RGB (such as synthetic assets, algorithmic stablecoins, etc.). Now, each RGB contract has a global state that can be accessed by virtual machines and clients (such as wallets, etc.).

Contract interface

The interface introduced in this release represents a standardized way to deliver various smart contracts through a well-defined API. Interfaces can be compared to contract ABI and ERC in the Ethereum world, however unlike Ethereum they neither require mandatory standardization (like ERC) nor are they distributed separately, but are always packaged with the contract. By using interfaces, wallets and other software can provide users with a semantically aware user interface for working with contracts - contract developers can also add more interfaces to their existing contracts over time without having to update immutable contracts itself.

Basic composition of RGB smart contract: RGB smart contract consists of three parts: Genesis (creation), State (state) and Transitions (transition). 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 v 0.10 introduces a new smart contract model, which is more flexible and powerful, and can support 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 for representation and introspection of RGB contract state. It allows compile-time size guarantees for 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 strictly typed, which allows formal proofs of binary compatibility between releases.

In other words, this new encoding format will make the use of RGB easier and safer, and will also enable asset issuers and contract developers to use additional metadata to sign their assets or contracts, which will Helps verify the identity of an asset or contract.

Writing Contracts in Rust

RGB smart contracts can be written and compiled using Rust. Thanks to strict typing, it is now also possible to compile Rust data types directly into RGB contracts.

State introspection

A contract can introspect its own state in the verification code used by the virtual machine, which opens up the possibility of writing complex forms of contracts that interact with Bitcoin transactions, DLC, and other complex data.

URL-BASED INVOICE FORMAT

Previously, RGB used Bech 32 m encoded invoices, which were very long, not easy 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 to preconfigured software.

WASM support

The RGB standard library can run without I/O and file system access, that is, it can run in a web page or browser plug-in.

Tapret Descriptors and Custom Derivations

RGB uses Taproot-based OP_RETURN promises (tapret for short), which need to be supported at the descriptor level so that wallets can treat transactions with adjusted outputs as transactions belonging to the wallet descriptor. The new version also introduces a custom derived index that prevents non-RGB wallets from accidentally consuming outputs with RGB assets (and thus corrupting assets).

Simplified dependencies

The RGB consensus layer now uses fewer dependencies, improving API stability. LNP/BP dropped the dependency on custom bulletproofs implementation from the Grin project.

Simplified Integration

Many operations that previously required multiple API calls and encoding complex data structures across languages can now be accomplished with a single API call. The RGB contract state is represented as a JSON object, which can be serialized between different languages without cumbersome operations.

Simplified User Experience

Previously with RGB, a wallet or user had to run an RGB node and interface via RPC (or cli tools) - and use many other libraries and command line tools to do most of the things like PSBT. In the new version, this complex stack is replaced by a single API library and rgb command line tool.

2. What are the major breakthroughs in RGB v 0.10?

As mentioned in the previous article, we believe that the main reason why RGB has not received widespread attention and application after several years of development. And after the study of RGB v 0.10 version, we have reason to believe that this phenomenon is about to change, and even the change is happening.

**1. In the previous version, why couldn’t independent developers develop complex smart contracts? **

In versions prior to RGB v 0.10, independent developers faced some challenges when developing complex smart contracts. This is mainly due to the following reasons:

1. Instability of the protocol: In the early version, the RGB protocol may undergo some major changes, which may cause the smart contracts that have been developed to fail to run on the new version of the protocol. This instability may hinder developers from complex smart contract development.

2. Lack of tools and resources: In early versions, there may be a lack of sufficient tools and resources to help developers with complex smart contract development. This includes lack of detailed documentation, tutorials or development tools etc.

3. Complexity of the protocol: The design and implementation of the RGB protocol can be quite complex, which can pose a challenge to independent developers. For example, the RGB protocol uses a novel verification mechanism called "client-side validation", which may require developers to have in-depth understanding and expertise for complex smart contract development.

However, these issues are being addressed with the development of the RGB protocol. For example, RGB v 0.10 version introduces a new type system called "strict types", which can help developers to more easily develop complex smart contracts. In addition, this release provides more tools and resources to help developers understand and use the RGB protocol.

2. It is possible to bring the function of fully supporting smart contracts to Lightning Network

Because RGB is built on Bitcoin, it is theoretically possible to transfer RGB assets using the Lightning Network. But in previous versions, RGB was not available in any existing Lightning nodes due to architectural limitations. In 2021, RGB developed its own architecture called LNP Node, written in Rust. It itself does not depend on Bitcoin Core, if users want to use RGB with Taproot in Lightning Network, they need to wait for Rust-bitcoin to complete support for Taproot.

And now, with the release of RGB v 0.10, the LNP/BP Association has announced the focus of the future, which is to complete the support for Lightning Network in the next few months, so that RGB assets can be transferred through Lightning Network.

If RGB is compatible and supported by Lightning Network, the liquidity and usability of RGB assets can be improved. Through the Lightning Network, users can quickly and cheaply transfer RGB assets without waiting for confirmation from the Bitcoin mainnet. This is very useful for users who need to trade RGB assets frequently.

More importantly, RGB may bring full support for smart contracts to the Lightning Network.

The Lightning Network has incredible speed, extremely low fees, and exceptional security. However, because Bitcoin itself does not support complex smart contracts, the Lightning Network is limited in terms of smart contracts.

RGB is able to support complex smart contract functionality because of its deliberate design, created specifically for implementing smart contracts on the Lightning Network. First, RGB employs Turing's 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 calculation logic and data operations, thus realizing various types of smart contracts.

RGB has fully considered 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 unbeatable combination may not only make the Lightning Network a shining star, but it may also eclipse other blockchains. As more and more funds and developers pour into the development of Bitcoin Lightning Network and RGB, it is expected that the ecosystem of Bitcoin and Lightning Network will reach a new height.

4. Comparison of RGB and other schemes

1. Token protocol based on altcoins

Most altcoin-based token protocols (such as ERC-20) provide smart contracts with a global unowned state (global unowned state), which makes it easy to deploy decentralized exchanges and other financial applications, but they Difficult to scale, no privacy, and inherit all the disadvantages of these altcoins, such as high cost of running nodes, lower decentralization and censorship resistance.

2. Liquid assets

Liquid is a Bitcoin consortium sidechain that offers some interesting features such as native asset support and confidential transactions (which can hide the ID of the asset being transferred and the amount paid). However, the federation model also suffers from low decentralization and weak censorship resistance.

3、All BOLT

OmniBOLT is a Lightning Network-compatible version of OmniLayer. OmniLayer has been briefly introduced in the previous article (interested readers can also read "DeFi Research on Bitcoin Lightning Network", here is a more detailed introduction).

The trade-off of OmniBOLT is very similar to that of RGB. The difference is that the design goals of the two protocols are different. Compared with RGB, OmniBOLT is relatively weak in terms of privacy because, like Bitcoin, token-related data is stored on the chain. However, OmniBOLT has a unique advantage in the stable currency payment business and has passed the test of time. Mainnet has been launched in June this year, and has realized the function of sending, receiving and transferring USDT through the Lightning Network.

4、Taproot (Taro)

At the Bitcoin 2022 Miami conference, Taro was released. Behind Taro is the Lightning Labs team, and the goal of the protocol is to bring assets onto the Lightning Network. According to the technical specifications that have been released, the entire design is very similar to RGB, and the characteristics and trade-offs are basically the same.

The main differences between RGB and Taro seem to be:

1. RGB is earlier and has published codes that can be audited, but lacks funds and operators.

2. Taro is currently only a specification, but on the other hand, behind Taro is Lightning Labs. The team raised $70 million in April last year and launched Taproot Assets v 0.2 (formerly known as Taro) in May this year. net.

If Taro and RGB eventually become interoperable, it's too early to tell whether there are incentives for that interoperability to happen.

5. RGB Ecological Projects/Development Teams Worthy of Attention

1、Infinite

Official website:

Infinitas is one of the first projects to start building a Turing-complete smart contract track based on Bitcoin. As a Bitcoin application ecological network that combines the RGB protocol and the Lightning Network, it aims to achieve higher privacy protection, excellent throughput and Excellent low-latency transaction processing. As an innovative blockchain solution, Infinitas has consolidated the idea of RGB-based Bitcoin Turing-complete smart contracts since 2021, giving full play to Bitcoin's security and consensus mechanism, allowing more complex transactions to be created on the Bitcoin network. applications and smart contracts, hoping to bring users an excellent trading experience. The technical core of the project is led by a team of top-level blockchain scientists who first paid attention to the RGB protocol and performed translation-related work, who are the code builders at the bottom of Bitcoin. Infinitas will give priority to providing Online IDE, data browser, and access to mainstream wallets to allow developers and users to participate in the ecology, and truly support the implementation of large-scale commercial applications such as RWA and full-chain games.

Project Features:

Whole-network hash computing power protection: Inheriting the high security of the Bitcoin blockchain, it ensures that Infinitas assets are protected by the hash computing power of the entire network in the Bitcoin blockchain, enhancing the security of assets.

Higher level of privacy protection: A higher level of privacy protection for Infinitas assets has been achieved, and a trustless Bitcoin anchoring mechanism has been introduced to further enhance user privacy.

Adapter technology: Through Infinitas adapter technology, users can understand the complete status of Bitcoin and enhance the perception of asset status.

Enrich the global state: By improving and expanding RGB's global state (Global State), it provides access interfaces for virtual machines and clients (such as wallets, etc.). In particular, special enhancements have been made in the trust of smart contract addresses, which critically support the construction of complex applications in the RGB ecosystem. This move also enables different systems to understand each other and explain their respective states, further promoting the development of the entire ecosystem.

Optimizing the Lightning Network: Through improvements to the Lightning Network (such as light block technology, node auto-scaling technology, and offline autonomy), higher transaction throughput is achieved while maintaining low-latency transaction confirmation time.

Developer-friendliness: Using the Rust language and using the Schema layer as the development infrastructure allows ordinary people to participate in the development.

It is reported that Infinitas will have an incentive plan for its native economy, and will use the form of mining to produce in the market in the early stage to promote the long-term development of the ecology. As the industry's first project to create a Turing-complete Bitcoin application ecosystem, it may become a phenomenal tipping point for the application of Bitcoin assets and a major leap in promoting the large-scale adoption of Crypto. At present, the testnet is not online yet, so please stay tuned.

2、COSMINMART

COSMINMART is based on Lightning Network, compatible with RGB and other protocols, and supports a new Bitcoin application ecology of smart contracts.

COSM Wallet: The core product of COSMINMART has wide applicability in the entire Bitcoin ecological network. It now supports Bitcoin mainnet and Lightning Network transfers, RGB protocol asset transfers and other functions, and will gradually be compatible with Stacks, Rootstock and other ecosystems.

COSM Market: It is one of the earlier platforms to support the aggregation and trading of Bitcoin derivative assets, and will gradually expand the scope of support to facilitate the trading of various Bitcoin derivative assets.

COSM Lanuchpad: It aims to screen bitcoin ecological projects with high-quality potential, and is committed to the sustainable development of bitcoin ecology.

COSMINMART takes the lead in defining the concept of Web 4, actively promotes the formulation of new RGB protocol standards, issues Lightning Network stable coins, combines Nostr and other protocols and Lightning Network trading advantages, and deeply integrates traditional APPs with Lightning Network, hoping to lead the development of Lightning-Application (Lightning-Application) A new era.

It is reported that COSMINMART plans to launch a public beta product at the end of this year, so keep an eye on it.

3、Pandora Prime Inc

Pandora Prime is a Swiss company based in the Verify Valley (Canton Neuchâtel) and a founding member of LNP/BP.

Pandora Prime is dedicated to pioneering Bitcoin Finance using a combination of RGB smart contracts and the Lightning Network. They start with programmable assets (RGBTC and CHFN) on Bitcoin that can scale to VISA/MasterCard levels in terms of transaction throughput via the Lightning Network, and also provide convenient facilities to exchange these assets without cumbersome KYC The program enables transactions of up to CHF 1,000 (in compliance with Swiss law). Currently, their products include MyCitadel (wallet), RGB Explorer (browser), and Pandora Network, among others.

MyCitadel

MyCitadel is a brand of Pandora Prime, MyCitadel is the first GUI wallet to support RGB, created in 2021 by RGB developers. It offers cross-platform desktop wallet and iOS/iPad wallet. Mobile wallets can handle fungible RGB assets.

RGB Explorer

RGB Explorer is the first browser developed by Pandora Prime to provide RGB asset registry and smart contracts. Currently supports RGB 20, RGB 21, RGB 25, and the assets that can be displayed are LNPBP, RGBTC, dCHF and RGBEX.

4、DIBA （DIGIT ALBITCOIN ART）

DIBA is dedicated to empowering the community by helping people understand, own and use non-custodial digital assets built on top of Bitcoin. And hope to shape digital art and asset economy with the principles of decentralization and inclusive empowerment.

DIBA is the first marketplace (as DIBA calls it) to trade Bitcoin NFTs using the RGB smart contract protocol and the Lightning Network. At present, DIBA BETA is running on the Bitcoin test network, and it will be launched on the Bitcoin main network soon, so you can stay tuned.

Bitmask

Created by DIBA, the wallet is the first NFT wallet in the RGB ecosystem, which can run in a web browser and interact with RGB contracts like MetaMask on Ethereum.

5、IRIS Wallet

IRIS Waller, the first Android wallet developed by the Bitfinex team, is dedicated to RGB integration and RGB related tools. Support for fungible and non-fungible assets. Iris Wallet supports RGB asset operations from issuance to spending and receiving, wrapping all functionality in a familiar wallet application and abstracting away as many technical details as possible. This is currently an experimental application and is only recommended for small amounts of Bitcoin and low-value assets.

6、Bitswap-BiFi

At present, the RGB ecosystem is actively exploring DEX solutions to solve the liquidity problem of RGB assets. In Bitswap's demo and proof of concept, it shows how to introduce "SWAPS" into DEX, but there is no AMM or LP for the time being. It is still in the verification stage, it is very early, and it is also worthy of attention.

6. Review and Prospect

The RGB protocol has gone through nearly 6 years of evolution from its initial conception to the present. While the RGB protocol has yet to gain widespread traction and adoption today, history tells us that people often overestimate the rapid adoption of new ideas, while underestimating the potential disruptive impact of these ideas when they eventually become widely accepted and speed. In fact, with the release of RGB protocol v0.10, we are standing at a new starting point, witnessing a future as limitless as Bitcoin.

The new version of the RGB protocol introduces a series of important updates. These updates enable 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 is not yet fully compatible with the Lightning Network, we firmly believe that in the coming months, the LNP/BP association and related development teams are expected to make more significant progress. We look forward to the perfect integration of the RGB protocol and the Lightning Network, which will be another important milestone for the RGB protocol and Bitcoin.

These new features and improvements enabled by the RGB protocol, especially full compatibility with the Lightning Network, light a bright light for the future of Bitcoin. These changes have opened the door to uncharted territory, allowing us to see the infinite potential of Bitcoin through it. In this uncharted territory, Bitcoin is no longer just a simple means of payment, but a powerful platform capable of carrying complex applications. The RGB protocol has become the cornerstone of this platform, which may lead us to a new Crypto world.

Attachment: References: