Submarine Swap

What Is a Submarine Swap?

A submarine swap is an atomic swap between on-chain Bitcoin and the Lightning Network. It lets a user send BTC on one layer and receive it on the other, with no trusted intermediary holding funds at any point. The name comes from the metaphor that one half of the transaction is "above water" (visible on-chain) while the other half is "below water" (off-chain on Lightning).

The concept was independently conceived by Alex Bosworth and Olaoluwa Osuntokun (Lightning Labs CTO) in 2018. Bosworth built the first implementation and published it publicly, while Osuntokun is credited with coining the term "submarine swap." The technology reached Bitcoin mainnet in August 2018 and has since become a core building block of Lightning infrastructure.

Submarine swaps solve a fundamental problem: Lightning channels are isolated from the base layer. Without submarine swaps, moving funds between on-chain and Lightning required opening or closing channels, which is slow and expensive. Submarine swaps allow fluid movement between layers while keeping existing channels intact. For a comprehensive walkthrough, see the submarine swaps deep dive.

How It Works

Submarine swaps use HTLCs on both the on-chain and Lightning sides. An HTLC combines two conditions: a hash lock (funds can only be claimed by revealing a specific preimage) and a timelock (if the preimage is not revealed in time, funds return to the sender). By using the same payment hash for both the on-chain and Lightning HTLCs, the two transactions become atomically linked.

Swap-In: On-Chain to Lightning

A swap-in (also called Loop In) moves on-chain BTC into Lightning. This is the original direction Bosworth implemented:

1. The swap provider generates a random 32-byte preimage and computes its SHA-256 hash
2. The user creates an on-chain HTLC: a Bitcoin script with two spending paths. The success path requires the preimage plus the provider's signature. The refund path requires only the user's signature after a timelock expires
3. The user broadcasts a transaction locking BTC to this HTLC address and waits for on-chain confirmation
4. Once confirmed, the swap provider pays the user's Lightning invoice. The Lightning payment settles by revealing the preimage through the normal HTLC resolution mechanism
5. The provider uses the revealed preimage to claim the on-chain HTLC funds before the timelock expires

If the Lightning payment fails, the user waits for the timelock to expire and reclaims their on-chain funds. Neither party can steal from the other.

Swap-Out: Lightning to On-Chain

A swap-out (also called Loop Out) moves Lightning funds to an on-chain address. This direction was more difficult to build: it required changes to LND to support hodl invoices, which hold Lightning payments without immediately settling:

1. The user generates a preimage and payment hash
2. The swap provider creates an on-chain HTLC locked to the same hash, with the user as the recipient
3. The user pays a Lightning invoice to the provider. Since this is a hodl invoice, the provider holds the payment without settling
4. Once the on-chain HTLC confirms, the user claims the on-chain funds by revealing the preimage
5. The provider observes the preimage on-chain and settles the hodl invoice, completing the swap

Swap-outs are the primary tool for gaining inbound liquidity without closing channels. For detailed guidance on using swaps for channel management, see the Lightning Loop guide.

On-Chain HTLC Script

The on-chain component of a submarine swap uses a Bitcoin script with two spending conditions. Modern implementations use Taproot with MuSig2 for cooperative key-path spends, but the underlying logic follows this pattern:

OP_HASH256 <hash> OP_EQUAL
OP_IF
    # Success path: preimage revealed, receiver claims funds
    <receiver_pubkey> OP_CHECKSIG
OP_ELSE
    # Refund path: timelock expired, sender reclaims funds
    <timeout_blockheight> OP_CHECKLOCKTIMEVERIFY OP_DROP
    <sender_pubkey> OP_CHECKSIG
OP_ENDIF

A typical submarine swap pair of on-chain transactions is approximately 260 to 290 virtual bytes. At current fee rates, on-chain costs range from a few hundred to several thousand satoshis per swap depending on mempool conditions.

Submarine Swap Providers

Lightning Loop

Lightning Loop is Lightning Labs' production submarine swap service, built for LND node operators. The client is open source, though the server is proprietary. Loop uses L402 tokens for authentication and supports both Loop In and Loop Out. Loop Out transactions are batched to reduce on-chain fees.

