Progress pill
Building on RGB

Bitfinex's work on RGB

RGB programming

Bitfinex's work on RGB

  • Background and objectives
  • The RGBlib library: simplifying the development of RGB applications
  • Iris Wallet: an example of an RGB wallet on Android
  • Proxy server and user experience
  • RGB integration on the Lightning Network
  • DEX potential and impact on Bitcoin
  • Conclusion and resources
In this chapter, based on a presentation by Frederico Tenga, we look at a set of tools and projects created by the Bitfinex team dedicated to RGB, with the aim of fostering the emergence of a rich and diverse ecosystem around this protocol. The team's initial aim is not to release a specific commercial product, but rather to provide software building blocks, contribute to the RGB protocol itself, and propose concrete implementation references such as a mobile wallet (Iris Wallet) or an RGB-compatible Lightning node.

Background and objectives

Since around 2022, the Bitfinex RGB team has been concentrating on developing the technology stack that enables RGB to be exploited and tested efficiently. Several contributions have been made:
  • Participation in source code and protocol specifications, including writing enhancement proposals, fixing bugs, etc;
  • Tools for developers to simplify the integration of RGB in their applications;
  • Design of a mobile wallet named Iris to experiment and illustrate best practices for using RGB;
  • Creation of a customized Lightning node, capable of managing channels with RGB assets;
  • Supporting other teams building solutions on RGB, to encourage diversity and a strong ecosystem.
This approach aims to cover the entire chain of needs: from the low-level library (RGBlib), enabling the implementation of a wallet, to the production aspect (a Lightning node, a wallet for Android, etc.).

The RGBlib library: simplifying the development of RGB applications

An important point in democratizing the creation of RGB wallets and applications is to make available an abstraction simple enough so that developers don't have to learn everything about the protocol's internal logic. This is precisely the aim of RGBlib, written in Rust.
RGBlib acts as a bridge between the highly flexible (but sometimes complex) requirements of RGB that we have been able to study in previous chapters, and the concrete needs of an application developer. In other words, a wallet (or service) wishing to manage token transfers, asset issuance, verification, etc., can rely on RGBlib without knowing every cryptographic detail or every customizable RGB parameter.
The bookshop offers:
  • Turnkey functions for issuing (issuance) assets (fungible or not);
  • The ability to transfer (send/receive) assets by manipulating simple objects (addresses, amounts, UTXOs, etc.);
  • A mechanism for storing and loading the status information (consignments) required for Client-side Validation.
RGBlib therefore relies on complex notions specific to RGB (Client-side Validation, Tapret/Opret anchors), but encapsulates them so that the final application doesn't have to reprogram everything or make risky decisions. What's more, RGBlib is already binded in several languages (Kotlin and Python), opening the door to uses beyond a simple Rust universe.

Iris Wallet: an example of an RGB wallet on Android

To prove the effectiveness of RGBlib, the Bitfinex team has developed Iris Wallet, exclusively on Android at this stage. It's a mobile wallet that illustrates a user experience similar to that of an ordinary Bitcoin wallet: you can issue an asset, send it, receive it, and view its history, while remaining on a self-custody model.
Iris has a number of interesting features:
Using an Electrum server:
Like any wallet, Iris needs to know about transaction confirmations on the blockchain. Rather than embedding a complete node, Iris defaults to an Electrum server maintained by the Bitfinex team. Users can, however, configure their own server or another third-party service. In this way, Bitcoin transactions can be validated and information retrieved (indexing) in a modular way.
The RGB proxy server:
Unlike Bitcoin, RGB requires the exchange of off-chain metadata (consignments) between sender and receiver. To simplify this process, Iris offers a solution where communication takes place via a proxy server. The receiving wallet generates an invoice that mentions where the sender should send the client-side data. By default, the URL points to a proxy hosted by the Bitfinex team, but you can change this proxy (or host your own). The idea is to return to a familiar user experience where the recipient displays a QR code, and the sender scans this code for the transaction, without any complex additional manipulations.
Continuous backup:
In a strictly Bitcoin context, backing up your seed is generally sufficient (although these days we recommend backing up the seed and descriptors instead). With RGB, this isn't enough: you also need to keep the local history (the consignments) proving that you really do own an RGB asset. Each time you receive a receipt, the device stores new data, which is essential for subsequent spending. Iris automatically manages an encrypted backup in the user's Google Drive. This requires no special trust in Google, as the backup is encrypted, and more robust options (such as a personal server) are planned for the future to avoid any risk of censorship or deletion by a third-party operator.
Other features:
  • Create a faucet to quickly test or distribute tokens for experimentation or promotion;
  • A certification system (currently centralized) to distinguish a legitimate token from a fake one copying a famous ticker. In the future, this certification may become more decentralized (via DNS or other mechanisms).
