Skip to main content

Loop

Welcome to the API reference documentation for Lightning Loop.

Lightning Loop is a non-custodial service offered by Lightning Labs to bridge on-chain and off-chain Bitcoin using submarine swaps. This repository is home to the Loop client and depends on the Lightning Network daemon loop. All of loop’s supported chain backends are fully supported when using the Loop client: Neutrino, Bitcoin Core, and btcd.

The service can be used in various situations:

  • Acquiring inbound channel liquidity from arbitrary nodes on the Lightning network
  • Depositing funds to a Bitcoin on-chain address without closing active channels
  • Paying to on-chain fallback addresses in the case of insufficient route liquidity
  • Refilling depleted channels with funds from cold-wallets or exchange withdrawals
  • Servicing off-chain Lightning withdrawals using on-chain payments, with no funds in channels required
  • As a failsafe payment method that can be used when channel liquidity along a route is insufficient

Usage​

Learn how to install, configure, and use Loop by viewing the documentation in the Builder's Guide.

Summary​

This site features the documentation for loop (CLI), and the API documentation for Python and JavaScript clients in order to communicate with a local loopd instance through gRPC.

gRPC​

The code samples assume that the there is a local loopd instance running and listening for gRPC connections on port 11010. LOOP_DIR will be used as a placeholder to denote the base directory of the loopd instance. By default, this is ~/.loop on Linux and ~/Library/Application Support/Loop on macOS.

At the time of writing this documentation, two things are needed in order to make a gRPC request to an loopd instance: a TLS/SSL connection and a macaroon used for RPC authentication. The code samples will show how these can be used in order to make a successful, secure, and authenticated gRPC request.

The original *.proto files from which the gRPC documentation was generated can be found here:

REST​

View a listing of all REST URLs on the REST Endpoints page.

The code samples assume that the there is a local loopd instance running and listening for REST connections on port 8081. LOOP_DIR will be used as a placeholder to denote the base directory of the loopd instance. By default, this is ~/.loop on Linux and ~/Library/Application Support/Loop on macOS.

At the time of writing this documentation, two things are needed in order to make an HTTP request to an loopd instance: a TLS/SSL connection and a macaroon used for RPC authentication. The code samples will show how these can be used in order to make a successful, secure, and authenticated HTTP request.

The original *.swagger.json files from which the gRPC documentation was generated can be found here:

REST Encoding​

NOTE: The byte field type must be set as the base64 encoded string representation of a raw byte array. Also, any time this must be used in a URL path (ie. /v1/abc/xyz/{payment_hash}) the base64 string must be encoded using a URL and Filename Safe Alphabet. This means you must replace + with -, / with _, and keep the trailing = as is. Url encoding (ie. %2F) will not work.

This documentation was generated automatically against commit 7f1344113fd0ed6f3d0f770f5e163d1c7f5c3342.