Loop's fee structure includes a service fee (variable, typically around 500 sats for a 300,000 sat swap), on-chain miner fees, and off-chain routing fees. Loop Out also requires a 30,000 sat prepayment held in escrow to prevent denial-of-service attacks. For automated liquidity management, Loop integrates with Autoloop, which triggers swaps automatically based on configurable thresholds.

Boltz Exchange

Boltz Exchange is a fully non-custodial swap provider that requires no accounts or KYC. Boltz charges a 0.1% service fee for on-chain-to-Lightning swaps and 0.5% for the reverse direction, plus network fees. Boltz also supports chain-to-chain swaps between Bitcoin mainchain and Liquid.

Boltz's current protocol (API v2) uses Taproot with MuSig2 for all swaps. This enables cooperative key-path spends, reducing on-chain fees by approximately 10% compared to legacy script-based swaps. Taproot swaps also enable cooperative refunds: if a swap fails, both parties can immediately agree on a refund transaction instead of waiting for the timelock to expire. In 2026, Boltz expanded to support non-custodial USDT and USDC swaps.

PeerSwap

PeerSwap takes a different approach: instead of routing through a centralized provider, it enables Lightning nodes to perform atomic swaps directly with their channel peers. This eliminates the intermediary fee entirely, making it the lowest-cost option. The trade-off is that both peers must support the PeerSwap protocol.

Use Cases

Channel Liquidity Management

The primary use case for submarine swaps is managing channel capacity. When a node operator has spent most of their outbound liquidity on a channel, a swap-out (Loop Out) sends Lightning funds on-chain and restores inbound capacity. Conversely, when inbound liquidity is exhausted, a swap-in replenishes outbound capacity. This avoids the cost and downtime of closing and reopening channels. For alternative approaches, see the research on channel management strategies.

Cold Storage Sweeps

Merchants and routing nodes that accumulate Lightning revenue can use swap-outs to move earnings to cold storage without closing any channels. This maintains the node's routing infrastructure while securing profits on-chain.

Payment Bridging

Submarine swaps allow on-chain-only users to pay Lightning invoices without opening their own channels. Wallets like Muun use submarine swaps transparently under the hood: the user sends on-chain BTC, and the wallet's swap service completes the Lightning payment. This dramatically lowers the barrier to Lightning adoption.

Layer-2 Interoperability

Because submarine swaps bridge on-chain and off-chain Bitcoin, they serve as a connector between different layers. Users can move funds between the base layer, Lightning, and other systems like Liquid through chained swaps. This interoperability is essential as Bitcoin's Layer 2 ecosystem grows. For context on how Spark fits into this landscape, see the Spark Layer 2 overview.

Risks and Considerations

Fee Overhead

Every submarine swap incurs both on-chain transaction fees and a service fee charged by the swap provider. Service fees typically range from 0.1% to 1% of the swap amount. During periods of high on-chain fee rates, the miner fees alone can make small swaps uneconomical. Users should compare the cost of a swap against alternatives like splicing or circular rebalancing.

Fund Lockup During Failures

If a swap fails partway through, funds remain locked in the on-chain HTLC until the timelock expires. Legacy implementations used timelocks of one to four days. Modern Taproot-based swaps (like Boltz v2) extend the timeout window to seven days but offer cooperative refunds that return funds immediately when both parties are online. The worst case occurs when the counterparty goes offline: the user must wait for the full timelock duration.

Fee-Rate Race Conditions

The on-chain claim transaction must confirm before the timelock expires. If the claim transaction pays too low a fee during a sudden mempool spike, it may not confirm in time. This creates a race between the claim and refund paths. Implementations mitigate this with replace-by-fee and fee bumping, but the risk remains during extreme congestion.

Griefing Attacks

A malicious party can initiate a swap and refuse to complete it, locking the counterparty's funds until timeout. Lightning Loop mitigates this with a 30,000 sat prepayment that is forfeited if the swap is not completed. Boltz relies on cooperative refund mechanisms and reputation. PeerSwap is inherently more resistant because swaps occur directly between known channel peers.

Provider Dependency

Most submarine swaps rely on a counterparty with sufficient liquidity on both sides. If the swap provider goes offline or runs out of capacity, the swap cannot proceed. Lightning Loop further concentrates this risk because its server is proprietary: users can only swap with Lightning Labs. Boltz and PeerSwap offer more decentralized alternatives.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.