Lightning Loop

• Name: Lightning Loop
• URL: https://docs.lightning.engineering/lightning-network-tools/loop.md
• Category: non-custodial Lightning liquidity management / submarine swap bridge / channel rebalancing control plane
• Tags: bitcoin-ecosystem
• Summary: Lightning Loop is Lightning Labs’ liquidity-control rail for lnd, not just a swap widget. The real surface is continuous channel management: Loop Out, Loop In, AutoLoop policy, static deposit addresses, instant loop-outs, and authenticated daemon/API access for operators who need to move liquidity without closing channels.
• What it does:
  • Moves offchain bitcoin to onchain addresses with Loop Out and moves onchain bitcoin into Lightning capacity with Loop In
  • Rebalances channels by shifting outbound liquidity into inbound liquidity, or refilling depleted channels, without closing them
  • Supports automated liquidity management with AutoLoop rules, fee caps, budgets, and dispatch limits
  • Provides static Loop In addresses so operators can pre-deposit funds onchain and deploy them into Lightning later
  • Ships as a standalone daemon and CLI, and also as part of Lightning Terminal (litd)
  • Exposes gRPC and REST APIs secured with TLS and macaroon auth while using L402s for service authentication
• Key claims:
  • The Loop docs describe it as a service for making a Lightning transaction to an onchain Bitcoin address or sending onchain bitcoin directly into a Lightning channel, and explicitly say it uses trustless submarine swaps
  • The same docs say Loop Out transactions are batched to save fees and that Loop uses L402s for authentication
  • The repository README calls Loop a non-custodial off/on-chain bridge and highlights automated channel balancing, privacy-forward swaps, instant Loop Outs, static reusable Loop In addresses, and progress monitoring
  • The get-started docs say Loop comes bundled with Lightning Terminal, can also run standalone, and requires lnd with specific subservers enabled
  • The repository README says loopd connects to an lnd instance, exposes its own gRPC and REST APIs, and secures them with TLS plus loop-specific macaroon authentication
  • The Autoloop docs show that operators can set node-, peer-, or channel-level liquidity rules, budget refresh periods, fee ceilings, and automatic dispatch behavior, which is strong evidence that Loop is an operational liquidity-management tool rather than only a manual swap product
  • The static-address docs say static Loop In addresses are two-of-two taproot multisig timeout addresses, allow pre-deposits and withdrawals without giving up control, and can later be used for near-instant liquidity deployment into Lightning
  • Those static-address docs also warn that the L402 token is part of user identification to the service and losing it can force the user to wait for timeout-based recovery, which is an important trust-model detail
• Whitepaper: No canonical standalone Lightning Loop whitepaper or litepaper surfaced in this pass. The clearest current sources of truth were the official Loop docs and the public lightninglabs/loop repository; see ../whitepapers/lightning-loop-primary-sources-2026-05-02.md.
• Sources:
  • https://docs.lightning.engineering/lightning-network-tools/loop.md
  • https://docs.lightning.engineering/lightning-network-tools/loop/get-started.md
  • https://docs.lightning.engineering/lightning-network-tools/loop/autoloop.md
  • https://docs.lightning.engineering/lightning-network-tools/loop/static-loop-in-addresses.md
  • https://github.com/lightninglabs/loop

Internal linkages

• Broadest swap-and-rebalancing anchor in this branch: boltz.
• Direct-peer counterpoint when liquidity stays between existing channel partners instead of going through a service: peerswap.
• Company / packaging boundary above the service path: lightning-labs.

Protocol / company boundary

• Keep this note on the product and service surface: Loop In / Loop Out mechanics, AutoLoop policy, static-address behavior, daemon/API access, and the specific recovery and authentication assumptions operators inherit when they use the service.
• Use lightning-labs for the wider release, docs, bundling, and cross-product packaging shell around Loop, LND, Lightning Terminal, Taproot Assets, and newer agent-facing tooling.
• That split matters because how does Loop manage liquidity? and whose company stack steers the default service path, docs, and surrounding operational bundle? are related but not identical questions.

Control surface

• Practical leverage sits in AutoLoop policy, fee caps, budgets, service authentication, static-address recovery assumptions, and how much of the node’s liquidity management gets handed to Lightning Labs’ swap path instead of left to bilateral or self-routed rebalancing.

• Keep the company shell visible too: Lightning Labs decides much of the surrounding documentation, service framing, and bundle path through which operators actually meet Loop.

• Read Loop as a service-coupled liquidity policy engine, not as a mere swap button.

• Last reviewed: 2026-08-09 UTC