Progress pill
Programming on RGB

RGB on the Lightning Network

RGB programming

RGB on the Lightning Network

  • Channel creation and funding
  • Channel update
  • HTLC management
  • RGB code map
In this chapter, I propose to examine how RGB can be used within the Lightning Network, to integrate and move RGB assets (tokens, NFTs, etc.) via off-chain payment channels.
The basic idea is that the RGB state transition (State Transition) can be committed to a Bitcoin transaction which, in turn, can remain off-chain until the Lightning channel is closed. So, each time the channel is updated, a new RGB state transition can be incorporated into the new committing transaction, which then invalidates the old transition. In this way, Lightning channels can be used to transfer RGB assets, and can be routed in the same way as conventional Lightning payments.

Channel creation and funding

To create a Lightning channel that carries RGB assets, we need two elements:
  • Bitcoin funding to create the channel's 2/2 multisig (the basic UTXO for the channel);
  • RGB funding, which sends assets to the same multisig.
In Bitcoin terms, the funding transaction must exist to define the reference UTXO, even if it only contains a small amount of sats (it's just a matter of each output in future commitment transactions remaining above the dust limit all the same). For example, Alice may decide to provide 10k sats and 500 USDT (issued as an RGB asset). On the funding transaction, we add a commitment (Opret or Tapret) which anchors the RGB state transition.
Once the funding transaction has been prepared (but not yet broadcast), commitment transactions are created so that either party can close the channel unilaterally at any time. These transactions resemble Lightning's classic commitment transactions, except that we add an additional output containing the RGB anchor (OP_RETURN or Taproot) linked to the new state transition.
The RGB state transition then moves the assets from the 2/2 multisig of the funding to the outputs of the commitment transaction. The advantage of this process is that the security of the RGB state exactly matches Lightning's punitive mechanics: if Bob broadcasts an old channel state, Alice can punish him and spend the output, in order to recover both the sats and the RGB tokens. The incentive is therefore even stronger than in a Lightning channel without RGB assets, since an attacker can lose not only sats, but also the channel's RGB assets.
A commitment transaction signed by Alice and sent to Bob would therefore look like this:
And the accompanying commitment transaction, signed by Bob and sent to Alice, will look like this:

Channel update

When a payment occurs between two channel participants (or they wish to change the asset allocation), they create a new pair of commitment transactions. The amount in sats on each output may or may not remain unchanged, depending on the implementation, as its main role is to enable the construction of valid UTXOs. On the other hand, the OP_RETURN (or Taproot) output must be modified to contain the new RGB anchor, representing the new distribution of assets in the channel.
For example, if Alice transfers 30 USDT to Bob in the channel, the new state transition will reflect a balance of 400 USDT for Alice and 100 USDT for Bob. The commit transaction is added to (or modified by) the OP_RETURN/Taproot anchor to include this transition. Note that, from RGB's point of view, the input to the transition remains the initial multisig (where on-chain assets are actually allocated until the channel closes). Only the RGB outputs (allocations) change, depending on the redistribution decided upon.
The commitment transaction signed by Alice, ready to be distributed by Bob:
The commitment transaction signed by Bob, ready to be distributed by Alice:

HTLC management

In reality, the Lightning Network enables payments to be routed via multiple channels, using HTLCs (Hashed Time-Locked Contracts). It's the same with RGB: for every payment in transit through the channel, an HTLC output is added to the committing transaction, and an RGB allocation linked to this HTLC. Thus, whoever spends the HTLC output (thanks to the secret or after expiry of the timelock) recovers both the sats and the associated RGB assets. On the other hand, you obviously need to have enough cash on the road in terms of both sats and RGB assets.
The operation of RGB on Lightning must therefore be considered in parallel with that of the Lightning Network itself. If you'd like to delve deeper into this subject, I highly recommend you take a look at this other comprehensive training course:
Lightning Network Theory
Lightning Network Theory
Lightning Network Theory
Intermediate
4.8(152)

Discover the Lightning Network from a technical perspective

4.8(152)
Lightning Network Theory
Lightning Network Theory

Discover the Lightning Network from a technical perspective

Fanis MichalakisFanis Michalakis
Intermediate
6 hours
4.8(152)

RGB code map

Finally, before moving on to the next section, I'd like to give you an overview of the code used in RGB. The protocol is based on a set of Rust libraries and open source specifications. Here's an overview of the main repositories and crates:

Client-side Validation

Management of off-chain validation and Single-use Seals logic.

Deterministic Bitcoin Commitments (DBC)

Management of deterministic anchoring in Bitcoin transactions (Tapret, OP_RETURN, etc.).

Multi Protocol Commitment (MPC)

Multiple engagement combinations and integration with different protocols.

Strict Types & Strict Encoding

The strict typing system and deterministic serialization used for client-side validation.

RGB Core

The core of the protocol, which encompasses the main logic of RGB validation.

RGB Standard Library & Wallet

Standard implementations, stash and wallet management.

RGB CLI

The rgb CLI and crate wallet, for command-line manipulation of contracts.

RGB Schema

Contains examples of schemas (NIA, UDA, etc.) and their implementations.

ALuVM

Registry-based virtual machine used to run validation scripts.

Bitcoin Protocol - BP

Add-ons to support the Bitcoin protocol (transactions, bypasses, etc.).

Ubiquitous Deterministic Computing - UBIDECO

Ecosystem linked to open-source deterministic developments.
Quiz
Quiz1/5
What is the main aim of integrating RGB into the Lightning Network?