Self-Custodial Lightning

What Is Self-Custodial Lightning?

Self-custodial Lightning refers to Lightning Network wallet implementations where the user retains control of their own private keys and channel state data. Unlike custodial Lightning wallets, where a third party holds funds on the user's behalf, self-custodial wallets ensure that no intermediary can freeze, seize, or spend the user's bitcoin without their explicit authorization.

The concept matters because Lightning was designed to scale Bitcoin payments without sacrificing self-custody: the principle that users alone control their money. In practice, however, the operational demands of running a Lightning channel have pushed many users toward custodial services. Self-custodial Lightning wallets aim to close this gap by abstracting the complexity of channel management while preserving the user's key ownership.

The most widely used self-custodial Lightning wallets today include Phoenix (by ACINQ), Breez, and Zeus. Each takes a different approach to balancing usability with sovereignty, but all share the core property that the user holds the keys to their funds.

The Custody Spectrum

Lightning wallets fall along a spectrum of custody and trust, not a binary divide. Understanding where a wallet sits on this spectrum is essential for evaluating its security properties.

Fully Custodial

Wallets like Wallet of Satoshi and Alby (in its hosted mode) hold your funds entirely. You do not have private keys, channel state, or the ability to force-close channels. The provider can freeze your balance, comply with subpoenas, or lose your funds through a hack or bankruptcy. Onboarding is seamless: download the app, receive a Lightning address, start transacting.

LSP-Backed Self-Custodial

Wallets like Phoenix and Breez keep your keys on your device but rely on a Lightning Service Provider for channel opens, inbound liquidity, and routing. The LSP cannot spend your funds unilaterally because the channel is enforced by HTLCs and commitment transactions. If the LSP disappears, you can force-close your channel and recover funds on-chain. The tradeoff: the LSP sees your payment metadata and controls channel management operations.

Full Node Self-Custodial

Running your own Lightning node with software like LND, Core Lightning, or LDK gives maximum control. You manage channels, select peers, set routing fees, and handle liquidity. Zeus can connect to a remote personal node, giving mobile access to a self-managed setup. This option demands technical expertise and infrastructure: a server, reliable internet, and ongoing maintenance.

How It Works

Self-custodial Lightning wallets combine several techniques to give mobile users a manageable experience without surrendering key control.

Key Ownership

When you install a self-custodial Lightning wallet, the app generates a seed phrase and derives your private keys locally. These keys never leave your device. Channel funding transactions are signed with your key, and the counterparty (typically the LSP) holds the other key in a 2-of-2 multisig arrangement. Neither party can spend from the channel unilaterally under normal operation.

LSP Channel Management

An LSP handles the operational complexity that would otherwise require running a full node:

1. Channel opens: the LSP opens a channel to your wallet, often using just-in-time (JIT) channels that are created when your first inbound payment arrives
2. Inbound liquidity: the LSP allocates capacity on its side of the channel so you can receive payments without managing liquidity yourself
3. Splicing: some wallets (notably Phoenix) maintain a single channel that is dynamically resized through splice-in and splice-out operations rather than opening multiple channels
4. Routing: the LSP acts as your gateway to the broader Lightning Network, finding payment paths and forwarding HTLCs on your behalf
5. Breach monitoring: the LSP or a delegated watchtower watches for revoked commitment transactions while your phone is offline

LSPS Standardization

The Lightning community has developed the LSPS (Lightning Service Provider Specifications) to standardize how wallets interact with LSPs. LSPS1 covers channel requests, and additional specs address zero-conf channels, JIT liquidity, and webhook notifications. These standards, now maintained under the bLIP (Bitcoin Lightning Improvement Proposal) process, aim to let wallets switch between LSPs without vendor lock-in.

Example: Phoenix Architecture

Phoenix, developed by ACINQ, illustrates a common LSP-backed pattern:

User Device                    ACINQ (LSP)
┌──────────────┐              ┌──────────────┐
│ Private keys │◄── 2-of-2 ──►│ LSP key      │
│ Channel state│   multisig   │ Routing node │
│ Seed phrase  │              │ Liquidity    │
└──────────────┘              └──────────────┘
       │                             │
       │   Single spliced channel    │
       │◄───────────────────────────►│
       │                             │
       ▼                             ▼
  User controls keys          LSP provides services
  Can force-close             Cannot spend user funds

Phoenix maintains one channel per user that grows or shrinks through splicing. When a payment exceeds the current channel capacity, Phoenix splices in additional funds on the fly. The user sees a simple balance that goes up and down without thinking about channels.

Mobile Node Challenges

Running a Lightning node on a mobile device introduces fundamental engineering challenges that shape every self-custodial wallet's design decisions.

