Submarine Swaps: Bridging On-Chain and Lightning Bitcoin

Bitcoin exists in two distinct domains: on-chain UTXOs confirmed by miners, and off-chain Lightning balances locked inside payment channels. Moving value between these two domains is not as simple as sending a transaction. On-chain Bitcoin and Lightning balances follow different rules, different timelocks, and different settlement models. Submarine swaps solve this by constructing an atomic exchange that spans both layers, using the same Hash Time-Locked Contract (HTLC) primitive that powers Lightning routing itself.

First described by Alex Bosworth in 2018, submarine swaps have become foundational infrastructure for Lightning liquidity management. They power Loop (Lightning Labs’ liquidity service), Boltz Exchange, and numerous LSP implementations. Understanding how they work is essential for anyone operating a Lightning node or building on the network.

The Problem: On-Chain and Off-Chain Are Different Worlds

A Lightning channel balance is not a UTXO. It is a commitment transaction output that both channel parties have agreed upon but not broadcast. You cannot spend a Lightning balance on-chain without closing the channel, and you cannot deposit on-chain Bitcoin into an existing channel without a mechanism like splicing (which itself requires an on-chain transaction and coordination with your channel peer).

This creates practical problems. A node operator who has accumulated most of their capital on the Lightning side cannot pay an on-chain invoice. A merchant who receives on-chain payments cannot use those funds to rebalance a depleted Lightning channel without opening a new one. The two pools of capital are isolated.

Before submarine swaps, the primary options were: close a channel (expensive, slow, and disruptive), open a new channel (requires an on-chain transaction and confirmation wait), or find a trusted intermediary willing to exchange one form for the other. None of these are atomic. None guarantee that both sides of the exchange complete.

The Core Mechanism: HTLCs Across Layers

Submarine swaps exploit a key property of HTLCs: the same hash lock can secure commitments on different transaction layers. An HTLC on-chain and an HTLC inside a Lightning channel can both be conditioned on the same payment hash. When one is resolved by revealing the preimage, the other can be resolved too. This creates atomicity: either both legs of the swap complete, or neither does.

The construction works because HTLCs are fundamentally layer-agnostic. An on-chain HTLC is a Bitcoin script output with two spending paths: one requiring a hash preimage (the claim path) and one with a timelock (the refund path). A Lightning HTLC is encoded in commitment transactions with the same two conditions. The hash is the same; the enforcement layer is different.

Why atomicity matters: Without atomic swaps, exchanging on-chain for Lightning funds requires trusting a counterparty. If Alice sends on-chain Bitcoin first, the swap server could pocket it and never send the Lightning payment. If the server sends Lightning first, Alice could receive it and never broadcast the on-chain transaction. Submarine swaps eliminate this trust requirement entirely.

The two types of submarine swaps

Submarine swaps come in two directions, each solving a different liquidity problem:

The naming convention reflects the original “submarine” metaphor: a standard submarine swap moves funds from the visible on-chain layer “down” into the off-chain Lightning layer. A reverse submarine swap brings them back “up.”

Step by Step: A Submarine Swap (Loop In)

Suppose Alice wants to convert on-chain Bitcoin into Lightning balance. She is using a swap service (the server). Here is the protocol:

1. Alice requests a swap from the server, specifying the amount. The server generates a random secret (the preimage) and sends Alice the corresponding payment hash.
2. The server creates a hold invoice (also called a hodl invoice) on Lightning for the swap amount minus the server’s fee. A hold invoice locks the payment in-flight without settling it: the server knows the preimage but does not release it yet.
3. Alice constructs an on-chain HTLC: a transaction that locks her Bitcoin in a script with two spending conditions. The server can claim the funds by revealing the preimage of the agreed hash. Alice can reclaim the funds after a timelock (typically 24 to 72 hours) expires.
4. Alice broadcasts the on-chain HTLC and waits for confirmation. She then pays the server’s hold invoice over Lightning. The Lightning payment is now in-flight, held by the server.
5. The server sees Alice’s confirmed on-chain HTLC and settles the hold invoice by releasing the preimage to the Lightning network. Alice’s Lightning payment completes, and she now has the funds in her Lightning balance.
6. The server uses the same preimage to claim the on-chain HTLC output. The swap is complete.

