Clarify off-chain token transfer

[cryptoquick]

Presently, when a token is spent, its contract consignment data is passed to the payee off-chain (after getting their blinded UTXO), but there's still an on-chain anchor tx that needs to be mined on-chain in order to prevent double-spend (and to properly mark the payment as "accepted"). If that's a correct understanding, in order to scale this, are payment channels (that can always be settled between two parties) used to prevent double-spend in an entirely off-chain context?

[dr-orlovsky]

Presently, when a token is spent, its contract consignment data is passed to the payee off-chain (after getting their blinded UTXO), but there's still an on-chain anchor tx that needs to be mined on-chain in order to prevent double-spend (and to properly mark the payment as "accepted").

That is correct

in order to scale this, are payment channels (that can always be settled between two parties) used to prevent double-spend in an entirely off-chain context?

Not sure I understand your question; specifically, what do you mean by "entirely off-chain context"? Lightning network?

[cryptoquick]

I mean both LN and RGB; they both add off-chain functionality, just using on-chain transactions for settlement.

I just wanted to be clear on how RGB over LN works; are RGB assets locked up in payment channels, where HTLC PSBTs are exchanged between two nodes that can be used to settle the assets on-chain whenever necessary?

[dr-orlovsky]

Ok, I see. The RGB on LN works by both peers on the channel ends independently generating new commitment transaction + a set of HTLC transactions, each of which also commits to the anchored RGB data, which assign a new state to the outputs of these transactions.

[cryptoquick]

That makes sense! So, it's very similar to how LN works, just with additional RGB anchor data.