Background Execution Limits

Mobile operating systems aggressively limit background processing to preserve battery life. iOS gives apps approximately 30 seconds of background execution time, while Android is somewhat more permissive but still kills idle processes. A Lightning node needs persistent TCP connections to channel peers, continuous blockchain monitoring, and the ability to respond to incoming payments at any time. These requirements conflict directly with mobile OS power management.

Gossip Bandwidth

Lightning nodes build a network graph by downloading gossip messages from peers. A full gossip sync can require tens of megabytes of data, consuming mobile bandwidth and battery. Solutions like Rapid Gossip Sync (used by LDK-based wallets) compress this process by serving pre-computed snapshots from a server, reducing sync time from minutes to seconds.

Channel Monitoring

If a channel counterparty broadcasts a revoked commitment transaction while your phone is off, you must respond with a justice transaction before the timelock expires or risk losing funds. Self-custodial mobile wallets address this by delegating monitoring to the LSP or a watchtower service. This introduces a trust assumption: you trust the watchtower to remain online and respond correctly.

Use Cases

Self-custodial Lightning wallets serve users who want the speed and low cost of Lightning without surrendering control of their funds.

• Personal savings in transit: users who keep meaningful balances on Lightning choose self-custody to avoid counterparty risk. If a custodial provider goes bankrupt or gets hacked, users with self-custodial wallets can force-close to Bitcoin's base layer.
• Privacy-sensitive payments: while LSP-backed wallets still expose payment metadata to the LSP, they avoid the complete surveillance that custodial services can perform. Zeus, routing through Tor by default, adds network-layer privacy on top.
• Merchant point-of-sale: Breez bundles merchant tools (POS terminal, invoicing) with self-custodial Lightning, letting small businesses accept bitcoin payments without trusting a third party to hold their revenue.
• Developer integration: the Breez SDK and LDK allow app developers to embed self-custodial Lightning into their own products, inheriting LSP connectivity without building node infrastructure from scratch.

Self-Custodial Lightning vs. Spark

Traditional self-custodial Lightning requires users to manage payment channels, even when an LSP abstracts much of the complexity. Channels must be opened and closed with on-chain transactions, liquidity must flow in both directions, and receiving payments requires the wallet (or its LSP) to be reachable.

Spark takes a different approach to self-custody. Instead of channels, Spark uses a statechain-inspired architecture where virtual UTXOs (vUTXOs) represent ownership of on-chain bitcoin. Transfers happen by rotating the private key share between sender and receiver through FROST threshold signatures, without opening or closing channels. Users do not need to be online to receive funds, and there is no concept of inbound or outbound liquidity to manage.

Both models preserve self-custody: the user holds keys and can exit to Bitcoin L1 unilaterally. The difference is operational. Lightning's channel model requires ongoing maintenance (or an LSP to handle it), while Spark's stateless transfers eliminate channel management entirely. For a detailed comparison of the two protocols, see Lightning vs. Spark.

Risks and Considerations

LSP Dependency

Most self-custodial Lightning wallets connect to a single LSP. If that LSP goes offline, stops serving your wallet, or censors transactions, your ability to send and receive payments is disrupted until you force-close and move to another provider. The LSPS specifications aim to mitigate this through interoperability, but in practice most wallets today are tightly coupled to one LSP.

Privacy Tradeoffs

An LSP that opens your channels and routes your payments can observe your transaction amounts, timing, and counterparties. ACINQ has acknowledged that Phoenix currently offers limited privacy advantages over custodial wallets in this regard. Wallets like Zeus mitigate this by connecting to a user-controlled node, but this shifts the complexity burden back to the user.

Zero-Conf Channel Trust

Many LSPs use zero-conf channels for instant onboarding: the channel is usable before the funding transaction confirms on-chain. This introduces a brief trust window where the LSP could theoretically double-spend the funding transaction. In practice, a reputable LSP has no economic incentive to do this, but the trust assumption exists.

On-Chain Scalability Limits

Every self-custodial Lightning channel requires at least one on-chain transaction to open and one to close. At scale, if millions of users each need their own channels, block space demand could become a bottleneck. This is one motivation behind channel factories, splicing (to reduce open/close cycles), and alternative L2 designs like Ark and Spark that share UTXOs among multiple users.

Backup Complexity

Unlike on-chain Bitcoin where a seed phrase recovers all funds, Lightning channel state is dynamic and cannot be fully reconstructed from a seed alone. Self-custodial wallets use static channel backups (SCBs) that store enough information to trigger a force-close and recover funds, but not to resume normal channel operation. Losing both your device and your backup can mean losing channel funds permanently.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.