Overview

This is a case study on Lightning Loop, a submarine swap implementation.

Lightning Loop is a non-custodial service for moving funds between Bitcoin's Lightning Network (off-chain) and the Bitcoin blockchain (on-chain). All swaps use Hash Time-Locked Contracts (HTLCs) to ensure atomic execution - either both parties succeed or both fail.

Roles

• Client: Loop daemon (loopd) connected to user's lnd node (Open source, include loop cli and loopd: https://github.com/lightninglabs/loop)
• Server: Loop server operated by Lightning Labs (Close source)

Standard Loop Out (Off-chain → On-chain)

Move funds from Lightning channels to an on-chain address.

Protocol Flow

1. Client generates swap preimage s and computes hash H(s)
2. Client requests quote from Server with desired amount and H(s)
3. Server returns:
   • Server's public key pk_server
   • Prepayment invoice (small fee, unrestricted)
   • Swap invoice (Lightning) with payment hash H(s)
   • CLTV expiry height for HTLC
4. Client pays prepayment invoice (small fee to server)
5. Client pays swap invoice (off-chain Lightning, locked to H(s))
6. Server creates on-chain P2WSH HTLC:
   • Success path: Unlocked by s + signature from pk_client
   • Timeout path: Unlocked by pk_server signature after CLTV expiry
7. Server publishes HTLC transaction on-chain
8. Client sweeps on-chain HTLC using preimage s (reveals it on-chain)
9. Server sees preimage on-chain, settles swap invoice using s

Security Properties

• Client safety: Only pays after receiving server's commitment (invoices), knowing swap can proceed