The BTC ecosystem is gaining momentum.
In 2024, multiple Bitcoin second-layer protocols have been or are being prepared for launch, and Lightning Network, BEVM, etc. have successively entered the public eye with different progress. Developers and miners are also looking forward to the BTC ecosystem market value to be on par with the Ethereum ecosystem as soon as possible, or even surpass it.
RGB is also a key part of the BTC ecosystem and has the most complete technical path; however, due to the extremely high development threshold, progress has been slow and it will still take at least one to two years to be implemented.
But we cannot deny that the vision of the RGB protocol to complete the operation of smart contracts based on the UTXO network is still grand and has broad room for imagination. The progress and future direction of RGB should always receive high attention from the industry.
In this article, Bailu Living Room recommends to readers to share the RGB ecological research conducted in August 2023 under the guidance of Professor Hong Shuning and co-authored by Waterdrop Capital and members of BiHelix, the Bitcoin ecological infrastructure, to fully understand the RGB protocol and protocol ecology.
The following is the original content of the research report:
In the world of crypto assets, Bitcoin is undoubtedly the most well-known. However, when people talk about Bitcoin, they often only focus on its price, market value and trading 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" published last year have made substantial breakthroughs in the first half of this year, such as:
Lightning Labs, launched the Taproot Assets v 0.2 (formerly known as Taro) testnet;
OmniBOLT has launched Mainnet and has realized the function of sending, receiving and transferring USDT through the Lightning Network;
RGB protocol, launched a more powerful, more flexible and more secure RGB v 0.10 version.
Speaking of the RGB protocol, people may be both familiar and unfamiliar with it. The familiarity comes from the fact that the concept of 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 received widespread attention and application, and people seem to be unable to find specific application cases of the RGB protocol.
After investigation and analysis, we believe that the main reason for this phenomenon is that in the early versions of the RGB protocol, its functions were relatively limited, and the ideas of the RGB protocol were highly original and unique, and the technology stack was quite grand. Developers needed to deeply understand the principles of Bitcoin and smart contracts before they could use it. However, with the continuous development and improvement of the RGB protocol, this situation is changing.
1. Introduction to RGB
1. What is RGB
RGB is a scalable and confidential Bitcoin and Lightning Network smart contract system developed by the LNP/BP Standard Association. It adopts the concepts of private and common ownership, is a Turing-complete, trustless distributed computing form, and does not require the introduction of a non-blockchain decentralized protocol for tokens.
RGB is designed to run scalable, robust, and private smart contracts on UTXO blockchains such as Bitcoin to realize all 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. It is a client state verification and smart contract system that runs on the second and third layers (off-chain) of the Bitcoin ecosystem.
Client-side validation:
Client-side verification 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 a decentralized protocol; instead, only the parties participating in a specific state transition need to verify it. With this approach, state transitions are not published to the global network, but are converted into a short cryptographic commitment by using cryptographic hash functions, etc., which needs to be part of some kind of "Proof-of-Publication" medium and have three main characteristics: proof of receipt, proof of non-publication, and proof of membership. The first client-side verification system was the OpenTimeStamps protocol, which was also proposed and developed by Peter Todd between 2014 and 2016.
Single-use-seals:
It can be compared to the one-time seals used to protect shipping containers in the real world. The one-time seal primitive is a unique object that can only encapsulate a message once, ensuring that the message can only be used once, and once used, it is permanently opened and cannot be closed again. In short, 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 about client-side validation and one-time sealing, and was implemented in the original MVP by BHB Network in 2017 with support from Poseidon Group.
In 2019, Maxim Orlovsk and Giacomo Zucco co-founded the LNP/BP Standards Association to promote RGB from concept to practical application. The association is supported by Fulgur Ventures, Bitfinex, Hojo Foundation, Pandora Prime and DIBA.
Dr. Maxim Orlovsky has served as the lead architect and chief contributor to the design and implementation of the current form of the RGB protocol since 2019. Since 2019, RGB has been reimagined and redesigned in terms of design and protocol peer review to become a general purpose computational 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 also started running on the Lightning Network, using the Rust reimplementation of the complete Lightning protocol (LNP Node) conducted by Dr. Maxim Orlovsky in the association.
In 2022, the LNP/BP Standards Association launched a new website (contractum.org) about the Contractum language (a new high-level language) for writing RGB smart contracts for Bitcoin and Lightning Network. Contractum is a functional declarative programming language designed for the development of smart contracts running on Bitcoin and 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 result of long-term cross-industry cooperation between these Bitcoin developers, contributors, and related companies, and more than four years of extensive development work.
2. Understanding RGB
1. Background
For many years, some projects and teams have been studying protocols for issuing tokens on Bitcoin and trying to make them compatible with the Lightning Network. Representatives include OmniBOLT, Taproot, and RGB.
Well-known protocols for issuing tokens on top of 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 considered a form of colored coins. In the Omni protocol, USDT exists in the form of Tether tokens, which are represented by using a specific transaction type of the Omni protocol in a Bitcoin transaction. Specifically, when a user initiates a USDT transaction on the Omni protocol, they add a special data field of OmniLayer to the Bitcoin transaction to indicate that the transaction involves the transfer of USDT tokens. This allows Bitcoin transactions to represent transfers of USDT tokens, and USDT holders can use Bitcoin addresses to receive, send, and store USDT tokens.
Such signaling is typically implemented using the OP_RETURN opcode, where outputs are ignored by normal Bitcoin nodes but can be interpreted by nodes that are aware of the token protocol, which enforce the token protocol’s validation rules.

