The problem solved by Alice sending BTC to Dan via USDT on the route is utilization of additional liquidity which will be present in LN only with RGB.

PPM fee still will be lower than onchain tx fee if liquidity is just not there and Alice can't pay Dan

Free option problem is always there in any atomic swap protocols; the way to mitigate it is just to set a proper CTV timeout and experience more failures.

Yes, it was an early demo during Lugano Plan B which was working only peer-to-peer through QR code or mesh network (i.e. when you are next to each other).

The new version will support remote invoicing.

Sorry it is not a nonsense but is an an already working system.

Yes, you if have RGB channels you need RGB-enabled LN nodes on both sides - there is RLN (RGB lightning node) and soon another one will be released (LNP Node). But outside channels are usual, so if Alice pays Dan in BTC through Bob and Carol, and Bob and Carol have direct RGB USDT channel, both Alice and Dan do not need a special LN node - any will work (but Bob and Carol need one). The forward-backward conversion fee will be seen as a fee for the routing from the point of view of Alice.

At https://pandoraprime.ch we plan to launch https://raywallet.app iOS wallet in August for internal testing and around September for public.

Right now the only liquidity present in Lightning network is BTC liquidity.

Yet stable coins (like USDT) has much more liquidity (most of BTC is on long-term holding and thus non-liquid, and would never touch LN). Once they come into lightning channels payments can be routed through channels with no BTC liquidity (but with USDT etc), converting on-the-fly; so BTC payment may pass through such channels in a transparent way.

Yes, there is clearly a global state; first right in the contract you have its explicit, and you may distribute information about it with any data availability layer (without additional consensus), like Nostr (we also work on a dedicated DA called Storm)

Yes, there is a pure technical reason.

In client-side validation there is no P2P network like in blockchain; you validate only part of the global history and state directly related and interested to you. Thus, if somebody in that history uses something which was valid for him, and you have a newer software in which this have become invalid (like in soft-fork in bitcoin blockchain), you will decline these data, meaning that that part of the history will be lost forever after such a change.

Also, in bitcoin blockchain you can target update events using blockchain as a Time Machine; in client-side validation there is no full order of events and you can't say that "After time point X a thing becomes valid/invalid", so no means of coordinating updates.

Not just shitcoins. Also:

With Prime (client-side validation layer 1):

And yes, there is bitcoin trustless bridging to RGB and Prime - with Radiant and/or BitVM (whatever happens first).

The main reason of its not being used is the fact that it was not released for production (until today). Consensus in client-side validated systems (RGB belongs to them) is kind of ossified from the day one when you start using in production; it is much harder to change that than blockchain consensus. Thus, it took many years to build a system which has everything needed, including zk-STARK readiness.

I am quite sure we will see a boost in RGB adoption over the next months after the release.