Custodial Lightning
Lightning Network wallets and services where a third party holds the user's private keys and manages channel liquidity.
Key Takeaways
- Custodial Lightning wallets let users send and receive Lightning payments without managing channels, liquidity, or private keys: a third-party service handles all of the infrastructure, but also controls the funds.
- The tradeoff is convenience for trust: custodial providers can freeze accounts, lose funds to hacks, or face regulatory shutdowns, reintroducing the counterparty risk that Bitcoin was designed to eliminate.
- Non-custodial alternatives like Spark now offer comparable ease of use without requiring users to surrender self-custody of their Bitcoin.
What Is Custodial Lightning?
Custodial Lightning refers to Lightning Network wallets and services where a third party holds the user's private keys, manages payment channels, and controls the underlying funds. The user interacts with a simple interface to send and receive payments, but the service operator maintains custody of the Bitcoin: the user holds an IOU, not actual satoshis.
This model emerged because running the Lightning Network in a self-custodial way is complex. Users need to open and fund payment channels, maintain inbound liquidity to receive payments, keep a node online to monitor for fraud, and pay on-chain fees for channel management. Custodial wallets abstract all of this away: the provider runs the Lightning node, manages channels, and handles routing, while the user simply sees a balance and a send/receive interface.
Popular custodial Lightning wallets have included Wallet of Satoshi (one of the most widely used Lightning wallets globally), Strike, and Cash App's Lightning integration. Some wallets like BlueWallet previously offered custodial Lightning via LndHub before deprecating the feature in favor of self-custodial approaches.
How It Works
In a custodial Lightning setup, the provider operates the Lightning infrastructure on behalf of all users. The architecture typically works like this:
- The provider runs one or more Lightning nodes with large channel capacity and extensive connections to the network
- Users create accounts (often just an email or phone number) and receive a balance tracked in the provider's internal database
- When a user wants to receive a payment, the provider generates a Lightning invoice from its own node
- When the payment arrives at the provider's node, the provider credits the user's account balance internally
- Outgoing payments work in reverse: the user requests a payment, the provider debits the internal balance and sends the Lightning payment from its own node
Payments between users of the same custodial service often never touch the Lightning Network at all. They are simply database updates: debit one account, credit another. This makes internal transfers instant and free, but it also means the provider has complete visibility into every transaction.
Hosted Channels
Hosted channels are a hybrid approach that sits between fully custodial and fully non-custodial Lightning. Defined in a specification by the IMMORTAN project, a hosted channel is a virtual payment channel where the host (service provider) holds all the funds on-chain, and the client maintains a signed state representing their balance.
Unlike standard Lightning channels, hosted channels do not have a funding transaction on the Bitcoin blockchain. The host commits to honoring the channel balance, and the client holds cryptographic proof of the latest state. However, the client cannot unilaterally close the channel and recover funds on-chain: if the host disappears or refuses to cooperate, the client has no recourse beyond the signed state as evidence.
This makes hosted channels custodial in practice: the user depends on the host's honesty and availability to access their funds. The advantage is that hosted channels are extremely lightweight: no on-chain transaction is needed to open them, users can receive payments immediately, and the host can provide inbound liquidity at zero cost.
LndHub Architecture
LndHub is an open-source account system built on top of LND. It allows anyone to run a custodial Lightning service by wrapping an LND node with a simple REST API. Users connect to the LndHub server through compatible wallets and transact via the server's Lightning node.
# LndHub architecture (simplified)
User App → LndHub API → LND Node → Lightning Network
↓
PostgreSQL DB
(user balances,
transaction history)
# User "receives" a payment:
1. LndHub creates invoice on its LND node
2. Sender pays the invoice via Lightning
3. LND node receives the sats
4. LndHub credits user's database balance
# User "sends" a payment:
1. User submits a Lightning invoice to LndHub
2. LndHub verifies user has sufficient balance
3. LND node pays the invoice
4. LndHub debits user's database balanceThe LndHub model makes it straightforward to deploy community-oriented custodial wallets. It was used by BlueWallet's custodial service (discontinued in 2023) and continues to be used by self-hosted instances. The tradeoff is clear: the LndHub operator holds all the keys and all the funds.
Why Custodial Lightning Is Popular
Lightning's complexity creates real barriers that push users toward custodial solutions. For a comprehensive comparison of the two approaches, see the self-custodial vs. custodial wallets deep dive. The key friction points include:
- Channel management: opening a channel requires an on-chain transaction (with fees that can range from under a dollar to over $50 during congestion), and users need enough channel capacity to cover their expected payment sizes
- Inbound liquidity: to receive payments, someone must have already committed funds to a channel pointed at you, a concept that confuses new users and requires coordination with an LSP or peer
- Online requirement: self-custodial Lightning wallets need to be online periodically to monitor for channel fraud (though watchtowers can help)
- Backup complexity: Lightning channel state is dynamic and cannot be recovered from a seed phrase alone, unlike on-chain Bitcoin
- Fee management: users must handle on-chain fees for opening and closing channels, reserve requirements, and routing fees
Custodial wallets eliminate all of these concerns. A user downloads an app, creates an account, and can send or receive Lightning payments within seconds. No channel management, no liquidity planning, no on-chain fees, no watchtowers. For many users, especially those making small payments, the convenience is compelling.
The Custody Spectrum
Lightning custody is not binary. A range of models exists between full custodial and full self-custody:
| Model | Key Control | Channel Management | Counterparty Risk |
|---|---|---|---|
| Full custodial (Wallet of Satoshi, Strike) | Provider holds all keys | Provider manages everything | Maximum |
| Hosted channels | Provider holds keys; user holds signed state | Provider manages channels | High (no unilateral exit) |
| LSP-assisted (Phoenix, Breez) | User holds keys | LSP handles liquidity and channels | Low (user can force-close) |
| Spark | User holds keys via threshold signatures | No channels needed | Minimal (unilateral exit to L1) |
| Full self-custody (running own node) | User holds all keys | User manages everything | None |
LSP-assisted wallets like Phoenix and Breez represent an important middle ground. They use Lightning Service Providers to handle channel management and liquidity provisioning, but the user retains their own keys and can force-close channels to recover funds on-chain without the LSP's cooperation. This preserves self-custody while simplifying the experience.
Regulatory Implications
Custodial Lightning services face the same regulatory requirements as any business that holds customer funds. In the United States, custodial wallet providers typically qualify as money transmitters under FinCEN guidance, requiring state-by-state licensing, anti-money laundering (AML) compliance, and KYC procedures.
This regulatory burden has already affected the custodial Lightning ecosystem. Wallet of Satoshi, one of the most popular Lightning wallets globally, removed itself from the U.S. App Store and Google Play Store for U.S. users in late 2023, citing regulatory concerns. The decision highlighted the tension between operating a simple custodial Lightning wallet and complying with money transmission regulations.
In the European Union, the Markets in Crypto-Assets Regulation (MiCA) imposes similar requirements on custodial crypto asset service providers, including capital requirements, governance standards, and safeguarding rules for client assets. Custodial Lightning wallets operating in the EU must obtain authorization as a Crypto-Asset Service Provider (CASP).
Non-custodial Lightning wallets and Layer 2 solutions like Spark generally fall outside these frameworks because the user retains control of their own keys. The provider does not hold customer funds and therefore does not meet the definition of a money transmitter or custodian. This regulatory distinction is a significant structural advantage for non-custodial architectures.
Risks and Considerations
Counterparty Risk
The fundamental risk of custodial Lightning is counterparty risk. When a provider holds your funds, you are exposed to their solvency, security practices, and honesty. If the provider is hacked, goes bankrupt, commits fraud, or is seized by regulators, user funds may be lost with no recourse. The history of cryptocurrency is filled with custodial failures: Mt. Gox, FTX, and numerous smaller incidents demonstrate that trusting a third party with your keys means trusting them with everything.
Privacy Concerns
Custodial Lightning providers have complete visibility into their users' transaction history. They know who paid whom, when, and how much. This data can be subpoenaed by governments, stolen in data breaches, or used for commercial surveillance. In contrast, self-custodial Lightning payments benefit from onion routing, which hides payment details from intermediate nodes.
For users who value financial privacy, custodial Lightning is functionally equivalent to a traditional payment app: every transaction is logged and attributable.
Censorship and Account Freezing
Custodial providers can freeze or close accounts at their discretion or under regulatory pressure. Users in sanctioned jurisdictions, politically sensitive regions, or flagged by automated compliance systems may find their funds inaccessible. This reintroduces the very censorship risks that Bitcoin's censorship resistance was designed to prevent.
Single Point of Failure
If a custodial Lightning provider goes offline, all users lose access to their funds simultaneously. Self-custodial Lightning users can at least force-close their channels and recover funds on-chain. Custodial users have no such fallback. The provider's uptime, security, and operational competence become the single point of failure for every user on the platform.
Non-Custodial Alternatives
The Bitcoin ecosystem has developed several approaches that aim to provide custodial-level simplicity without surrendering key control:
- LSP-assisted wallets: services like Phoenix and Breez use Lightning Service Providers to manage channels and liquidity while the user retains their keys and the ability to force-close channels
- Federated custody: Fedimint distributes trust across a federation of guardians, so no single party can steal funds, though users still depend on federation honesty
- Spark: a Bitcoin Layer 2 that eliminates channels entirely. Users hold their own keys via threshold signatures and can unilaterally exit to the Bitcoin base layer at any time. No channel management, no inbound liquidity concerns, and no custodial trust assumptions. See the Spark deep dive for technical details
These solutions represent the direction the ecosystem is moving: preserving the ease of use that made custodial Lightning popular while eliminating the counterparty risk that makes it dangerous.
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.