A Closer Look at Submarine Swaps in the Lightning Network

Submarine swaps have been in the talk for a couple of weeks and there are already some interesting implementations in products and services . But, what exactly are they and how do they work? In this post we answer these questions.

To understand submarine swaps, we first need to talk about HTLCs: hashed time-locked contracts. They are easier to understand than what it seems. And, the good thing is that understanding HTLCs is not just key to understanding submarine swaps but also the Lightning Network itself.

HTLC as building blocks

Let’s say you are a proud owner of a bitcoin and you send it to an address that belongs to your friend, Martin. To spend the bitcoin, Martin needs to prove he has the corresponding private key to that address. This is how Bitcoin works at the basic level: Martin proves he has the key and he can spend the money.

I’ve said “at the basic level” because you could add more conditions for Martin to spend that bitcoin. In particular, you could add the condition that Martin has to reveal a certain secret within a given period of time, called a timeout. When the time expires, the bitcoin can be spent by another set of keys, for instance, some you own.

Where does this secret come from? The secret is a piece of information Martin, or someone else in the network, created. If Martin created the secret himself he will, of course, know it at the moment of payment. If someone else created it, Martin needs to find out what the secret is.

In any case, it makes sense that, as soon as Martin gets to know the secret, he will spend the bitcoin, even if that means sending to another address he owns, to prevent the timeout from getting activated. We’ll call this action to claim funds.

So, this is an HTLC in a nutshell: it is a contract that requires the receiver in a transaction to prove they know a particular secret, within a certain period of time, in order to spend the money.

It turns out that adding this condition enables a very interesting and useful feature: the ability to chain payments. This might not be initially relevant for on-chain transactions, where you could pay directly to the final recipient at any time, but it is very useful in the Lightning Network, where being able to pay directly to everyone would be very inefficient.

Because it is easier to understand the purpose of HTLCs within the context of a routed network, such as the Lightning Network, we’ll see an example of an off-chain payment first. Keep in mind, however, that HTLCs work in both on-chain and off-chain transactions. They even work in other blockchains, like Litecoin’s.

HTLCs in the Lightning Network

Imagine you want to pay 1 BTC to Sandra but you don’t share a payment channel with her. Instead, Thomas, who has channels with both of you, will route the payment. What could go wrong in this chain of payments?

Without HTLCs, and depending on who pays first, two things could go wrong:

If you pay Thomas first, trusting he would then pay Sandra, Thomas could run away with your funds.

If Thomas pays Sandra first, trusting you will then pay him, you could make Thomas pay your expenses for you and never give the money back.

Using an HTLC, Sandra can create a secret that only she knows and tell you to safely send the bitcoin to Thomas, adding a clause that in order to spend the bitcoin he needs to reveal the secret within a period of time. If he doesn’t, you’ll be able to spend the bitcoin. Sandra will give you this instruction in the QR code with the Lightning invoice she shows you. She can do this without revealing you the secret itself, because of an interesting property: you will know Thomas is revealing the secret she created, even without knowing the secret beforehand.

Now Thomas can send Sandra a bitcoin, and include the same clause: to spend it she needs to reveal the secret within a period of time. Sandra, who already knows the secret, can claim the money right away. At the moment of claiming the funds, Sandra reveals the secret, Thomas gets to know it and he can claim the bitcoin you send him.

The result is you successfully paid Sandra through Thomas, without trusting each other and nobody risking their funds. Now you and Thomas know the secret Sandra created, and you can both use it as a proof of payment, since Sandra revealed it to claim the money she was being paid. Notice that the time-outs are important for having a way to “rollback” payments in case Sandra refuses or is unable to reveal the secret.

HTLCs in Submarine Swaps

HTLCs can be included in both, on-chain and off-chain, transactions. In fact, they can be used to chain payments that happen between an on-chain sender and an off-chain receiver, and vice versa. These are submarine swaps.

Let’s suppose you want to pay something in the Lightning Network but don’t want to manually manage channels yourself. Submarine swaps allow you to use your on-chain bitcoins to pay the lightning invoice, through a swap provider. How would this work?

The Lightning merchant generates a QR code hinting you the secret you should ask the swap provider to reveal in order to claim the money you will send them. You can now safely send the swap provider your bitcoin, making an on-chain HTLC.

The swap provider cannot spend the bitcoin you just sent to him because he doesn’t know the secret yet. Instead, he will transfer a bitcoin to the Lightning merchant, via Lightning, adding the clause that to claim the fund, the merchant has to reveal the secret.

The Lightning merchant already knows the secret, but to claim the money he has to reveal it. In that process, the swap provider gets to know it, and claims the money you sent them. Both, the swap provider and the merchant, claim the money received, but there’s a difference: while the swap provider claims the money on-chain, the merchants does it off-chain.

What are Submarine Swaps useful for?

Submarine swaps might be the easiest way for someone to make their first payment via Lightning. While you still incur on-chain fees, the payment flow is similar to one on-chain and payments can be instant (depending on the implementation). Also, if you are just looking to try the Lightning Network, opening a channel itself also requires an on-chain transaction. Since we are in the early days of Lightning, having an easy on-ramp for people to try it is important. This is the reason why we implemented submarine swaps in Muun Wallet.

Submarine swaps can also be useful for cases where users need to move part of their money on-chain to off-chain, and the other way around. For instance, after a successful week of sales via Lightning, a merchant might need to get on-chain bitcoins to pay providers. Loop Out provides a way of doing a reverse submarine swap, and at the same time rebalance channels to get inbound capacity.

Finally, and given that submarine swaps can also be done with other coins, you could use for instance Litecoin, which has lower fees and faster confirmation times, to make a Lightning payment to a merchant or provide more liquidity to your channels.

Submarine swaps started as an idea by Alex Bosworth and Olaoluwa Osuntokun from Lightning Labs and have gained more popularity with time. Although not without its downsides, it has some interesting applications that can help the network in its early days in two big fronts: liquidity and adoption.

You can read more about the Lightning Network in these posts:

Visit Muun Website: https://muun.com/

Follow Muun on Twitter: https://twitter.com/MuunWallet