Submarine Swap
Funds that are locked into a Lightning channel are usually limited to being transferrable solely across the Lightning Network. They can be sent back and forth on a given channel, but cannot come back on-chain unless the channel is closed.
This presents a few challenging scenarios:
- managing channel balancing (available liquidity)
- sending transactions across the boundaries of on-chain and off-chain
Submarine swaps have emerged as a way to bridge these deficiencies by allowing persons to send funds from an on-chain address directly into an open Lightning channel and vice versa.
Mechanism
There are a few variants to how the swaps actually work but the overall mechanism is that a Lightning invoice is generated by one of the parties and the payment hash of that invoice is included in an on-chain transaction. This is done in such a way that payment of the Lightning invoice reveals the preimage of the hash which allows the other party to spend the on-chain transaction and collect funds.
Some examples of this mechanism include:
Typical Scenarios
Channel balancing
In Lightning Network design there is a popular analogy with marbles in a tube that is used to describe the problem of being able to send/receive across a channel and the limitations that come from not having balanced channels.
[Insert explainer here]
Channels can be rebalanced if they can somehow receive funds or route funds in the opposite direction to the desired direction that the user would like funds to flow in. One way of doing this is reallocating balances from other channels the user owns, but this still doesn’t impact the overall send/receive liquidity that a node is capable of at a given point in time.
By being able to effectively “teleport” funds from an on-chain address into a Lightning channel or set of channels and vice versa, a user is able to rebalance the overall state of their node by using on-chain funds.
On/Off-chain payments
Using this mechanism, merchants can also directly pay on-chain invoices with Lightning funds and vice versa by using some submarine swap service or client in the middle.
Novel Scenarios
Handling toxic change
A potential application of this mechanism could also be the handling of toxic UTXOs from processes like mixing and coinjoins (example here). The change can be sent to a submarine swap service and funds received into some channel so that the funds are effectively teleported away from those UTXOs in a fairly unlinkable way.
The submarine swap provider would still theoretically be able to make this linkage.s