The critical insight: the preimage that settles the Lightning payment is the same preimage that claims the on-chain funds. The server cannot take Alice’s on-chain Bitcoin without simultaneously settling her Lightning payment. Alice cannot receive the Lightning payment without the server being able to claim the on-chain funds. This is what makes the swap atomic.

What if something goes wrong?

Several failure modes exist, each handled by the protocol:

• If Alice never broadcasts the on-chain HTLC, no funds are at risk. The Lightning hold invoice eventually times out.
• If Alice broadcasts the on-chain HTLC but the server never settles the Lightning payment, Alice reclaims her on-chain funds after the timelock expires.
• If the server settles the Lightning payment but the on-chain claim transaction gets stuck in the mempool, the server still has the preimage and can claim once confirmed. The risk is fee-related: the server must ensure its claim transaction confirms before Alice’s refund timelock expires.

The stuck swap problem: During fee spikes, the on-chain HTLC claim transaction may not confirm quickly enough. If the server’s claim and Alice’s refund are both competing for confirmation near the timelock expiry, a race condition develops. Modern swap implementations mitigate this by using generous timelocks and by setting initial fees high enough to confirm within the window.

Reverse Submarine Swaps (Loop Out)

The reverse direction is more commonly used in practice. Node operators use Loop Out to drain Lightning balance into on-chain Bitcoin, freeing up inbound channel capacity in the process. The protocol inverts the roles of who generates the preimage.

1. Alice generates a random preimage and computes its hash. She sends the hash to the swap server along with an on-chain destination address.
2. The server constructs an on-chain HTLC: it locks the agreed amount (minus fees) in a script that Alice can claim with the preimage, or the server can reclaim after a timelock.
3. Once the on-chain HTLC confirms, the server sends Alice a Lightning invoice (a standard invoice, not a hold invoice) conditioned on the same hash. Alice pays it.
4. The server now holds the preimage (extracted from the settled Lightning payment) and could theoretically claim back the on-chain HTLC. But Alice already knows the preimage (she generated it) and claims the on-chain output first.

Wait: if the server learns the preimage from the Lightning payment, why can’t it race Alice to claim the on-chain HTLC? Because the on-chain HTLC is constructed so that only Alice’s key can claim via the preimage path. The server’s claim path is the timeout refund. Alice holds both the preimage and the correct key, making her claim uncontestable.

Pricing: Why Swaps Cost More Than Regular Transactions

Submarine swaps are not free. They involve multiple costs that compound into a total fee significantly higher than either a standalone on-chain transaction or a Lightning payment.

Cost components

• On-chain mining fee for the HTLC output creation (paid by whichever party constructs the on-chain leg)
• On-chain mining fee for claiming the HTLC output (paid by whichever party sweeps)
• Lightning routing fees for the payment leg (if the Lightning payment routes through multiple hops)
• Service fee charged by the swap provider (typically 0.1% to 1% of the swap amount)

During periods of high on-chain fee rates, the mining fees alone can make small swaps uneconomical. A swap of 100,000 sats during a 50 sat/vbyte fee market might cost 15,000 to 20,000 sats in combined on-chain fees, plus the service fee. This is why Autoloop implementations include configurable fee thresholds: automated swaps pause when fees exceed the operator’s willingness to pay.

Pricing comparison across providers

The service fee compensates the swap provider for several things: capital lockup during the swap window (the server’s funds are tied up in the HTLC until claimed), the risk of fee spikes making the claim transaction expensive, and the operational cost of running Lightning and on-chain infrastructure.

Swap Providers Compared

Several implementations of submarine swaps exist, each with different architectural choices.

Loop (Lightning Labs)

