<blockquote>
<p>Is it possible to forward the RGB assets through multiple channels that do not recognize any RGB assets?</p>
</blockquote>
<p>I am not 100% comfortable with the RGB protocol, so what I am saying is my understanding of it.</p>
<p>from the docs I read</p>
<blockquote>
<p>Above we just saw a simplification of payment channels that involve only two parties, but since in reality the lightning network is designed also to route payments towards more participants, all payments actually use HTLCs output. With RGB channels it works exactly the same way, for each payment that is being routed through the channels, a dedicated HTLC output will be added to the lightning commitment transaction.</p>
</blockquote>
<p>I guess that all the route should be an RGB channel because when I am making a payment I need to update the HTLC and the docs says that we should update also the OP_RETURN to make the RGB state transition.</p>
<blockquote>
<p>. Together with the new HTLC output,  a new allocation needs to be added to the RGB state transition, which will send the amount of assets involved in the payment towards the new HTLC output. Whoever manages to spend the HTLC output, either through knowledge of a secret or by waiting for a timelock expiration, will be able to move both the satoshis that were in the output and all the assets assigned to it.</p>
</blockquote>
<p>I do not know what will be changed with Taproot but I guess if the transaction is built in a different way, all the routes should support this feature because the HTLC is for a channel and not for a path.</p>
<p>In this case, I do not have a clear for a multipart update</p>

CC BY-SA 4.0
2023-08-13T10:33:07.487Z
2023-08-13T10:33:07.487Z
vincenzopalazzo
<p>RGB on lightning has happened recently. <a href="https://docs.rgb.info/lightning-network-compatibility" rel="nofollow noreferrer">This documentation</a> is said that payment channel can have HTLCs that contain RGB state transitions. That means payment for RGB assets can be delayed on LN when a payer makes a payment. Is it possible to forward the RGB assets through multiple channels that do not recognize any RGB assets?</p>

CC BY-SA 4.0
2023-03-25T17:27:12.143Z
Can you provide a link to the documentation you are referencing?
Poseidon
CC BY-SA 4.0
2023-03-26T08:47:26.187Z
@Poseidon Edited this question to have the reference.
ogw_yuya
<lightning-network>
How can I send a RGB token via Lightning Network?
ogw_yuya
# How can I send a RGB token via Lightning Network?

(Asked by: username_0 on 2023-03-25)

RGB on lightning has happened recently. [This documentation](https://docs.rgb.info/lightning-network-compatibility) is said that payment channel can have HTLCs that contain RGB state transitions. That means payment for RGB assets can be delayed on LN when a payer makes a payment. Is it possible to forward the RGB assets through multiple channels that do not recognize any RGB assets?

**Tags:** lightning-network

> **Comments:**
> **username_1**: Can you provide a link to the documentation you are referencing?  
> **username_0**: @username_1 Edited this question to have the reference.  

---

## 1 answers

### Answer by username_2 on 2023-08-13. Score: 1

> Is it possible to forward the RGB assets through multiple channels that do not recognize any RGB assets?

I am not 100% comfortable with the RGB protocol, so what I am saying is my understanding of it.

from the docs I read

> Above we just saw a simplification of payment channels that involve only two parties, but since in reality the lightning network is designed also to route payments towards more participants, all payments actually use HTLCs output. With RGB channels it works exactly the same way, for each payment that is being routed through the channels, a dedicated HTLC output will be added to the lightning commitment transaction.

I guess that all the route should be an RGB channel because when I am making a payment I need to update the HTLC and the docs says that we should update also the OP\_RETURN to make the RGB state transition.

> . Together with the new HTLC output, a new allocation needs to be added to the RGB state transition, which will send the amount of assets involved in the payment towards the new HTLC output. Whoever manages to spend the HTLC output, either through knowledge of a secret or by waiting for a timelock expiration, will be able to move both the satoshis that were in the output and all the assets assigned to it.

I do not know what will be changed with Taproot but I guess if the transaction is built in a different way, all the routes should support this feature because the HTLC is for a channel and not for a path.

In this case, I do not have a clear for a multipart update


---

