Lightning Loop: Complete Guide to Submarine Swaps

Lightning Loop is Lightning Labs' non-custodial service for moving Bitcoin between the Lightning Network and the base chain without closing channels. It uses submarine swaps to let node operators drain excess local balance to cold storage, replenish depleted outbound capacity, and keep channels in a healthy state for routing. If you run a Lightning node, Loop is one of the primary tools for keeping your liquidity where it needs to be.

This guide walks through both swap directions step by step, explains autoloop configuration, breaks down the fee structure, and compares Loop to alternatives like Boltz, PeerSwap, and circular rebalancing. By the end, you will know when each approach makes economic sense and when it does not.

Why Lightning Channels Need Liquidity Management

A Lightning channel has a fixed total capacity set at opening. That capacity splits between two sides: local balance (what you can send) and remote balance (what you can receive, also called inbound liquidity). As payments flow through the channel, this split shifts. A merchant who receives 500,000 sats through a 1,000,000-sat channel now has 500,000 local and 500,000 remote. After a few more payments, the channel is full on their side and they can no longer receive.

This creates three recurring problems for node operators:

• Receiving capacity dries up as incoming payments accumulate on the local side
• Sending capacity dries up as outgoing payments deplete the local side
• Capital locked in Lightning cannot be moved to on-chain cold storage without closing the channel

Closing and reopening channels is expensive: two on-chain transactions, potential routing downtime, and lost channel age (which affects routing score in many implementations). Loop solves all three problems by swapping funds between layers while keeping channels open.

How Loop Out Works

Loop Out moves sats from your Lightning channel to an on-chain address. This frees up inbound liquidity in the channel, letting you receive more payments. It is a reverse submarine swap: the Lightning payment goes to the Loop server, and the server publishes an on-chain HTLC that you sweep to your wallet.

Loop Out Step by Step

1. You generate a random preimage and compute its SHA-256 hash. This hash links the on-chain and off-chain halves of the swap.
2. You send a Lightning payment to the Loop server using a hold invoice. The server holds this payment: it can see the hash but cannot settle until it learns the preimage.
3. You also send a small prepay invoice (approximately 30,000 sats) as an anti-DoS deposit. This settles immediately.
4. The Loop server publishes an on-chain HTLC locked to the same hash. The HTLC has two spending paths: a hash path (requiring the preimage plus your signature) and a timeout path (allowing the server to reclaim funds after a CLTV expiry).
5. You monitor the blockchain, see the HTLC confirm, and broadcast a sweep transaction that reveals the preimage and sends the funds to your on-chain address.
6. Once the preimage appears on-chain, the Loop server learns it and settles the held Lightning invoice. The swap is complete.

Why the prepay exists: When the Loop server publishes an on-chain HTLC, it spends real miner fees. If you abandon the swap after the HTLC is published, the server loses those fees. The prepay deposit makes this kind of griefing attack economically impractical. If the swap completes normally, the prepay is absorbed into the total fee.

Loop Out CLI Example

The basic command is straightforward:

loop out 500000 --addr bc1q... --conf_target 6

Additional flags let you specify which channel to drain (--channel), set maximum routing fees (--max_swap_routing_fee), or skip batching for faster execution (--fast). Use loop quote out 500000 to get a fee estimate before committing.

How Loop In Works

Loop In is the inverse: it moves on-chain BTC into your Lightning channels, replenishing outbound (sending) capacity. This is a standard submarine swap. You fund an on-chain HTLC, and the Loop server pays you via Lightning.

Loop In Step by Step

1. You request a Loop In from the server. The server provides an on-chain HTLC address and a hash that it generated.
2. You send BTC to this HTLC address. The HTLC is locked to the server's hash, with a timeout path allowing you to reclaim funds if the swap fails.
3. After the on-chain transaction confirms, the Loop server sends you a Lightning payment routed through the network to your node.
4. Your node settles the Lightning payment by revealing the preimage (standard Lightning payment settlement).
5. The server, having learned the preimage from the Lightning payment path, sweeps the on-chain HTLC. Both sides are settled.

You can use --last_hop to control which channel receives the incoming Lightning payment, targeting specific channels that need outbound capacity. The --external flag allows funding from a separate wallet rather than your node's on-chain wallet.

Static Loop In Addresses

A significant addition in the February 2025 MuSig2 upgrade: Loop now supports static, reusable deposit addresses using 2-of-2 MuSig2 taproot constructs. You can fund a Loop In address on-chain during low-fee periods (even months in advance) and execute the actual swap later. The timeout for static addresses is 14,400 blocks (approximately 100 days), giving you a wide window to initiate the swap when conditions are favorable.