Loop is the most widely deployed submarine swap service. It integrates directly with LND (Lightning Labs’ Lightning implementation) and provides both Loop In and Loop Out functionality. Loop is primarily designed for node operators managing channel capacity: Loop Out drains local balance to create inbound liquidity, while Loop In replenishes outbound capacity from on-chain funds.

Autoloop extends Loop with automated threshold-based swaps. Operators configure minimum and maximum local balance ratios per channel, and Autoloop triggers swaps when channels drift outside those bounds. This reduces manual intervention but does not eliminate cost: each automated swap still incurs on-chain and service fees.

Boltz Exchange

Boltz takes a different approach by operating as a non-custodial exchange with a web interface. Users can perform swaps without running a full Lightning node: Boltz supports swaps from on-chain Bitcoin to Lightning invoices (and vice versa) through a browser-based flow. The swap protocol is the same HTLC construction, but Boltz handles the Lightning-side infrastructure.

Boltz also supports swaps involving the Liquid sidechain, adding a third domain (Liquid L-BTC) to the on-chain and Lightning pair. This enables three-way liquidity movement between on-chain Bitcoin, Lightning, and Liquid.

PeerSwap

PeerSwap eliminates the intermediary entirely. Instead of swapping through a service provider, two Lightning node operators perform a submarine swap directly with each other. If Alice and Bob share a channel that has become imbalanced, they can execute a swap where one side sends on-chain Bitcoin and the other sends the equivalent Lightning balance, rebalancing the channel without paying a third-party service fee.

The limitation is coordination: both peers must be running PeerSwap-compatible software, and the swap requires one party to have on-chain funds available. For operators with bilateral relationships and mutual interest in channel balance, PeerSwap is the most cost-efficient option.

Trust Model and Security Considerations

Submarine swaps are trustless in the cryptographic sense: the HTLC construction guarantees atomicity without requiring either party to trust the other. However, “trustless” does not mean “riskless.” Several practical risks remain.

Timelock races

The security of the swap depends on the claiming party being able to broadcast and confirm their transaction before the refund timelock expires. If the Bitcoin mempool is severely congested and the claim transaction cannot get confirmed in time, the refunding party may reclaim the funds. Swap implementations set timelocks conservatively (often 144 blocks or more) to provide ample margin, but extreme fee events can still create pressure.

Preimage exposure

Once a preimage is revealed on one layer, it becomes visible to anyone monitoring that layer. In a submarine swap, the preimage revealed on the Lightning network propagates through all forwarding nodes on the payment path. This is not a vulnerability per se (the HTLC construction accounts for it), but it does mean the claim window is time-sensitive. The claiming party should sweep the on-chain HTLC promptly after the preimage is exposed.

Server availability

Centralized swap providers (Loop, Boltz) represent single points of failure. If the server goes offline mid-swap, the swap may not complete. The user’s funds are not at risk (timelock refunds protect them), but the swap fails and the user must wait for the refund period to reclaim their capital. This is an availability risk, not a theft risk.

The Operational Overhead of Submarine Swaps

For Lightning node operators, submarine swaps are a necessary but costly part of channel management. Every circular rebalance that fails, every channel that depletes on one side, and every new inbound liquidity requirement potentially triggers a swap. The costs add up.

Consider a routing node that processes payments predominantly in one direction. Its channels gradually become imbalanced: local balance builds up on one side while remote balance accumulates on the other. To keep routing, the operator must periodically Loop Out to drain local balance and restore inbound capacity. Each Loop Out costs on-chain fees plus the service fee. Over months of operation, these fees can represent a significant fraction of routing revenue.

This creates a structural tension in Lightning economics: the nodes that route the most payments also incur the highest rebalancing costs. Submarine swaps are the primary tool for managing this, but they convert an off-chain liquidity problem into an on-chain fee expense. During the high-fee periods that periodically hit the Bitcoin mempool, this expense can spike dramatically.

Multi-Path Swaps and Advanced Patterns

Standard submarine swaps are single-path: one on-chain HTLC paired with one Lightning payment. More advanced patterns have emerged to handle larger amounts and improve reliability.

Splitting swaps across channels

