Efficient self-custodial asset exchanges on Lightning ‒ Off-chain swaps and a central order book
tl;dr Taproot-based assets like stablecoins can be swapped atomically with BTC in an instantaneous yet trustless manner when deposited into Lightning payment channels. Combined with an execution logic like a central order book, this enables highly efficient self-custodial exchanges.
Introduction ‒ Taproot & overlay asset protocols
Bitcoin’s Taproot upgrade has enabled a set of overlay applications on top of Bitcoin through its novel design of Bitcoin outputs and signatures. One novelty it enables is the ability to commit to additional arbitrary data inside an output in a hashed format and for that output to still be spendable. In principle, many of these kinds of commitments and corresponding applications were possible before Taproot. However, Taproot has improved things like cryptographic complexity, privacy implications, and the overall developer experience.
An example of an overlay application protocol based on Taproot is Taro, an asset protocol that lives inside of Merkle trees committed to in Taproot outputs. The assets can be stablecoins or other securities, for example. The data commitment includes asset specifics such as the name and the total issued amount as well as information on asset ownership. The asset ownership is organized in a way similar to BTC ownership; the assets are sent to addresses owned by a private key. Another more complex example of an overlay application would be RGB.
This blog post deals with a concept for exchanging Taproot-based assets in an efficient yet trustless manner. This is possible by depositing the assets and BTC into Lightning payment channels and exchanging both through a combination of trustless atomic swaps and a central order book.
Off-chain atomic swaps
Due to Taro’s ownership model based on addresses similar to Bitcoin that are nested inside actual Bitcoin UTXOs, it is straightforward to deposit Taro assets into Lightning payment channels. This enables an interesting new application: Purely off-chain atomic swaps.
Previously, atomic swaps on Bitcoin were mostly used for cross-blockchain swaps or for so-called submarine swaps of on-chain BTC with BTC inside a payment channel. Both require at least one side of the swap being on-chain with the usual wait times necessary until enough confirmation blocks have been written.
Once Taproot-based payment channels on the Lightning network are rolled out, it will be possible to deposit both BTC and other Taproot-based assets like stablecoins into Lightning payment channels. This in turn will make it possible to send either one to the other side of a payment channel locked by a hash-time locked contract (HTLC).
Figure 1 shows how it works: One party sends a Taproot-based asset to the other side of a payment channel by paying a HODL invoice and therefore adding an unresolved HTLC. The other party sends BTC to the other side of the payment channel also by paying a HODL invoice based on the same pre-image and therefore also adding an unresolved HTLC. In fact, both transfers do not have to happen inside the same channel but let’s assume this for simplicity reasons for now.
When the pre-image is revealed, both payments, the BTC one and the Taproot-based asset one, are settled and an atomic swap of the two is finalized. The preimage for this may have been created and revealed by either one of the parties or by a third party, depending on the application.
Such off-chain atomic swaps of BTC with a Taproot-based asset (or it could also be a swap of two Taproot-based assets with each other) is just as trustless and as fast as any payment on the Lightning network.
Central order book
So if you want to swap your asset or your BTC and you can do so in an instantaneous yet trustless manner, two questions come up:
1) At what exchange rate can you swap?
2) Whom do you swap with?
A solution for these questions that has existed for ‘a long time’ is to gather many trading parties, buyers and sellers, at a central marketplace, i.e. an exchange. An exchange enables for a number of buyers and sellers (of a Taproot-based asset in exchange for BTC or another Taproot-based asset) to place their orders of various sizes and at various prices and find one or multiple counterparties to match their orders.
A common way to organize such an exchange for fungible assets is a central so-called ‘limit order book’ with a bid and an ask side. Most modern stock exchanges are based on this approach. The idea is to collect buy and sell orders at different prices and different amounts in two separate books. Given enough market participants this allows for an efficient order matching and a corresponding efficient discovery of a fair price.
Whenever a buy order is placed whose price is above or exactly at the lowest sell order price on the ask side or whenever a sell order is placed whose price is below or exactly at the highest buy order price on the bid side, an order match occurs.
Figure 2 shows how the concept of off-chain atomic swaps can be combined with a central order book: The exchange running the central order book enters separate off-chain atomic swaps with Alice and Bob, respectively, with Alice being the buyer of a Taproot-based asset and Bob being the seller. The settlement of both atomic swaps is based on the revelation of two separate pre-images both held by the exchange.
The revelation of the pre-image is left to the central order book logic. Assuming Alice places her order first, entering an off-chain swap agreement with the exchange, it is saved in the order book and waiting to be matched by another order. Now Bob comes along and essentially wants to do the exact reverse trade, also entering an off-chain swap agreement with the exchange (for simplicity reasons let’s assume the same exchange rate and the same order amount). Whenever he places his order, the order is matched to Alice’s by the order book logic and the exchange reveals both pre-images corresponding to the off-chain swaps.
Trust model
Terms like decentralized, trustless, self-custodial etc. describe what’s unique about Bitcoin and also the Lightning network. Let’s try to untangle what is true about an exchange platform like the one described above.
First of all, the described exchange is literally centralized since the buyers as well as sellers have to be connected to the same exchange for their orders to be matched to a corresponding counterpart in the order book. Further, the exchange, a single entity, takes care of the preimage creation and revelation.
In essence, centralization is what creates liquidity on the exchange and therefore makes the exchange efficient. It enables a high-speed matching of different order sizes and an efficient price discovery just like on a traditional stock exchange.
However, the described atomic swaps between Alice and the exchange and Bob and the exchange still remain trustless and Alice as well as Bob decide for themselves at what exchange rate they are willing to have their respective swap executed. This makes the exchange self-custodial since neither Alice nor Bob need to give up custody of their funds at any point. They merely agree to exchange their funds at a certain rate.
It remains up to the exchange and the central order book logic to decide whether it will trigger the swap execution by revelation of the pre-image. It can decide to do so or not. This is the only risk Alice and Bob carry; their order might or might not be executed.
In summary, an exchange solution like the one described above can be described as trustless and self-custodial from the user perspective despite being centralized for good reasons.
Summary & Outlook
Taproot-based assets can be swapped atomically with each other or with BTC in an instantaneous yet trustless manner when deposited into Lightning payment channels. Combined with an execution logic like a central order book, this enables highly efficient self-custodial asset exchanges.
The concept of an efficient self-custodial asset exchange is not limited to the asset protocol Taro. It rather seems to be applicable to other Taproot-based asset protocols such as RGB. I took Taro as the main example, however, due to its relative simplicity.
Besides a central order book, other execution logics that trigger the pre-image revelation are conceivable. These could be oracle-based ones that execute based on a price feed or an automated market maker as it is used by other decentralized exchanges.
L2.auction
I am currently working on an implementation of the introduced concept in my project L2.auction.
Edits: Spelling, grammar, added stablecoins as example for assets in several places, minor corrections in figures and captions, clarification on Taproot novelties, clarification on the term Taproot-based asset and two specific implementation examples: RGB and Taro.