As of Loop v0.32.0-beta (March 2026), you can also open new Lightning channels directly from static address deposits using loop openchannel, combining deposit and channel operations into a single workflow.

Loop Out vs Loop In: When to Use Each

Autoloop: Automated Liquidity Management

Manually monitoring channel balances and dispatching swaps does not scale. A routing node with 50+ channels needs automation. Autoloop watches your channel balances and automatically dispatches Loop swaps when they drift outside configured thresholds.

Enabling Autoloop

Autoloop is disabled by default. The simplest way to enable it:

loop setparams --autoloop=true --easyautoloop=true --localbalancesat=1000000

Easy autoloop mode dispatches swaps whenever your total local balance across all channels exceeds the threshold. For finer control, set per-channel or per-peer rules:

loop setrule {channel_id} --incoming_threshold=25 --outgoing_threshold=25

This tells autoloop to initiate a swap whenever inbound or outbound capacity drops below 25% of the channel's total capacity. Rules can target individual channels or peers, but not both simultaneously for the same channel.

Budget and Fee Controls

Autoloop includes granular fee controls to prevent runaway spending:

• --autobudget: total satoshis allowed for fees within the budget period (covers server fees, sweep costs, and routing fees, but not swap amounts)
• --autobudgetrefreshperiod: how often the budget resets (e.g., 168h for weekly)
• --feepercent: maximum fee as a percentage of swap amount
• --sweeplimit: maximum sat/vbyte for on-chain sweep transactions
• --maxprepay: cap on the no-show prepay fee
• --autoinflight: maximum concurrent swaps (default: 1)

Use loop suggestswaps to preview what autoloop would dispatch without actually executing. This is valuable for tuning your parameters before going live.

Tip: As of Loop v0.31.1-beta (May 2025), autoloop defaults to a 30-minute publication deadline for on-chain transactions. This slower pace enables batching, which reduces miner fees. If speed matters more than cost, override with a shorter deadline.

Loop Fee Structure

Every Loop swap involves multiple fee components. Understanding them is essential for determining when a swap makes economic sense versus when you should consider alternatives.

Fee Breakdown

Total costs vary significantly with mempool conditions. During low-fee periods, a 500,000-sat Loop Out might cost roughly 2,000 to 3,000 sats total. During fee spikes, the on-chain component alone can exceed that. Always run loop quote before committing to a swap.

When Swaps Make Economic Sense

The key question: does the cost of the swap justify the liquidity it provides? Consider these factors:

• Routing revenue potential: if a rebalanced channel earns more in routing fees than the swap cost, it pays for itself
• Alternative cost: closing and reopening a channel requires two on-chain transactions, which during normal fee conditions costs more than a single Loop swap
• Cold storage extraction: if you need funds on-chain for reasons beyond liquidity (e.g., moving to a hardware wallet), Loop Out is the only option besides closing channels
• Timing flexibility: static Loop In addresses let you fund during low-fee weekends and execute swaps later, decoupling the on-chain cost from the swap timing

MuSig2 Upgrade: What Changed in 2025

In February 2025, Lightning Labs integrated MuSig2 into Loop, the most significant architectural change since the service launched. MuSig2 is a multi-signature protocol for Schnorr signatures that produces outputs indistinguishable from regular single-signer transactions on the blockchain.

The practical benefits:

• Privacy: cooperative swap completions look like ordinary Taproot spends, not multi-sig or HTLC constructions
• Lower fees: smaller transaction sizes due to Schnorr signature aggregation
• Instant Loop Out: users can Loop Out without waiting for on-chain confirmations by using pre-funded non-HTLC parent transactions with virtualized child HTLCs
• Pre-funding: static reusable Loop In addresses allow on-chain deposits months before the swap executes

Alternatives to Lightning Loop

Loop is not the only option for Lightning liquidity management. Depending on your setup, alternatives may be cheaper, more private, or better suited to your needs.

Boltz Exchange

Boltz is a non-custodial, open-source submarine swap service supporting Bitcoin mainchain, Lightning, and Liquid. Service fees range from approximately 0.1% to 0.5% with dynamic network fees on top. Unlike Loop, Boltz is not tied to LND: it works with any Lightning implementation and offers a web interface for manual swaps. Boltz also supports chain-to-chain swaps (e.g., Bitcoin to Liquid), which Loop does not.