Although this design is very 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 by the OP_RETURN output, which is generally 80 bytes. This space is sufficient for encoding ordinary transaction data, but it is difficult to meet more complex application scenarios.
2) The token protocol node needs to scan the entire blockchain and search for token transfers that may be related to the user in the OP_RETURN output. The whole process will be more resource-intensive due to the growth of the Bitcoin blockchain.
3) In terms of user privacy, all transaction data is visible to everyone.
2. RGB’s solution: off-chain transfer
With the goal of optimizing this design, the RGB protocol proposes a more scalable, more private, and more future-proof solution, based on the concepts of client-side validation and single-use-seals proposed by Peter Todd in 2016.
The core concept of the RGB protocol is to call the Bitcoin blockchain only when necessary, that is, to use proof of work and the decentralization of the network to achieve double-spending protection and censorship resistance. All verification of token transfers is removed from the global consensus layer and placed off-chain, and is only verified by the client of the party receiving the payment.
working principle:
In a contract of RGB, the genesis tokens belong to a Bitcoin UTXO (whether it already exists or is temporarily created), and in order to transfer the 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 RGB's payment information, which defines the input, which UTXO these tokens will be sent to, the asset's id, quantity, the transaction to spend, and other data that needs to be attached.

If you have tokens that belong to output#1of Bitcoin transaction A, to transfer them you need to create an RGB transaction and a Bitcoin transaction that spends output#1of transaction A and commits to the RGB transaction. As you can see, the RGB transaction is transferring tokens from output#1of Bitcoin transaction A to output#2of Bitcoin transaction C (which is not shown in the diagram), not to Bitcoin transaction B. In most cases, we can expect output#0of transaction B to be the change address, in order to send the remaining funds back to the original owner after deducting the miner's fee, and output#1is to commit to the RGB transaction to avoid double spending.
Privacy protection:
In order to transfer RGB tokens that belong 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. As in our example above, the output of the RGB transaction (output#2of Bitcoin transaction C) can have no connection to the Bitcoin transaction that committed the RGB transaction (transaction B). This means that RGB tokens can be "transferred" from one UTXO to another without leaving any trace in the Bitcoin transaction graph, 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 one.
The specific payment information of RGB tokens is transmitted off-chain through a dedicated communication channel, from the payer to the recipient's client, who 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 activities.
Verify the closed loop:
However, verifying the payment information sent is not enough to ensure that the sender really owns the assets to be sent to you. Therefore, in order to ensure the finality of the transaction sent, you must also receive the history of all transactions of these tokens from the payer, from the current one all the way back to the one that was originally issued. By verifying all transaction histories, you can ensure that these assets have not been inflated and 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 the asset, only the part that is relevant to you. In addition, the design that transactions are not broadcast to the global ledger also improves privacy, because fewer people know the existence of your transaction.
Blinded secret value:
To further improve privacy, RGB also supports blinding of outputs, which means that when you send a payment request to a payer, you do not need to disclose the UTXO you use to receive the token. 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 exchanges and other service providers cannot know whether users are withdrawing funds to UTXOs that are "blacklisted" by some regulatory agencies, nor how these tokens will be spent in the future. It should be noted that when the token is spent, the blinded secret value must be disclosed to the recipient so that the latter can verify the part of the transaction history related to the Bitcoin transaction. This means that when using RGB, you have complete privacy at the moment, but future token holders will be able to see all UTXOs in the transfer history of their tokens. Therefore, while you can get perfect privacy when receiving and holding RGB tokens, the confidentiality of a user's past financial activities will continue to degrade as tokens are transferred, ultimately tending to the same privacy as our Bitcoin transaction history.
3. Main characteristics of RGB
Through understanding 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. Future upgrades without hard forks
4. Higher censorship resistance than 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 blockchain, we generally involve the concepts of block and chain, but there is no concept of block and chain in RGB because it is a client verification technology and a non-block decentralized protocol.
III. The infinite possibilities of RGB v 0.10
RGB v 0.10 marks a major breakthrough, advancing RGB to the stage of a system that is ready for commercial use. It introduces the last consensus-breaking changes, designed to maintain full backward compatibility for future RGB versions. In addition, it also unlocks the last batch of features for fully functional smart contracts that can be customized by contract developers.
RGB v 0.10 was released, which includes the consensus layer, standard library (for wallet/exchange integration, etc.) and command line tools. The following table summarizes the main differences between the new and old versions based on the official RGB materials:

1. RGB v 0.10 Interpretation
In general, the v 0.10 version of the RGB protocol solves many problems with older versions, including limitations in smart contract development, the impact of the consensus layer, limitations in the encoding format, Rust Bitcoin dependency issues, lack of WASM compatibility, global state and context management issues, integration issues with the Lightning Network, inflexible backup processes, and insufficient support for mobile wallets. These improvements make the RGB protocol more powerful, flexible, and secure, and lay a solid foundation for future development. Specifically, the RGB v 0.10 version introduces the following functional support for RGB:
Global state in the 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
Interfaces, introduced in this release, represent a standardized way to communicate various smart contracts through well-defined APIs. Interfaces can be compared to contract ABIs and ERCs in the Ethereum world, however, unlike Ethereum, they neither require mandatory standardization (like ERCs) nor need to be 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 the immutable contracts themselves.
The basic structure of RGB smart contract: RGB smart contract consists of three parts: Genesis, State and Transitions. Genesis defines the basic properties and rules of the contract, State is the current state of the contract, and Transitions is the transition between states. RGB v 0.10 introduces a new smart contract model that is more flexible and powerful and can support a variety of 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 the representation and introspection of RGB contract states. It allows guarantees on the size of any data at compile time, simplifying the operation of RGB on low-end and limited memory devices such as hardware wallets. The entire RGB consensus layer is now compiled to strict types, which allows formal proof 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 sign their assets or contracts with additional metadata, which will help verify the identity of the asset or contract.
Writing contracts in Rust
RGB smart contracts can be written and compiled in Rust. Thanks to strict typing, it is now also possible to compile Rust data types directly into RGB contracts.
State introspection
Contracts can introspect their own state within the verification code used by the virtual machine, which opens the possibility of writing complex forms of contracts that interact with Bitcoin transactions, DLCs, and other complex data.
URL-based invoice format
Previously, RGB used Bech 32 m-encoded invoices, which were very long, difficult to read, and could not be opened automatically by most software. The new format is shorter, easier for users to verify, and can be opened automatically as a link by pre-configured 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 a Taproot-based OP_RETURN commitment (tapretated), which needs 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 to prevent non-RGB wallets from accidentally consuming outputs with RGB assets (thus destroying the assets).
Simplified dependencies
The RGB consensus layer now uses fewer dependencies, improving API stability. LNP/BP dropped the dependency on a 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. RGB contract states are represented as JSON objects that can be serialized between different languages without tedious manipulation.
Simplified user experience
Previously, to use RGB, wallets or users had to run an RGB node 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 rgb command line tool.
2. What are the major breakthroughs of RGB v 0.10?
In the previous article, we mentioned the main reasons why we think RGB has not received widespread attention and application after several years of development. After studying RGB v 0.10, we have reason to believe that this phenomenon is about to change, and even the change is happening.
1. In previous versions, why couldn’t independent developers develop complex smart contracts?
In versions prior to RGB v 0.10, independent developers faced some challenges in developing complex smart contracts. This was mainly due to the following reasons:
1) Protocol instability: In early versions, the RGB protocol may undergo some major changes, which may cause the already developed smart contracts to be unable to run on the new version of the protocol. This instability may hinder developers from developing complex smart contracts.
2) Lack of tools and resources: In early versions, there may be a lack of sufficient tools and resources to help developers develop complex smart contracts. This includes a lack of detailed documentation, tutorials, or development tools.
3) Protocol complexity: The design and implementation of the RGB protocol may be quite complex, which may 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 a deep understanding and expertise to carry out complex smart contract development.
However, as the RGB protocol develops, these issues are being addressed. For example, RGB v 0.10 introduces a new type system called "strict types", which can help developers develop complex smart contracts more easily. In addition, this version also provides more tools and resources to help developers understand and use the RGB protocol.
2. It is possible to bring full support for smart contracts to the Lightning Network
Because RGB is built on Bitcoin, it is theoretically possible to use the Lightning Network to transfer RGB assets. But in previous versions, RGB could not be used in any existing Lightning nodes due to architectural limitations. In 2021, RGB developed its own architecture, called LNP Node, and wrote it in Rust. It does not rely on Bitcoin Core itself, and if users want to use RGB with Taproot in the Lightning Network, they need to wait for Rust-bitcoin to complete support for Taproot.
Now, with the release of RGB v 0.10, the LNP/BP Association has announced its future priorities, which is to complete support for the Lightning Network in the coming months, allowing RGB assets to be transferred through the Lightning Network.
If RGB completes the compatibility and support of Lightning Network, it can improve the liquidity and availability of RGB assets. Through Lightning Network, users can transfer RGB assets quickly and cheaply 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 smart contract support to the Lightning Network.
The Lightning Network has amazing speed, extremely low fees, and excellent 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 functions because it has been carefully designed and created specifically for implementing smart contracts on the Lightning Network. First, RGB uses the Turing Complete Virtual Machine (AluVM), a powerful computing engine that allows complex smart contracts to run on the Lightning Network. AluVM enables RGB to handle complex computing logic and data operations, thereby implementing 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 unparalleled combination may not only make the Lightning Network a shining star, but may also eclipse other blockchains. As more funds and developers pour into the development of the Bitcoin Lightning Network and RGB, it is expected that the Bitcoin and Lightning Network ecosystems will reach new heights.
4. Comparison between RGB and other solutions
1. Token protocols based on altcoins
Most token protocols based on altcoins (such as ERC-20) provide smart contracts with global unowned state, which makes it easy to deploy decentralized exchanges and other financial applications, but they are difficult to scale, have no privacy, and inherit all the shortcomings of these altcoins, such as high cost of running nodes, lower decentralization and censorship resistance.
2. Liquid Assets
Liquid is a federated sidechain for Bitcoin that provides some interesting features, such as native asset support and confidential transactions (which can hide the ID of the asset being transferred and the amount of the payment). However, the federation model also has the same problems of 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" for a more detailed introduction).
The trade-offs of OmniBOLT are very similar to those of RGB. The difference is that the two protocols have different design goals. Compared with RGB, OmniBOLT is relatively weak in terms of privacy because, like Bitcoin, all token-related data is stored on the chain. However, OmniBOLT has a unique advantage in the stablecoin payment business and has been tested by time. In June this year, Mainnet was launched and realized the function of sending, receiving and transferring USDT through the Lightning Network.
4、Taproot (Taro)
Taro was released at the Bitcoin 2022 Miami conference. The Lightning Labs team is behind Taro, and the goal of the protocol is to bring assets to the Lightning Network. According to the technical specifications that have been released, 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 started earlier and had published auditable code, but it was short of funds and operators.
2) Taro is currently just a specification, but on the other hand, behind Taro is Lightning Labs. The team raised US$70 million in April last year and launched the Taproot Assets v 0.2 (formerly known as Taro) testnet in May this year.
If Taro and RGB are ultimately interoperable, it is not possible to tell whether the incentives exist to make that interoperability happen.
5. RGB Ecosystem Projects/Development Teams Worthy of Attention
1. Infinitas (the brand was upgraded to BiHelix on December 20)
Infinitas is one of the earliest projects to start building Turing-complete smart contracts 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 been consolidating the idea of Bitcoin Turing-complete smart contracts based on RGB since 2021, giving full play to Bitcoin's security and consensus mechanism, allowing more complex applications and smart contracts to be created on the Bitcoin network, hoping to bring users an excellent trading experience. The technical core of the project is led by a team of top blockchain scientists who are the builders of some of the underlying code of Bitcoin and the first to pay attention to the RGB protocol and conduct translation-related work. Infinitas will give priority to providing online IDE, data browsers, access to mainstream wallets, etc. 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 by the hash power of the entire network: Inheriting the high security of the Bitcoin blockchain, Infinitas assets are protected by the hash power of the entire network in the Bitcoin blockchain, thus enhancing the security of assets.
Higher level of privacy protection: A higher level of privacy protection for Infinitas assets is achieved, and a trustless Bitcoin anchoring mechanism is introduced to further enhance user privacy.
Adapter technology: Through Infinitas adapter technology, users can understand the complete status of Bitcoin and enhance their ability to perceive the status of assets.
Enriching the global state: By improving and expanding the global state of RGB, access interfaces are provided for virtual machines and clients (such as wallets, etc.). In particular, special reinforcement is made in the trust of smart contract addresses, which critically supports the construction of complex applications in the RGB ecosystem. This move also enables different systems to understand and explain each other's 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 automatic expansion technology, and offline autonomy), higher transaction throughput is achieved while maintaining low latency transaction confirmation time.
Developer-friendly: Using the Rust language and the Schema layer as the development infrastructure allows ordinary people to participate in the development.