Atomic multi-path payments (AMP) can be used on the Lightning leg of a swap, splitting the payment across multiple channels and routes. This allows swaps larger than any single channel’s capacity. The on-chain HTLC remains a single output, but the Lightning payment that resolves it may traverse multiple paths simultaneously.

Batched swaps

Loop and Boltz both support batching multiple swap claims into a single on-chain transaction. Instead of one on-chain claim per swap, the server aggregates multiple HTLC claims and sweeps them together. This amortizes the on-chain fee across multiple swaps, reducing the per-swap cost. Users benefit indirectly through lower service fees.

Submarine Swaps vs. Other Bridging Methods

Submarine swaps are not the only way to move Bitcoin between on-chain and Lightning. Several alternatives exist, each with different tradeoffs.

Splicing is the most direct competitor to submarine swaps for existing channel operators. A splice-in adds on-chain funds to a channel in a single transaction, and a splice-out removes them. The channel remains operational throughout. However, splicing requires cooperation from the channel peer and is not yet universally supported across Lightning implementations.

Beyond Swaps: Native Layer Bridging

Submarine swaps exist because Lightning and on-chain Bitcoin are fundamentally separate systems that must be bridged. The HTLC construction is elegant, but the overhead is real: multiple on-chain transactions, service fees, timelock windows, and the ever-present risk of fee spikes disrupting the swap flow.

Spark approaches the bridging problem differently. Moving Bitcoin from on-chain to Spark is a single deposit transaction: send Bitcoin to a Spark-controlled address, and the protocol credits your Spark balance once confirmed. There are no HTLCs, no timelocks, no swap servers, and no service fees beyond the standard mining fee for the deposit transaction. The protocol handles the transition natively rather than requiring an atomic swap mechanism bolted on top.

This architectural difference extends to exits as well. Withdrawing from Spark to on-chain Bitcoin uses pre-signed exit transactions that the user holds from the moment they receive funds. There is no counterparty to negotiate with, no swap to execute, and no timelock race to worry about. The exit is unilateral: the user broadcasts when ready.

The tradeoff, as with all Spark operations, is the trust model. Spark requires that at least one operator in its distributed set behaves honestly during transfers (a 1-of-n assumption). Submarine swaps require no such trust: they are fully trustless by construction. For operators already comfortable with Lightning’s trust model and tooling, submarine swaps remain the standard approach. For users who want simpler bridging without channel management overhead, Spark eliminates the need for swaps entirely.

Practical Considerations

For developers and node operators working with submarine swaps, several practical points are worth noting:

• Set refund timelocks generously. A 144-block timelock provides roughly 24 hours of margin, which is usually sufficient but can be tight during severe mempool congestion.
• Monitor mempool conditions before initiating swaps. Tools like mempool.space provide real-time fee estimates that help determine whether a swap is economical.
• Use Autoloop with fee caps. Uncapped automated swaps during fee spikes can drain node revenue faster than routing generates it.
• Consider PeerSwap for channels with cooperative peers. Eliminating the service fee makes frequent rebalancing more sustainable.
• Account for channel reserves when calculating swap amounts. The reserve is unavailable for swaps, so the effective swappable balance is slightly less than the channel balance shown in node management tools.

Conclusion

Submarine swaps are one of the most important pieces of Lightning infrastructure. By extending HTLCs across the on-chain and off-chain boundary, they enable trustless exchange between two otherwise incompatible Bitcoin domains. Loop, Boltz, and PeerSwap each implement this primitive with different operational philosophies, but the cryptographic core is the same: a shared hash lock that makes the swap atomic.

The costs are real. Every swap involves on-chain fees, service fees, and timelock risk. For high-volume routing nodes, these costs are a significant operational expense. For end users, they add friction to what should ideally be a seamless experience of moving value between layers.

As the Bitcoin scaling ecosystem evolves, the need for submarine swaps reflects a broader architectural question: should layers be bridged with bolt-on mechanisms, or should the protocol handle transitions natively? Different systems give different answers, and the right choice depends on the trust assumptions and operational complexity each user is willing to accept.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.