Lightning based atomic-swaps
It is possible to leverage the Lightning Network compatibility of RGB also to execute low fees and low latency atomic swap. For this to be possible, both parties need to have lightning channels with sufficient liquidity for both of the assets that are being exchanged, and it has to be possible to route payments between those channels.
The swap will leverage lightning’s HTLC based multi-hop payments to guarantee the atomicity of the exchange. The same hash of the same secret preimage will be used to construct all the HTLCs for the routing of the transfer of both assets. In this way, either the swap is completely successful, or no asset gets moved. So let’s assume Alice and Bob agree to swap 0.1 bitcoin for 3000 USDT, two nodes will create a circular payment that starts from Alice and goes back to Alice passing through Bob’s node somewhere along the routing path. The portion of the routing path from Alice to Bob will be denominated in bitcoin, while the second half from Bob back to Alice will be denominated in USDT. In this way both parties are receiving an asset on one channel, and sending the other on the second channel, but since it is all constructed as a single payment using the same secret for all the hops, there is atomicity between the bitcoin and the USDT parts, guaranteeing that trustlessness in the swap is preserved.
Executing the atomic swaps on top of the Lightning Network instead of doing it on-chain presents several advantages:
1– No need to pay on-chain fees if the Lighting channels are already established.
2– Fast settlement with no need to wait for on-chain confirmation and no risk of the counterparty double-spending their input.
Moreover, when compared to liquidity pool based DEXes, you also get the added benefit of no frontrunning (miners and blockchain observers cannot see the swap is happening), certainty over the execution price and better privacy.
Free american option problem
With RGB-based atomic swaps on Lightning the free american call option problem still remains, as there will always be one of the two parties that has the final trigger to execute the swaps and can decide on whether to do it or abort the whole operation. In the example above, once all the HTLC have been set up Alice can decide not to share the HTLC secret and let the timelock expire. The duration of the option is therefore equal to the length of the time-locks in the HTLCs.
In a decentralized setup the free option problem is unfortunately unavoidable, as the option is either held by one of the two counterparties or, as in the case of liquidity pool based DEXes, by the miner. The only realistic mitigation to the problem is to make sure that the option is held by the party with more reputation at stake (e.g. a professional liquidity provider) so that there is a disincentive in holding the option until the first time-lock expires (i.e. if you do it too often people stops trading with you).
Onchain Swaps
Atomic swaps are a powerful tool to exchange assets without intermediaries and without counterparty risk in a blockchain or across blockchains. Atomic swaps typically require the two parties to fund HTLC outputs, from which the assets will be redeemed using a secret if the swap is successful, or using a timelock if the swap fails. In RGB, it is possible to have atomic swap without the need for any scripting mechanism, and without having to perform two rounds of transactions, achieving both efficiency and privacy benefits.
In an RGB swap, the two parties will create together a Bitcoin transaction spending as inputs their respecting colored UTXO containing the RGB assets, and having as outputs the two change addresses where both parties can send back the bitcoins contained in their UTXO (minus the network fee) and an output containing the commitment to both RGB state transitions, one for Alice to send her assets to Bob, and the other for Bob to send his assets to Alice.
N.B. the output used for the RGB state transition commitment can either be a dedicated OP_RETURN output as in the example below, or a Taproot output also used for the bitcoin change of one of the two parties.
The atomicity of the exchange is guaranteed by the fact that both RGB state transitions are committed to same Bitcoin transaction, so either both of them get finalised or both of them fail. Compared to traditional atomic swaps, with RGB there is the advantage that much less on-chain space is used, and a blockchain observer cannot distinguish the atomic swap from a generic Bitcoin transaction.
The same scheme can work also for swaps between RGB asset and bitcoin, with the only difference that only one RGB state transition will be committed in the Bitcoin transaction, and one of the Bitcoin outputs will be dedicated to send bitcoin to the party who is acquiring bitcoin in the swap.
It is important to notice that in a real world environment there exists the risk of one of the two counterparties double-spending their input if they are no longer satisfied with the previously agreed conversion rate for the swap. One way to mitigate this issue is to have the two parties create a few RBF versions of the swap transaction with increasing fee rates, so that an input double-spending attempt can be responded to by broadcasting a higher fee paying version of the swap transaction.