It is reported that Infinitas will have its own native economic incentive plan, and will use mining to produce in the market in the early stage to promote the long-term development of the ecosystem. As the industry's first Turing-complete Bitcoin application ecosystem project, it may become a phenomenal detonation point for Bitcoin asset applications and a major leap in promoting the large-scale adoption of Crypto. The test network is not yet online, so stay tuned.
2、COSMINMART
COSMINMART is a new Bitcoin application ecosystem based on the Lightning Network, compatible with RGB and other protocols, and supporting smart contracts.
COSM Wallet: COSMINMART's core product, with wide applicability in the entire Bitcoin ecological network, currently 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 earliest platforms that supports Bitcoin derivative asset aggregation trading. It will gradually expand its support scope to facilitate various types of Bitcoin derivative asset transactions.
COSM Lanuchpad: Aims to screen Bitcoin ecological projects with high-quality potential and is committed to the sustainable development of the Bitcoin ecosystem.
COSMINMART took the lead in defining the concept of Web 4, actively promoted the formulation of the new RGB protocol standard, issued the Lightning Network stablecoin, combined with the Nostr and other protocols and the advantages of Lightning Network transactions, deeply integrated the traditional APP with the Lightning Network, and hoped to lead a new era of Lightning Application.
It is reported that COSMINMART plans to launch a public beta product at the end of this year, so stay tuned.
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 committed to pioneering Bitcoin Finance using a combination of RGB smart contracts and the Lightning Network. They start with programmable assets on Bitcoin (RGBTC and CHFN), which can be expanded to VISA/MasterCard levels in terms of transaction throughput through the Lightning Network, and also provide convenient facilities to exchange these assets, without cumbersome KYC procedures, for transactions under 1,000 Swiss francs (in compliance with Swiss law). Currently, their products include MyCitadel (wallet), RGB Explorer (browser), and Pandora Network.
MyCitadel
MyCitadel is a brand of Pandora Prime, MyCitadel is the first GUI wallet that supports RGB, created by RGB developers in 2021. It provides cross-platform desktop wallets and iOS/iPad wallets. The mobile wallet can handle fungible RGB assets.
RGB Explorer
RGB Explorer is the first browser developed by Pandora Prime that provides RGB asset registration and smart contracts. Currently, it supports RGB 20, RGB 21, and RGB 25, and can display four assets: LNPBP, RGBTC, dCHF, and RGBEX.
4、DIBA (DIGIT ALBITCOIN ART)
DIBA is committed to enhancing the development of the community by helping people understand, own and use non-custodial digital assets built on Bitcoin. It hopes to shape the digital art and asset economy with the principles of decentralization and inclusive empowerment.
DIBA is the first market to use the RGB smart contract protocol and the Lightning Network to trade Bitcoin NFTs (DIBA calls it). Currently, DIBA BETA is running on the Bitcoin testnet and will be launched on the Bitcoin mainnet soon, so stay tuned.
Bitmask
The wallet was created by DIBA and is the first NFT wallet in the RGB ecosystem. It runs in a web browser and interacts with RGB contracts similar to 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. It supports both fungible and non-fungible assets. Iris Wallet supports RGB asset operations from issuance to spending and receiving, wrapping all functions in a familiar wallet application and abstracting away as many technical details as possible. This is currently an experimental application and is recommended for only small amounts of Bitcoin and low-value assets.
6、Bitswap-BiFi
Currently, the RGB ecosystem is actively exploring DEX solutions to solve the liquidity problem of RGB assets. Bitswap's demonstration and proof of concept showed how to introduce "SWAPS" into DEX, but there is no AMM or LP for the time being. It is still in the verification stage, which is very early and also worth paying attention to.

VI. Review and Outlook
The RGB protocol has evolved over the past six years since 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 and underestimate the disruptive impact and speed that these ideas may cause when they are finally widely accepted. In fact, with the launch of the RGB protocol v 0.10, we are standing at a new starting point, witnessing a future with unlimited possibilities like Bitcoin.
The new version of the RGB protocol introduces a series of important updates, which enable the RGB protocol to not only issue and transfer multiple assets on the Bitcoin network and Lightning Network, but also have the ability to support more complex smart contracts. Although the RGB protocol is not yet fully compatible 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. We look forward to the perfect integration of the RGB protocol and the Lightning Network, which will become another important milestone for the RGB protocol and Bitcoin.
The new features and improvements brought by the RGB protocol, especially the full compatibility with the Lightning Network, have lit a bright light for the future of Bitcoin. These changes have opened the door to an unknown area, allowing us to see the unlimited potential of Bitcoin. In this unknown area, Bitcoin is no longer just a simple means of payment, but a powerful platform that can carry complex applications. The RGB protocol has become the cornerstone of building this platform, which may lead us to a brand new Crypto world.
