Lightning Loop: swapping bitcoin in and out of the Lightning Network

Non-custodial means the swap is a protocol, not a deposit

Lightning Loop is a non-custodial service offered by Lightning Labs that makes it easy to move bitcoin into and out of the Lightning Network. The features list frames the operational picture. There is automated channel balancing, privacy-forward non-custodial swaps, opportunistic transaction batching to save on fees, instant Loop-Outs for faster off-chain to on-chain swaps, static reusable addresses for Loop-Ins, and progress monitoring of in-flight swaps. The batching point is the one that changes the economics. A swap that waited long enough to be batched with others would cost less, so the client has a choice between waiting for a batch and swapping immediately, and the fast flag exists precisely to skip the saving. That is the trade the service is built around, and it is also why the fee savings are not automatic.

loopd is the daemon, loop is the client

The client needs a short-lived daemon to facilitate swaps, and starting it is one command:

loopd

To use testnet, the network flag is passed:

loopd --network=testnet

By default the daemon attempts to connect to the lnd instance running on localhost:10009 and reads the macaroon and the TLS certificate from ~/.lnd, and the README says this can be altered with command line flags, with loopd --help covering the rest. That dependency on lnd is the first practical constraint. Loop is not a standalone wallet, it is a client for a Lightning node, and the node has to be running and reachable for a swap to be possible. The daemon is described as short-lived in the sense that it does the coordination work for swaps, and the client commands talk to it rather than to the swap server directly.

Loop Out moves Lightning funds back to a Bitcoin address

Loop Out is the direction that turns Lightning balance into spendable on-chain funds, and the command takes an amount in satoshis:

loop out <amt_in_satoshis>

The notable options are spelled out. The --fast flag makes the swap happen immediately, and the README is explicit that this opts out of the fee savings that batching would otherwise provide. The --channel flag restricts the loop out to specific channels, which matters when you want the outbound liquidity to come from a particular peer rather than being selected for you. The --addr flag sets the address the funds go to, with the default being the lnd wallet, so the common case does not need an address at all. Progress is visible separately with loop monitor, which reports the status of a swap, so a swap that is waiting for a batch is not a silent state.

Loop In and AutoLoop cover the other direction

Loop In converts on-chain bitcoin into spendable Lightning funds:

loop in <amt_in_satoshis>

Two related capabilities make it more than a manual command. Static, reusable addresses for Loop-Ins let you publish one address and receive deposits into Lightning repeatedly, which is what makes Loop In usable as a deposit mechanism rather than a one-off conversion, and the README lists depositing to a Bitcoin address without closing channels as a use case. AutoLoop is the automated version of channel management, and the listed use cases are automating channel balancing, converting outbound liquidity into inbound liquidity with Loop Out, and refilling depleted Lightning channels with Loop In. The repository has a dedicated autoloop document for the details, and the interesting part is that AutoLoop is a client policy rather than a server feature, so you decide the thresholds and the daemon acts on them.

Two APIs, both behind TLS and macaroons

The daemon exposes a gRPC API, by default on port 11010, and a REST API, by default on port 8081. The security model mirrors lnd, since the gRPC and REST connections of loopd are encrypted with TLS and secured with macaroon authentication in the same way lnd is. Without a custom loop directory the TLS certificate is stored in ~/.loop/<network>/tls.cert and the base macaroon in ~/.loop/<network>/loop.macaroon, and the loop command picks those files up automatically on mainnet, while other networks need the --network flag so the CLI knows which subdirectory to look in. One warning in the README deserves repeating in bold in your own notes, because it is a common operational mistake. Loop's macaroons are independent from lnd's, so the same macaroon cannot be used for both loopd and lnd, and copying a macaroon across will not work even though the authentication scheme looks identical.

lnd needs all of its subservers, and the build is a Go install

The LND section states that Loop requires lnd to be built with all of its subservers, and gives the flag for people who build from source:

make install tags="signrpc walletrpc chainrpc invoicesrpc"

That is a hard prerequisite rather than a suggestion, because a node without the wallet, chain and invoice subservers cannot service a swap. Building Loop itself is a normal Go install from the command directory:

git clone https://github.com/lightninglabs/loop.git
cd loop/cmd
go install ./...

The container path exists too, with a multi-stage Dockerfile that cross-compiles rather than emulating, since the builder stage stays pinned to the build platform so the Go toolchain runs natively, and the final Alpine image exposes the two service ports:

EXPOSE 8081 11010

For anyone producing release files themselves, the README points to a reproducible release guide, and the Makefile shows the version stamping with the commit, the commit hash and a dirty flag injected as linker flags.

Regtest for development, beta tags for releases

For local work, the README points at a regtest server environment example that runs a stripped down dummy Loop server in a local regtest Bitcoin network, which is the sensible way to develop against the client without touching real funds. The release history shows a project that ships under a beta label, with v0.33.3-beta on 2026-06-21, v0.34.0-beta on 2026-07-23 and v0.35.0-beta on 2026-08-25, and the last push was on 2026-10-20, so the code moves faster than the tags. The dependency list explains the weight of the client, with lnd at a v0.21.0-beta version, plus lndclient, the looprpc and swapserverrpc protocol modules, taproot-assets, which points to work on assets moving through swaps, and aperture, the Lightning Labs proxy. The licence is MIT, the default branch is master, and security issues are handled through SECURITY.md rather than the public issue tracker, with the README asking that security disclosures not be filed as public issues.

Editorial conclusion

Adopt Lightning Loop if you run lnd and need to move bitcoin between the chain and Lightning, whether by hand with loop out and loop in or automatically with AutoLoop keeping channels balanced. Do not adopt it if you need a custodial exchange or if your node cannot reach the swap server, since the daemon does the coordination. Verify first that your lnd was built with all of its subservers, because the README requires the signrpc, walletrpc, chainrpc and invoicesrpc tags, keep in mind that the release line is still tagged as beta, and set aside the two API ports, gRPC on 11010 and REST on 8081, both of which need TLS and a macaroon.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. lightninglabs/loop on GitHub
4. README
5. Releases