A Lightning wallet's type is defined by where the channel keys live, who manages liquidity, and how the wallet resolves incoming payments. Custodial wallets (Wallet of Satoshi, Strike) hold funds and channels on the user's behalf. Self-custodial wallets split into LSP-backed channel management (Phoenix, Breez), user-managed remote-node control (Zeus), and hybrid submarine-swap designs (Muun). The right type matches the user's balance size, technical comfort, and jurisdiction (source: Lightning Network; Lightning BOLTs; Bitcoin.org).
Which Lightning wallet type fits which user in 2026
Custodial Lightning wallets fit beginners who want a zero-configuration payment app for small day-to-day balances. Self-custodial LSP-backed wallets fit users who want to keep keys without running infrastructure. User-managed node wallets fit power users who already run a node. Submarine-swap hybrids fit users who think on-chain first and want Lightning as a convenience layer.
The four types in order:
Custodial (Wallet of Satoshi, Strike, Cash App): simplest, highest counterparty trust.
Self-custodial LSP-backed (Phoenix, Breez): user holds keys; LSP opens channels and handles inbound capacity.
User-managed node (Zeus, Blixt, Alby Hub): user runs their own LND or Core Lightning node; the wallet is a UI over it.
Hybrid submarine-swap (Muun): single-balance UI that routes on-chain and Lightning through different mechanisms under the hood.
Each tier trades one friction for another. Lower operational friction means higher trust friction; higher sovereignty means the user carries more backup, liquidity, and recovery work.
How custody, channels, and liquidity define wallet type
Every Lightning wallet answers three structural questions: who holds the private keys that can unilaterally close a channel, who opens and manages channels, and who sources inbound liquidity so incoming payments can land. The combination of answers is the wallet's type.
Lightning channels are two-of-two multisig Bitcoin outputs whose balances update off-chain via signed commitment transactions (source: GitHub). Custodial wallets keep the channel keys on a service's servers; self-custodial wallets keep them on the user's device. Inbound capacity is the separate constraint: a channel's balance sits on one side or the other, and an incoming payment can only land if the counterparty has room to forward onto the user's side. This is why first-time Phoenix or Breez users have an onboarding step that custodial wallets never need.
Dimension | Custodial | Self-custodial LSP-backed | User-managed node | Submarine-swap hybrid |
|---|---|---|---|---|
Channel keys | Provider | User device | User's own node | User device |
Channel management | Provider | LSP (ACINQ, Blockstream) | User | User + automated swap |
Inbound capacity | Abstracted | LSP opens / splices on demand | User opens or buys | On-chain address, swapped to LN |
Backup responsibility | None (provider holds) | Seed + static channel backup | Full node backup | Seed phrase |
Example | Wallet of Satoshi | Phoenix | Zeus | Muun |
Tracing a 50,000-sat incoming invoice clarifies the split. In a custodial wallet, the provider's pooled channels receive the HTLC and the user's in-app balance ticks up in the provider's database. In an LSP-backed wallet, the user's device has a channel to the LSP (ACINQ for Phoenix, Greenlight or Spark for Breez-SDK), which routes the HTLC onto the user's channel or splices in capacity at an on-chain fee. In a user-managed node setup, the user's own node is on the public graph with its own channels, and the mobile wallet (Zeus) is a remote-control UI signing via macaroons. In a submarine-swap hybrid, Muun runs a backend swap that claims a short-lived on-chain HTLC and credits the user's balance.
For the protocol-level mechanics behind this flow, see how a lightning payment works. For the channel primitives themselves, see lightning channels.
Custodial Lightning wallets: Simplest UX, highest counterparty trust
Custodial Lightning wallets hide the network entirely. The user sees an app balance, pays invoices by pasting them, and receives at a static username-style address. The provider holds keys and runs all channel and liquidity work; the balance is effectively an IOU from the provider.
Wallet of Satoshi has been the canonical example, reportedly processing a majority of retail Lightning payment volume during 2023-2024. The tradeoff showed up twice. In late 2023 it pulled from US app stores; existing US users kept access but new signups stopped (source: Cryptoslate). In early 2026 it wound down its EU custodial service under the Markets in Crypto-Assets (MiCA) licensing regime, migrating affected users to a self-custodial Spark-based build (source: CryptoTimes; The Rage). EU users cannot create new custodial invoices; existing balances remain withdrawable.
Strike is US-regulated, dollar-denominated, and uses Lightning as a settlement rail for fiat-to-BTC and cross-border remittances. Cash App integrates Lightning into its broader payments app. Both are full custodians: the user trades custody for zero-setup UX.
What custodial risk actually looks like
A provider can freeze individual accounts under a sanctions obligation, suffer an internal incident, or exit a jurisdiction and force a migration window. The Wallet of Satoshi EU wind-down is the cleanest current example: users kept balances, but the service they signed up for changed with no direct equivalent. Custodial Lightning works until regulatory or business circumstances shift, which is rarely predictable from the user side.
From BloFin's exchange-operator perspective, we treat custodial Lightning the same as any off-exchange custodial balance: convenience for payment UX, not a place to park holdings. When we design deposit paths that accept Lightning, we assume the sender's custodial wallet could be frozen, geo-restricted, or in migration at any given moment, and the flow must tolerate that rather than depend on provider continuity.
Custodial wallet | Typical fit | Key risk surface |
|---|---|---|
Wallet of Satoshi | Small-balance spending; pre-2026 EU users on migration path | Account freeze, regional restriction, MiCA wind-down |
Strike | USD-denominated Lightning, remittances, US-compliant flow | Strike platform risk, fiat account link |
Cash App | Existing Cash App users | Single-provider stack, US-only Lightning feature |
For the broader custody framework, see custodial wallet vs self-custody. For the Lightning-specific custody split, see custodial vs non-custodial lightning wallets.
Self-custodial LSP-backed wallets: User holds keys, LSP handles channels
LSP-backed wallets sit in the middle. The user holds the private keys that can unilaterally close a channel, and a dedicated Liquidity Service Provider (LSP) opens channels, sources inbound capacity, and maintains routing paths. The phone becomes a sovereign endpoint without requiring a home-server node.
Phoenix (by ACINQ) is the reference implementation. Every Phoenix wallet has exactly one channel, opened to ACINQ's node. Historically channels were opened at a 1% flat inbound-liquidity fee; since the splicing update, Phoenix runs a single dynamic channel whose capacity grows and shrinks via on-chain splices, with mining fees as the primary liquidity cost and a flat 0.4% fee on outgoing Lightning payments replacing the old 1% inbound model (source: ACINQ; The Block). Users can still request guaranteed inbound capacity at an explicit ~1% service fee. The user can force-close and recover funds on-chain if ACINQ disappears. Phoenix's liveness depends on ACINQ; its custody does not.
Breez took a different bet. The historical Breez SDK-Greenlight variant ran a Core Lightning node in Blockstream's Greenlight cloud per user, with keys on the user's device; a validating signer on the phone had to approve every action the cloud node took (source: Blockstream). That implementation is now deprecated in favor of Breez SDK variants on Spark and Liquid. Twelve partner apps were running the Breez SDK in Q1 2026 across neobanks, Nostr clients, and prediction markets (source: Breez). Misty Breez, the direct-to-user wallet, sits on that SDK.
When LSP-backed is the honest answer
The model works when the user's sovereignty need is "hold my keys" rather than "run my own node." The user cannot be frozen in the custodial sense but is operationally dependent on the LSP staying online. Force-close recovery costs on-chain fees plus a CLTV wait; acceptable as worst case, not a place to live.
Phoenix's splice fees track mempool conditions, so a rebalance during congestion costs meaningfully more than during calm hours. Breez-SDK wallets inherit their fee model from their implementation layer. Self-custodial does not mean fee-free; it means paying for infrastructure explicitly.
For the comparison across rails, see Lightning vs on-chain Bitcoin. For the broader Lightning risk frame, see Lightning Network risk.
User-managed node wallets: Maximum sovereignty, maximum operational load
User-managed node wallets do not hold funds themselves; they are remote-control interfaces over a node the user runs somewhere else. Zeus is the dominant example: an open-source mobile wallet that connects to a remote LND or Core Lightning (CLN) node via hostname, port, and a macaroon capability token for authentication (source: GitHub). Zeus v0.8.0 added an embedded LND mode called OLYMPUS for users without a home server, plus Zeus Pay lightning addresses for receiving under a readable handle.
This tier is for users who already run a Bitcoin node (Umbrel, Start9, myNode, RaspiBlitz, Nodl) or are willing to stand one up. The wallet does not manage channels, source inbound liquidity, or pick routing strategies; the node does, and the user configures it. In exchange, the user gets the only Lightning setup with no third-party dependency once channels are open.
The operational cost is real. Running a Lightning node means keeping it online, making static channel backups, watching the chain for commitment-transaction broadcasts by a misbehaving counterparty, and budgeting on-chain fees for channel opens and closes. A node that is offline when its counterparty force-closes misses the window to respond; watchtower services mitigate this but require configuration.
When the node route is worth it
Three populations: businesses accepting Lightning at scale, power users who want no third-party dependency, and users with balances large enough that the operational cost of running a node is dwarfed by the counterparty risk of trusting an LSP. Everyone else usually does better with an LSP-backed wallet.
From BloFin's deposit-engineering perspective, the consistent pattern is that most retail-volume inbound Lightning traffic comes from custodial or LSP-backed wallets, while node-origin payments are a smaller share but carry significantly larger per-payment values. That distribution fits the tier logic.
For the standalone node question, see should you run a Lightning node. For the broader node-vs-miner-vs-wallet split, see Bitcoin nodes vs miners vs wallets.
Submarine-swap hybrids: Muun and the case for on-chain-first UX
Muun is the outlier. It is self-custodial, but does not open persistent Lightning channels the way Phoenix does. Instead it shows a single balance and uses submarine swaps to bridge on-chain Bitcoin and Lightning transparently (source: Muun). Sending to a Lightning invoice constructs a short-lived on-chain HTLC that a swap provider claims in exchange for routing the equivalent Lightning payment; receiving runs the swap in reverse.
The benefit is conceptual simplicity. A Muun user sees "I have 0.01 BTC," sends to any address or invoice, and the wallet decides under the hood whether on-chain or Lightning rails are used. No channel setup, no inbound capacity onboarding, and the seed phrase alone is enough to recover funds because there are no off-chain channel states that require a static channel backup.
The tradeoff is the on-chain footprint. Every swap touches the base chain in both directions, so Muun payments consume blockspace even when the user experience feels like instant Lightning. During congestion this translates to higher user-facing fees and occasional swap delays. Community discussions have flagged Muun's swap volume as a non-trivial contributor to on-chain fee pressure at peak (source: Stacker).
Muun fits users whose default frame is on-chain-first and who want Lightning as a convenience, or those with smaller balances who prefer a single recovery artifact (the seed) to the more complex custody discipline a channel-backed wallet requires. It is a bad fit for users sending many small payments, because every swap adds on-chain cost compared to a same-size channel-based payment.
Key management and backup: Seed phrase is not the whole story
Lightning backup is subtler than on-chain Bitcoin backup, and users quietly assume more safety than they have. A standard on-chain wallet needs only the seed phrase to recover, because all UTXOs are on the chain and deterministic derivation finds them. A Lightning channel balance is off-chain; the on-chain record shows only the funding transaction, not the current balance. To recover a channel without counterparty cooperation, the wallet needs a static channel backup (SCB): a small state file that lets the wallet request a cooperative close from each peer at the last known state.
Handling varies by type:
Custodial: no user-side backup exists. Recovery is logging back into the provider. If the provider disappears, so does the balance.
LSP-backed (Phoenix, Breez): the user backs up the seed, and the wallet typically stores an encrypted channel state on a remote peer. Seed-only recovery on a new device usually works because the LSP holds the counterparty state and can cooperatively close at the latest state.
User-managed node (Zeus): the user backs up the node's seed AND maintains SCB files. Losing the SCB while the node state is also lost risks channel-balance loss to force-close at a stale state.
Submarine-swap hybrid (Muun): seed phrase is enough, because no persistent channels exist.
Seed-phrase-only recovery is reliable in custodial, LSP-backed, and submarine-swap models. User-managed nodes add a second moving part that must be backed up separately. For the seed-phrase basics, see what is a seed phrase. For the broader storage framework, see how to store bitcoin.
Liquidity sourcing: Inbound capacity across the four types
Inbound liquidity is the Lightning constraint most invisible to beginners. A brand-new wallet cannot receive anything until some hop on the public graph has outbound capacity pointing at it. How each type solves this shapes the fee conversation.
Custodial wallets abstract it away. The provider maintains a large pool of channels and spreads inbound across all users; receiving works immediately, with cost priced into the spread or explicit fees.
LSP-backed wallets expose the problem directly. Phoenix opens the first channel on the user's first incoming payment and splices in more capacity as needed, each splice a user-paid on-chain transaction. A 1,000,000-sat invoice on a fresh install may cost a few thousand sats at low mempool pressure or tens of thousands during congestion.
User-managed node wallets require manual sourcing: open an outbound channel and wait for organic rebalancing, pay a liquidity marketplace (Amboss, Magma, LNBIG) to open a channel toward the node, or run a swap service like Loop In (source: Amboss). A node with no inbound cannot receive any payment; this is the most common new-node failure.
Submarine-swap hybrids sidestep it. Muun's inbound path is the on-chain address, which always receives, and the swap converts to a Lightning balance.
Approach | Typical 2026 cost | Time to usable | Typical fit |
|---|---|---|---|
LSP pay-as-you-go splice (Phoenix) | Mining-fee-based, a few hundred to low thousands of sats | Seconds | Retail users |
LSP guaranteed inbound for a year (Phoenix) | ~1% of the requested amount + mining fee | Seconds | Users expecting steady inbound |
Liquidity marketplace (Amboss/Magma/LNBIG) | 500-2,500 sats per 100k sat (rates vary) | Minutes to hours | Node operators |
Organic rebalancing (open outbound, wait) | On-chain fee only | Days to weeks | Nodes with no hurry |
Loop In / submarine swap | Swap fee + on-chain fee | Minutes | Nodes converting on-chain to channel balance |
Numbers move with mempool congestion and LSP pricing; treat them as ballpark. Lightning inbound is not free, and the user pays somehow regardless of type. For on-chain fee mechanics, see why are Bitcoin fees so high.
2026 network snapshot and wallet state
The public Lightning graph in May 2026 has roughly 6,085 public nodes, 19,992 channels, and 2,919 BTC of total public capacity, median channel capacity around 0.02 BTC, median base fee near 0.39 sat, and median fee rate near 141 ppm (source: 1ML). Those numbers set what each wallet type is routing against.
Wallet-side highlights:
Wallet of Satoshi: US-blocked since late 2023, EU custodial service wound down under MiCA in early 2026, new self-custodial implementation on Spark rolled out for affected users (source: Bitcoinmagazine). Custodial form still operational outside blocked jurisdictions.
Strike: US-regulated, fiat-integrated, still the default Lightning wallet for USD users.
Phoenix: splicing-based single-dynamic-channel model; ACINQ remains sole LSP.
Breez SDK: Greenlight variant deprecated; Spark and Liquid variants current; 12+ partner apps shipped in Q1 2026.
Zeus: v0.8.0+ adds embedded LND (OLYMPUS) and Zeus Pay lightning addresses alongside its remote-node mode for LND and CLN.
Muun: still operational on the submarine-swap model; community sentiment around its on-chain footprint remains mixed.
The custodial-versus-self-custodial split is less about "better" and more about which failure mode the user accepts. Custodial wallets fail to regulations and provider continuity; self-custodial wallets fail to user discipline and LSP uptime. Neither is zero-risk. Matching failure mode to the situation is the decision.
Security: Custodial rug risk, self-custodial operational risk
Security divides along custody lines. Custodial wallets carry classic custodian risk: the provider can be compromised, sanctioned, required to freeze accounts, or wound down under regulatory pressure. Self-custodial wallets carry user-operated risk: seed loss, channel-backup neglect, force-close mistakes, and failure to watch the chain for counterparty misbehavior.
Multiple custodial crypto services have frozen withdrawals or exited regions on short notice, and users who treated custodial balances as equivalent to self-custody have learned otherwise. Lightning-specific custodial failures are rarer because the sector is smaller, but the structural risk is identical. The Wallet of Satoshi US and EU moves are regulatory rather than insolvency-driven; the user-facing impact of service loss is similar.
Self-custodial failure modes: losing the seed phrase and device simultaneously (recovery fails), force-closing at a stale channel state and having an old balance settle (channel balance loss), and running a node offline during a counterparty dispute (timeout loss). Discipline problems rather than attacks, which is why self-custodial Lightning has a quietly higher learning curve than its marketing suggests.
For broader wallet-security framing, see what is a hardware wallet.
How to pick the right Lightning wallet type
The decision has three inputs: balance size, technical comfort, and jurisdiction.
Small spending balance, no technical appetite, non-restricted jurisdiction: a custodial wallet is honest. Wallet of Satoshi (outside US and EU) or Strike (in the US) covers most day-to-day Lightning needs. Keep balances modest; treat it as a payment app, not a vault.
Small-to-medium balance, want to hold keys, not ready to run a node: an LSP-backed wallet like Phoenix or a Breez-SDK wallet is the right tier. The user keeps the seed, LSP does the operational work, fees are visible. This is the largest user group in 2026 and the natural upgrade path from a custodial wallet.
Meaningful balance, already running a home node or willing to: Zeus with a remote LND or CLN backend, or embedded OLYMPUS for users without a home server. Operational load is real but sovereignty is absolute.
On-chain-first framing, smaller spending balance: Muun, if the user accepts the swap mechanics and their on-chain footprint.
Meaningful savings balance: none of the above. Lightning is a payment rail, not a vault. See hot wallet vs cold wallet.
Your situation | Typical 2026 fit | Why |
|---|---|---|
Beginner, small balance, US | Strike | Regulated, US-available, fiat-integrated |
Beginner, small balance, non-US/non-EU | Wallet of Satoshi (custodial) | Easiest UX, still available in-region |
Beginner, small balance, EU post-MiCA | Phoenix or self-custodial WoS migration | Custodial WoS no longer offered in EU |
Intermediate, wants keys, no node | Phoenix or Breez-SDK wallet | LSP model matches the need |
Advanced, running a node | Zeus remote-node mode | Full sovereignty |
On-chain-first user | Muun | Submarine-swap fits the approach |
Long-term holder | Cold storage, not Lightning | Lightning is a payment rail |
FAQ
What is the best Lightning wallet type for a complete beginner in 2026?
For beginners with small balances and no technical appetite, a custodial wallet is usually the honest answer because setup is zero and payment UX is immediate. Strike fits US users, Wallet of Satoshi fits non-US non-EU users, Cash App fits existing Cash App users. EU users post-MiCA should default to a self-custodial wallet like Phoenix because the Wallet of Satoshi custodial product wound down regionally in early 2026. The important caveat is that custodial wallets should be treated as spending tools with modest balances, not places to hold meaningful amounts.
Is Phoenix actually self-custodial if ACINQ runs the only LSP?
Yes at the custody layer, no at the liveness layer. Phoenix keeps the channel's private keys on the user's device, and the user can force-close the channel to recover funds on-chain even if ACINQ disappears. That is what self-custodial means in a Lightning context: unilateral unencumbered exit. What Phoenix is not is infrastructure-independent. If ACINQ's node is offline, the user's Phoenix wallet cannot send or receive until ACINQ comes back or the user force-closes and moves. That is a liveness dependency, not a custody dependency, and the distinction matters when evaluating risk.
Can I lose funds just by losing my seed phrase with a Lightning wallet?
In custodial wallets there is no seed phrase; recovery is via provider login. In LSP-backed and submarine-swap wallets the seed phrase alone is usually enough because the LSP or swap mechanism preserves counterparty state for a cooperative close on seed-only recovery. In user-managed node wallets the seed plus a current static channel backup are both needed; losing the backup while the node state is also lost risks channel-balance loss via force-close at a stale state. This is why user-managed node wallets require more backup discipline than the other types.
Why did Wallet of Satoshi stop working in my country?
Wallet of Satoshi pulled from US app stores in late 2023 without a public legal explanation, and wound down its EU custodial service in early 2026 under the Markets in Crypto-Assets (MiCA) regulation, which requires any custodial crypto service to hold a national license and comply with AML and counter-terrorist-financing rules equivalent to banks. Existing EU users can still withdraw balances; new custodial invoices and accounts are blocked. Affected users are being migrated to a self-custodial Wallet of Satoshi build on Spark. Users outside the US and EU continue to have full custodial access.
Should I keep savings in a Lightning wallet regardless of type?
Usually not. Lightning wallets are payment-optimized, not custody-optimized, across all four types. Custodial Lightning adds counterparty risk; LSP-backed Lightning adds LSP liveness risk plus periodic on-chain transactions; user-managed node Lightning adds node-uptime risk; submarine-swap Lightning adds on-chain footprint per transaction. For meaningful savings, users are better served by cold storage or a hardware wallet, keeping Lightning balances small enough to treat as a working payment balance rather than a store of value.
Does running a Lightning node actually give more privacy than a custodial wallet?
Yes at the transaction-flow level, but Lightning privacy is subtler than on-chain. A node operator's outbound payments are onion-routed so intermediate hops cannot identify the sender; the first hop knows the sender but not the ultimate recipient. Compared to a custodial wallet, the operator is not reporting balance or transaction metadata to a provider, so the provider-level privacy leak is gone. What node operation does not hide is the channel topology, which is public via BOLT 7 gossip, and the operator's IP address unless the node runs over Tor. Strong payment privacy, moderate identity privacy, not absolute.
Are submarine-swap wallets like Muun actually Lightning wallets?
Partly. Muun shows a unified balance and uses submarine swaps to bridge on-chain and Lightning, so the user experiences Lightning payments without operating a Lightning channel. At the mechanism level the wallet is doing on-chain Bitcoin with a swap layer rather than true payment-channel Lightning. That is a legitimate design with tradeoffs: every swap touches the base chain, adding fees and using blockspace. For users who think on-chain first and want Lightning as occasional convenience, the model fits. For users sending many small payments, a channel-based wallet is more efficient per-payment.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. All facts independently verified.
Disclaimer: This content is for educational purposes only and does not constitute financial, investment, legal, or tax advice. Crypto assets are highly volatile and carry significant risk of loss. Always verify local regulations and consult a qualified professional before making financial decisions.