All in all, Iris offers a user experience close to that of a classic Bitcoin wallet, masking the additional complexity (stash management, consignment history, etc.) thanks to RGBlib and the use of a proxy server.

Proxy server and user experience

The proxy server introduced above deserves to be detailed, as it is the key to a smooth user experience. Instead of the sender having to manually transmit the consignments to the recipient, the RGB transaction takes place in the background via:
  • The recipient generates an invoice (containing, among other things, the proxy address);
  • The sender sends (via an HTTP request) a transition project (the consignment) to the proxy;
  • The recipient retrieves this project, executes the client-side validation locally;
  • The recipient then publishes, via the proxy, the acceptance (or possibly rejection) of the state transition;
  • The sender can view the validation status and, if accepted, broadcast the Bitcoin transaction finalizing the transfer.
In this way, the wallet behaves almost like a normal wallet. The user is unaware of all the intermediate steps. Admittedly, the current proxy is neither encrypted nor authenticated (which leaves concerns about confidentiality and integrity), but these improvements are possible in later versions. The proxy concept remains extremely useful for recreating the "I send a QR code, you scan to pay" experience.

RGB integration on the Lightning Network

Another key focus of the Bitfinex team's work is to make the Lightning Network compatible with RGB assets. The aim is to enable Lightning channels in USDT (or any other token), and to benefit from the same advantages as bitcoin on Lightning (near-instantaneous transactions, routing, etc.). In concrete terms, this involves creating a Lightning node modified to:
  • Open a channel by placing not only satoshis, but also one or more RGB assets in the funding UTXO multisig;
  • Generate Lightning commitment transactions (Bitcoin side) accompanied by corresponding RGB state transitions. Each time the channel is updated, an RGB transition redefines the asset distribution in the Lightning outputs;
  • Enable unilateral closure, where the asset is retrieved in an exclusive UTXO, in compliance with Lightning Network rules (HTLC, timelock, punishment, etc.).
This solution, dubbed "RGB Lightning Node", uses LDK (Lightning Dev Kit) as a base, and adds the mechanisms needed to inject RGB tokens into the channels. Lightning commitments retain the classic structure (punishable outputs, timelock...), and in addition anchor an RGB state transition (via Opret or Tapret). For the user, this opens the way to Lightning channels in stablecoins or in any other asset emitted via RGB.

DEX potential and impact on Bitcoin

Once several assets are managed via Lightning, it becomes possible to imagine an atomic exchange on a single Lightning routing path, using the same logic of secrets and timelocks. For example, user A holds bitcoin on one Lightning channel, and user B holds USDT RGB on another Lightning channel. They can build a path linking their two channels and simultaneously exchange BTC for USDT, without the need for trust. This is nothing more than an atomic swap taking place in several hops, making outside participants almost oblivious to the fact that they are making a trade, not just a routing. This approach offers:
  • Very low latency, as everything remains off-chain on Lightning.
  • A superior privacy: nobody knows it's a trade, and not a normal routing;
  • Avoiding frontrunning, a recurring problem for on-chain DEX;
  • Reduced costs (you don't pay blockspace, just Lightning routing fees).
We can then imagine an ecosystem where Lightning nodes offer swap prices (by providing liquidity). Each node, if it wishes, can play the role of market maker, buying and selling various assets on Lightning. This prospect of a layer-2 DEX reinforces the idea that it is not necessary to fork or use third-party blockchains to obtain decentralized asset exchanges.
The impact on Bitcoin could be positive: Lightning's infrastructure (nodes, channels and services) would be more fully utilized thanks to the volumes generated by these stablecoins, derivatives and other tokens. Merchants interested in USDT payments on Lightning would mechanically discover BTC payments on Lightning (managed by the same stack). The maintenance and financing of the Lightning Network infrastructure could also benefit from the multiplication of these non-BTC flows, which would indirectly benefit Bitcoin users.

Conclusion and resources

The Bitfinex team dedicated to RGB illustrates, through its work, the diversity of what can be done on top of the protocol. On the one hand, there's RGBlib, a library that facilitates the design of wallets and applications. On the other, we have Iris Wallet, a practical demonstration on Android of a neat end-user interface. Finally, the integration of RGB with Lightning shows that stablecoin channels are possible, and opens the way to a potential decentralized DEX on Lightning.
This approach remains largely experimental and continues to evolve: the RGBlib library is being refined as we go along, Iris Wallet is receiving regular enhancements, and the dedicated Lightning node is not yet a mainstream Lightning client.
For those who wish to learn more or contribute, several resources are available, including:
In the next chapter, we'll take a closer look at how to launch an RGB Lightning node.
Quiz
Quiz1/5
What is RGBlib in the RGB ecosystem?