|
| 1 | +### Project Summary: Lightning Loop |
| 2 | + |
| 3 | +**1. Core Purpose:** |
| 4 | +Lightning Loop is a non-custodial service from Lightning Labs for bridging the Bitcoin mainnet (on-chain) and the Lightning Network (off-chain). It enables users to rebalance their channels—moving funds into or out of Lightning—without the need for closing and reopening them. The system is architected to be non-custodial, using atomic swaps to ensure neither the user nor the server can lose funds. |
| 5 | + |
| 6 | +**2. Architecture & Core Components:** |
| 7 | +The project is a client daemon (`loopd`) that connects to a user's `lnd` node and communicates with a remote Loop server via gRPC. It is composed of several distinct managers and services that handle different aspects of the swap lifecycle. |
| 8 | + |
| 9 | +* **`loopd` (Daemon):** The main executable that bootstraps and orchestrates all other components. It initializes the database, connects to `lnd`, starts the gRPC/REST servers, and launches all the feature-specific managers (`liquidity`, `instantout`, `staticaddr`, etc.). Its lifecycle and configuration are managed in the `loopd/` and `cmd/loopd/` packages. |
| 10 | + |
| 11 | +* **Finite State Machines (FSM):** The core logic for managing swaps is built around a robust FSM pattern (`fsm/`). Each swap type (Instant Out, Static Address Loop-in, etc.) has its own state machine that defines its lifecycle. This ensures that swaps progress through a defined set of states, with transitions triggered by on-chain or off-chain events, making the system resilient to failures and restarts. |
| 12 | + |
| 13 | +* **Database (`loopdb/`):** Persistence is handled by a database layer that supports both `bbolt` and `PostgreSQL` (via `sqlc` for query generation). It stores swap contracts, state history, liquidity parameters, and other critical data, allowing the daemon to recover and resume operations after a restart. |
| 14 | + |
| 15 | +* **Notification Manager (`notifications/`):** Manages a persistent gRPC subscription to the Loop server. It listens for asynchronous events, such as a `Reservation` being offered or a request to co-sign a `StaticAddress` sweep, and dispatches them to the appropriate internal manager. |
| 16 | + |
| 17 | +* **On-Chain Transaction Management:** |
| 18 | + * **Sweeper (`sweep/`):** A utility library responsible for crafting and signing sweep transactions for various HTLC types (P2WSH, P2TR, etc.). |
| 19 | + * **Sweep Batcher (`sweepbatcher/`):** A sophisticated service that batches multiple on-chain sweeps into a single transaction to save on-chain fees. It has its own database store and logic for creating, tracking, and RBF-bumping (Replace-By-Fee) batch transactions until they are confirmed. |
| 20 | + |
| 21 | +**3. Swap Types & Features:** |
| 22 | + |
| 23 | +* #### Standard Loop Out |
| 24 | + * **Goal:** Move funds from Lightning to an on-chain address. |
| 25 | + * **Mechanism:** The client pays an off-chain Lightning invoice to the Loop server. In return, the server sends an equivalent amount (minus fees) to the user's on-chain address via an on-chain HTLC. The client sweeps this HTLC using the same preimage from the Lightning payment, completing the atomic swap. |
| 26 | + |
| 27 | +* #### Standard Loop In |
| 28 | + * **Goal:** Move on-chain funds into the Lightning Network. |
| 29 | + * **Mechanism:** The client sends funds to an on-chain HTLC. This HTLC is spendable by the server *if* it knows the swap preimage (which it learns by paying the client's off-chain Lightning invoice), or by the client after a timeout. Once the server sees the on-chain HTLC, it pays the invoice to "loop in" the funds and then sweeps the HTLC with the revealed preimage, often in cooperation with the client to save fees. |
| 30 | + |
| 31 | +* #### Instant Loop-Out (`instantout/`) |
| 32 | + * **Goal:** A faster, more efficient Loop-Out that prioritizes a cooperative path. |
| 33 | + * **Mechanism:** Built on **Reservations**—on-chain UTXOs controlled by a 2-of-2 MuSig2 key between the client and server. The primary flow is a cooperative "Sweepless Sweep" that spends the reservation directly to the client's destination. A non-cooperative fallback to a standard HTLC ensures the swap remains non-custodial. |
| 34 | + |
| 35 | +* #### Static Address (`staticaddr/`) |
| 36 | + * **Goal:** Provide a permanent, reusable on-chain address for receiving funds that can then be looped into Lightning. |
| 37 | + * **Mechanism:** The address is a P2TR (Taproot) output with a cooperative MuSig2 keyspend path and a unilateral CSV timeout scriptspend path for safety. This feature is composed of several sub-managers: |
| 38 | + * `address/`: Manages the creation and lifecycle of the static address itself. |
| 39 | + * `deposit/`: Monitors the address for new UTXOs (deposits) and manages their state (e.g., `Deposited`, `Expired`, `LoopingIn`). |
| 40 | + * `loopin/`: Orchestrates the Loop-In process for funds held at the static address. |
| 41 | + * `withdraw/`: Handles cooperative withdrawal of funds from the address back to the user's wallet without performing a swap. |
| 42 | + |
| 43 | +* #### Liquidity Manager (`liquidity/`) |
| 44 | + * **Goal:** Automate channel liquidity management based on user-defined rules. |
| 45 | + * **Mechanism:** Periodically assesses channel balances and can suggest or automatically dispatch swaps to meet target liquidity levels. It supports detailed rules, fee budgets, and an "easyAutoloop" mode for simple balance targeting. |
| 46 | + |
| 47 | +**4. Technology & Cross-Cutting Concerns:** |
| 48 | + |
| 49 | +* **Language:** Go |
| 50 | +* **Remote Communication:** gRPC. Definitions are split between `looprpc/` (client-facing) and `swapserverrpc/` (server-facing). |
| 51 | +* **Cryptography:** Extensively uses Taproot and MuSig2 for efficiency, privacy, and complex spending conditions, especially in the `instantout` and `staticaddr` features. |
| 52 | +* **Labeling (`labels/`):** A utility to create and validate labels for swaps, which helps distinguish between user-initiated and automated swaps (e.g., `[reserved]: autoloop-out`). |
| 53 | +* **Assets (`assets/`):** Contains logic for interacting with `tapd` (Taproot Assets Protocol Daemon), allowing Loop to facilitate swaps involving assets other than Bitcoin. |
0 commit comments