The tradeoff: Boltz lacks autoloop-style automation. You can run boltz-client for programmatic access, but there is no built-in daemon that monitors channel balances and dispatches swaps automatically.

PeerSwap

PeerSwap takes a fundamentally different approach: fully decentralized, peer-to-peer atomic swaps directly with your channel counterparty. One node sends on-chain BTC (or L-BTC on Liquid) to its peer, who simultaneously shifts the equivalent Lightning balance in the channel. There are no service fees: you only pay on-chain miner costs.

The key limitation: PeerSwap only works between direct channel peers, not through the broader network. Both peers must run the PeerSwap plugin. It also does not add or remove net liquidity from Lightning: it rebalances existing channels, whereas Loop moves funds between layers entirely.

Circular Rebalancing

Circular rebalancing sends a payment from your node, routed through the network, back to yourself through a different channel. Sats leave through a channel with excess outbound and arrive through one that needs it. No on-chain transaction is involved: you pay only Lightning routing fees.

This is the cheapest option when viable routes exist. However, it does not change net liquidity: it shuffles existing Lightning funds between your channels. Large rebalances often fail due to insufficient route capacity, and routing fees can accumulate on high-volume nodes. It also provides no path to move funds to on-chain cold storage.

Comparison at a Glance

Practical Tips for Loop Users

Optimizing Loop Out

• Time your swaps during low-fee weekends when mempool clears: the on-chain sweep fee is often the largest cost component
• Use --conf_target with a high block target (e.g., 144 for next-day) to get a lower fee rate on the sweep transaction
• Let autoloop batch multiple swaps at a slow publication deadline (the default 30-minute window) to reduce per-swap miner costs
• After a Loop Out, the sweep transaction supports RBF (Replace-By-Fee): if your initial fee rate was too low and the timeout is approaching, you can bump the fee

Optimizing Loop In

• Fund static Loop In addresses during low-fee periods, then execute the swap weeks or months later when you actually need the liquidity
• Use --last_hop to target a specific channel that needs outbound capacity, rather than letting the incoming payment land on a random channel
• Use --external to fund from a separate wallet (e.g., your exchange account) if your node's on-chain wallet has insufficient funds

Autoloop Tuning

• Start with loop suggestswaps for a week before enabling autoloop: this reveals your actual liquidity patterns without spending fees
• Set conservative budgets initially (--autobudget 50000 --autobudgetrefreshperiod 168h) and adjust upward based on observed swap frequency
• A 24-hour failure backoff (the default) prevents retrying swaps during temporary fee spikes or routing issues

The Fundamental Problem Loop Solves (and How Spark Avoids It)

Loop exists because of a structural property of Lightning: channel capacity is fixed at opening, and balance shifts with every payment. Every Lightning node operator, from a solo routing node to a large Lightning Service Provider, must continuously manage this liquidity or risk being unable to route payments. Loop, Boltz, PeerSwap, and circular rebalancing are all symptoms of this underlying constraint.

Spark takes a different architectural approach. Because Spark uses statechains rather than payment channels, there is no concept of channel capacity, inbound liquidity, or balance sides. A Spark user who receives 1,000,000 sats can immediately send 1,000,000 sats: there is no channel to deplete and no remote balance to manage. This eliminates the entire category of liquidity management tooling that Lightning requires.

For developers building payment applications, this distinction matters. A Lightning-based app must either run liquidity management infrastructure (Loop, autoloop, LSPs) or rely on a custodial provider that handles it behind the scenes. A Spark-based app needs neither. To explore how this works in practice, see the Spark developer documentation and the Lightning liquidity deep dive for a fuller comparison of the two models.

Conclusion

Lightning Loop is essential infrastructure for anyone operating a Lightning node. Loop Out lets you extract on-chain funds and free inbound capacity. Loop In lets you push on-chain BTC into your channels. Autoloop turns this from a manual chore into an automated system with configurable budgets and thresholds. The February 2025 MuSig2 upgrade added privacy, lower fees, and static deposit addresses that decouple funding timing from swap execution.

That said, Loop is a tool for managing a structural limitation. It does the job well, but the job only exists because Lightning channels have finite, directional capacity. If you are evaluating Bitcoin Layer 2 options for a new application, consider whether your use case benefits from channel-based architecture or whether a channel-free protocol like Spark is a better fit. For existing Lightning infrastructure, Loop remains one of the most reliable and well-integrated liquidity management solutions available.

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.