As vincenzopalazzo correctly noted, every channel in the route must be RGB-aware — there is no way to forward RGB assets through a channel that does not support the protocol.
The reason is architectural. In RGB over Lightning, the asset is not carried “alongside” a normal satoshi payment: it is embedded inside the commitment transaction of each channel as an RGB state transition.
Since each hop in a multi-hop payment, the intermediate node must do two things:
- Add a new HTLC output to their commitment transaction (standard Lightning)
- Add a corresponding RGB allocation in the RGB state transition, assigning the asset amount to that HTLC output
As the official RGB v0.11.1 documentation states:
“For each payment that is being routed through the channels, a
dedicated HTLC output will be added to the lightning commitment
transaction. 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.”
A channel that doesn’t support RGB has no mechanism to create this state transition. In fact, it cannot allocate RGB assets to an HTLC output, so it cannot forward the asset.
In practice: RGB payments on Lightning require a dedicated path of RGB-capable channels, where every node in the route has implemented the RGB Lightning protocol. This is the same constraint that applies to any asset in a payment channel network: intermediate nodes must speak the same protocol as the asset being routed.
