RGB & Lightning Network —
native asset channels,
no bridges required.
When an RGB state transition is committed into a Bitcoin transaction, it doesn’t need to be settled on-chain immediately — it can derive its security from being part of a Lightning Network payment channel. This is the foundation of RGB Lightning Network integration.
RGB Lightning channels work like regular Lightning channels — but with an additional RGB state transition committed inside each channel update. Assets move at Lightning speed. Bitcoin provides the security. No bridges, no custodians.
Lightning channels that carry
RGB assets natively.
◎ The content of this page is based on the official RGB protocol documentation at docs.rgb.info →
RGB state transitions are committed into Bitcoin transactions — but those transactions don’t need to be broadcast to the blockchain immediately. They can instead live inside a Lightning Network payment channel, deriving their security from the channel’s commitment transaction structure.
Every time a Lightning channel is updated, a new RGB state transition is committed inside the new channel update transaction, invalidating the previous one. The result: Lightning channels that move RGB assets, with payments routable across channels exactly like regular Lightning payments.
Two-part funding:
bitcoin and RGB assets.
Opening an RGB Lightning channel requires a funding transaction with two components, as described in the RGB documentation.
Bitcoin funding — creating the multisig
A standard bitcoin funding transaction creates the multisig UTXO that anchors the channel. The bitcoin amount doesn’t need to be economically significant — it only needs to be sufficient to keep all commitment transaction outputs above the dust limit.
Same as standard Lightning channel
RGB asset funding — allocating assets to the multisig UTXO
An RGB state transition sends the assets to the multisig UTXO created by the bitcoin funding. From this point, the assets are locked in the channel and their movements are tracked by RGB state transitions embedded in each channel commitment transaction.
RGB-specific: assets allocated via state transition
Example: Alice opens a channel with Bob — 10,000 satoshis + 500 USDT
500 USDT
10,000 sats
channel open
Multisig UTXO
Bitcoin + RGB assets locked
RGB commitment in OP_RETURN
or Taproot output
channel open
0 USDT
0 sats
Each payment updates
the RGB state transition.
When a payment occurs and the channel state needs to be updated, a new pair of commitment transactions is created. The bitcoin amounts in the outputs may or may not change — their primary role is to create new UTXOs, not to move economic value in bitcoin.
The key change is in the OP_RETURN or Taproot output: it now contains an RGB anchor to a new RGB state transition, which updates the asset balances to reflect the payment. The previous state transition is invalidated.
Alice sends 100 USDT to Bob
A new pair of commitment transactions is created. The RGB state transition moves assets from the funding multisig UTXO — which remains the RGB input throughout the channel’s lifetime — towards the new commitment transaction outputs, reflecting the updated balances: 400 USDT to Alice, 100 USDT to Bob.
RGB input always: original funding multisig
Multi-hop payments work
exactly like standard Lightning.
Real Lightning Network payments route through multiple nodes using Hash Time-Locked Contracts (HTLCs). RGB channels support this natively — each routed payment adds a dedicated HTLC output to the commitment transaction, with a corresponding RGB allocation in the state transition.
How RGB HTLCs work — from docs.rgb.info
For each payment routed through a channel, a dedicated HTLC output is added to the Lightning commitment transaction. The HTLC output needs a bitcoin amount above the dust limit — but it can remain economically insignificant. A new RGB allocation is added to the state transition, sending the assets involved in the payment to the HTLC output. Whoever spends the HTLC output — either via a secret or timelock expiration — receives both the satoshis and all RGB assets assigned to it.
This means every RGB payment on Lightning also transfers some satoshis — enough to keep the HTLC output above the dust limit in case of a force-close. The satoshi amount can be economically insignificant.
What RGB Lightning channels
give you.
Instant settlement
RGB asset transfers settle in milliseconds over Lightning — the same speed as any standard Lightning payment, with identical security from Bitcoin’s proof-of-work.
Near-zero fees
Lightning routing fees apply — fractions of a cent regardless of amount. No base-layer transaction cost per transfer. No gas, no fee market.
No bridges or custodians
RGB assets never leave Bitcoin’s security model. No lock-up contracts, no third-party operators, no additional trust assumptions beyond Bitcoin itself.
Full routing compatibility
RGB payments route across channels like regular Lightning payments, using the same HTLC mechanism. The existing Lightning Network infrastructure is compatible.
Both commitment schemes
RGB supports both OP_RETURN and Taproot output commitment schemes in Lightning channels — compatible with current and future Lightning implementations.
Unilateral close protection
If a counterparty becomes unresponsive, both satoshis and RGB assets can be recovered unilaterally after the timelock expires — no trust required.
Bitcoin-level security,
end to end.
RGB Lightning channels inherit all the security properties of standard Lightning channels — with one important addition: the economic punishment for broadcasting an old state extends to RGB assets, not just satoshis.
What happens if a party tries to cheat
If Alice broadcasts an old channel state to reclaim assets she already sent, Bob can use Alice’s revocation secret to spend the output — claiming both the satoshis and all RGB assets that were locked in the channel. The punishment is not limited to the bitcoin amount, which may be economically insignificant.
Honest close
Last state broadcast
Both parties receive their correct RGB asset balances after the timelock expires. No dispute possible.
Fraudulent close
Old state broadcast
The counterparty uses the revocation secret to claim all satoshis and all RGB assets in the channel. Full punishment.
Unresponsive counterparty
Last state broadcast
Both parties receive their correct RGB asset balances after the timelock expires. No dispute possible.
Honest close
Last state broadcast
Both parties receive their correct RGB asset balances after the timelock expires. No dispute possible.
What to read
next.
Ready to build
on RGB Lightning?
Everything you need to start developing RGB asset channels.