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:
looprpc/client.proto
looprpc/debug.proto
swapserverrpc/instantout.proto
swapserverrpc/reservation.proto
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:
looprpc/client.swagger.json
looprpc/debug.swagger.json
swapserverrpc/instantout.swagger.json
swapserverrpc/reservation.swagger.json
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
d198bb8230a84a918bf332f29d3e4d308d8375e1
.