Lightning Mobile Wallets: Architecture and Implementation Patterns

Lightning mobile wallets face a fundamental tension: the Lightning Network was designed for always-on nodes with persistent connections, but mobile devices are constrained environments with aggressive power management, limited background execution, and intermittent connectivity. Every wallet that ships Lightning on mobile must navigate this mismatch, and the architectural choices they make determine the tradeoffs users inherit.

This article examines how leading Lightning mobile wallets solve these challenges, the role of Lightning Service Providers in making mobile Lightning viable, and the platform-specific constraints that shape wallet design on iOS and Android. Understanding these patterns matters for developers building payment applications and for users evaluating which wallet trust model fits their needs.

Why Mobile Lightning Is Hard

A Lightning node must perform several tasks that conflict with how mobile operating systems manage resources. The node needs to maintain persistent TCP connections to channel peers, monitor the blockchain for force-close transactions, respond to HTLC forwarding requests, and store a growing set of revoked channel states. Each of these requirements clashes with at least one mobile platform constraint.

Background Execution Limits

iOS gives apps roughly 30 seconds of background execution time via beginBackgroundTask before suspending them. Background App Refresh tasks (BGAppRefreshTask) also receive approximately 30 seconds but are scheduled at the system's discretion. Processing tasks (BGProcessingTask) can run for several minutes, but iOS typically delivers them overnight when the device is charging and idle. Silent push notifications grant another 30-second window, but iOS throttles delivery based on battery level and device state.

Android's Doze mode activates when the device is unplugged, stationary, and the screen is off. In Doze, the system blocks network access, ignores wakelocks, and defers alarms, sync adapters, and job scheduler tasks. Periodic maintenance windows allow brief execution, but an app cannot rely on continuous connectivity. Foreground services can keep a node running (Zeus uses this approach), though device manufacturers often impose additional restrictions beyond stock Android behavior.

Channel State Storage

Under the current penalty-based Lightning channel protocol, a node must retain every revoked channel state it has seen. This is O(n) storage that grows with each payment. Losing this data is dangerous: if a counterparty broadcasts an old state and the wallet cannot produce the corresponding justice transaction, the user loses all funds in that channel.

The proposed eltoo protocol (also called LN-Symmetry) would reduce this to O(1) storage by allowing any later state to invalidate any earlier state. However, eltoo requires a new sighash flag (SIGHASH_ANYPREVOUT) that has not been activated on Bitcoin.

Online Requirement for Receiving

Standard Lightning requires the recipient to be online when a payment arrives. The sender constructs an onion-routed path to the recipient, and the final hop must be completed by the recipient's node. If the node is offline (which is the default state for a mobile app not in the foreground), the payment fails. This creates a poor user experience compared to on-chain Bitcoin, where funds arrive regardless of whether the recipient's wallet is running.

The core tension: Lightning assumes always-on participants. Mobile operating systems assume apps should be suspended when not in use. Every mobile Lightning wallet is a workaround for this mismatch.

The Role of Lightning Service Providers

Lightning Service Providers (LSPs) are the bridge between Lightning's always-on requirements and mobile's constrained execution model. An LSP is a well-connected Lightning node that provides services to mobile wallets: opening channels, providing inbound liquidity, routing payments, and monitoring for channel breaches. Without LSPs, self-custodial Lightning on mobile would be impractical for most users.

What LSPs Provide

• Channel opens with pre-allocated inbound liquidity so users can receive payments immediately
• Zero-confirmation channels for instant onboarding without waiting for block confirmations
• Payment routing when the user's node is behind NAT or on a mobile network
• Watchtower services to monitor for channel breaches while the mobile app is suspended
• Wrapped invoices that hide the user's node public key for privacy
• Channel lifecycle management including splicing and rebalancing

Trust Model

LSPs in the Lightning model are non-custodial: the user holds their own keys, and the LSP cannot unilaterally spend channel funds. However, the relationship introduces dependencies. The LSP controls channel opens and closures, can see payment metadata (amounts and timing), and its uptime directly determines whether the user can send or receive. Most mobile wallets connect to a single LSP, creating a single point of failure for Lightning connectivity.

Zero-confirmation channels add a specific trust assumption: the user trusts that the LSP will not double-spend the channel funding transaction before it confirms. After confirmation, the trust model reverts to standard Lightning security.

LSP Standardization

The LSPS specification effort aims to standardize wallet-to-LSP communication. LSPS0 defines the transport layer using JSON-RPC over BOLT8 peer messages. LSPS1 covers channel request protocols. LSPS2 specifies JIT (just-in-time) channel negotiation, where channels are opened on demand when a payment arrives. Proposed extensions (LSPS3 through LSPS5) address flow control, channel lifecycle events, and webhook notifications. The goal is to let wallets switch between LSPs without code changes, reducing vendor lock-in.

Wallet Architecture Comparison

Three wallets illustrate the range of architectural approaches to mobile Lightning: Phoenix (single-LSP with splicing), Zeus (embedded node with graduated custody), and Breez (SDK-based with a recent pivot away from Lightning channels entirely).

Phoenix: Single Dynamic Channel

Phoenix, built by ACINQ, uses lightning-kmp, a Kotlin Multiplatform Lightning implementation optimized specifically for mobile. The defining architectural choice is a single dynamic channel per user that resizes via splicing. Instead of opening new channels when capacity is needed, Phoenix splices funds in and out of a single channel. This means one UTXO per user on-chain, eliminating the liquidity fragmentation that plagues multi-channel setups.

When an incoming payment exceeds available inbound liquidity, Phoenix initiates a splice-in to expand the channel. Outbound on-chain payments use splice-out, sending directly from the channel without needing a separate on-chain wallet. In 2025, Phoenix introduced taproot channel support, reducing on-chain costs by roughly 20% and making the channel's on-chain footprint indistinguishable from a standard Taproot payment (unless force-closed).

The tradeoff is complete dependency on ACINQ as the sole LSP. ACINQ provides the channel counterparty, watchtower monitoring, and encrypted static channel backup storage. If ACINQ becomes unavailable, the user must force-close their channel and wait for the timelock to expire. Phoenix also charges a 0.4% fee on outgoing Lightning payments.

Phoenix was removed from US app stores in May 2024 following the Samourai Wallet indictment, then returned in April 2025 after the DOJ issued guidance on prosecution policy. This episode highlighted the regulatory risk that LSP-dependent wallets face: a legal threat to the LSP operator can disrupt service for all users.

Zeus: Embedded Node with Graduated Custody

Zeus v13 replaced its embedded LND node with LDK Node (maintained by Spiral) as the default backend. LDK provides a lighter footprint while maintaining the same self-custodial properties. Zeus is the largest mobile wallet to ship LDK Node in production.

Zeus introduced a graduated wallet model. New users start in "Mortal" tier with Cashu ecash for frictionless onboarding and an immediate Lightning address. As balances grow, users are prompted to upgrade to "God" tier with a full self-custodial embedded node. "Olympian" tier serves sovereign node runners managing their own infrastructure. This graduated approach acknowledges that the complexity cost of running a full Lightning node on mobile is not worth paying for small balances.

On Android, Zeus runs a persistent foreground service that keeps the node active even when the app is closed. This is the most aggressive approach to the background execution problem: the node maintains connections, monitors channels, and can receive payments while backgrounded. On iOS, this approach is not available due to Apple's restrictions on persistent background connections, making Zeus significantly less capable on iPhone.

Zeus operates its own LSP, OLYMPUS, which provides zero-conf channels and wrapped invoices. Channel fees are 10,000 sats for channels under 1 million sats, or 1% for larger channels. OLYMPUS has been integrated into other projects including Alby Hub.

Breez: From Lightning Nodes to Liquid Swaps

Breez's architectural evolution illustrates the industry's trajectory. The original Breez wallet ran a full LND node on mobile. The second generation, Breez SDK Greenlight, used Blockstream's Greenlight service to run CLN (Core Lightning) nodes in the cloud on behalf of users. Over 75 apps integrated this SDK, including Deblock and Klever, though some integrators found it "good enough for developers but still lacking for users."

Breez deprecated the Greenlight SDK in favor of a radically different approach: the Nodeless SDK, which eliminates Lightning nodes entirely. Users hold funds as L-BTC on the Liquid sidechain. Sending a Lightning payment triggers a submarine swap from L-BTC to Lightning sats via Boltz. Receiving reverses the swap. No channels, no LSP, no channel state to manage.

The reference wallet Misty Breez, launched April 2025, supports BOLT 11, BOLT 12, LNURL-Pay, Lightning Addresses, and BIP 353. For offline receiving, Misty Breez uses a webhook-based notification delivery service: when a payment arrives, a webhook triggers a push notification that wakes the app to complete the swap.

The tradeoff is trust model: funds are held on Liquid, a federated sidechain operated by a consortium of functionaries. This is not equivalent to holding Bitcoin in a Lightning channel where exit is enforced by Bitcoin consensus. Breez has also announced an Ark-based SDK and a Spark-based SDK in partnership with Lightspark, reflecting a strategy of supporting multiple Layer 2 backends.

Platform-Specific Implementation Challenges

iOS and Android impose different constraints on Lightning wallet implementations, and these differences have material impact on what architectures are viable on each platform.

The practical effect: wallets that run embedded nodes (Zeus, the original Breez) work significantly better on Android. On iOS, every wallet is forced toward LSP-dependent designs where the LSP holds payments, monitors channels, and handles operations the mobile app cannot perform while suspended. This is not a wallet design choice: it is an operating system constraint that narrows the viable design space.

iOS forces centralization: Apple's background execution limits make it impossible to run a fully autonomous Lightning node on iPhone. Every iOS Lightning wallet depends on a server-side component (LSP, swap service, or custodian) to function. The self-custody spectrum is constrained by platform policy before any wallet code is written.

Background Operation Patterns

Four patterns have emerged for handling Lightning operations when the mobile app is not in the foreground.

Pattern 1: LSP Payment Holding

The LSP intercepts incoming payments and holds them until the recipient's device comes online. Phoenix uses this approach: ACINQ holds the HTLC and waits for the user to open the app. If the user does not come online before the HTLC timeout, the payment fails and the sender receives funds back. This works reliably but couples receiving entirely to a single LSP's availability.

Pattern 2: Webhook + Push Notification

The wallet registers a webhook with a notification delivery service. When a payment arrives, the webhook fires a push notification that wakes the app briefly to process the payment. Breez's Nodeless SDK uses this pattern. The notification wakes the app, the Notification Plugin completes the submarine swap, and the app returns to suspended state. This depends on push notification reliability, which varies by platform and device configuration.

Pattern 3: Persistent Foreground Service

Android-only. The wallet runs a persistent foreground service that keeps the Lightning node active continuously. Zeus uses this to maintain peer connections and receive payments while backgrounded. The user sees a persistent notification indicating the service is running. Some Android manufacturers (Xiaomi, Samsung, Huawei) aggressively kill foreground services despite stock Android protecting them, creating inconsistent behavior across devices.

Pattern 4: No Background Operation

The wallet only operates when in the foreground. Channel management, payment receipt, and breach monitoring are deferred to the next time the user opens the app. This is the simplest approach but the most risky: if a counterparty publishes a revoked state while the app is inactive and no watchtower is watching, the user may lose funds after the timelock expires (typically 144 blocks, roughly one day).

The Watchtower Problem on Mobile

Watchtowers exist to solve a specific problem: a mobile user who is offline when their channel counterparty attempts to cheat by broadcasting a revoked state. The watchtower monitors the blockchain and broadcasts a justice transaction on the user's behalf if a breach is detected.

For each channel state update, the user encrypts a pre-signed justice transaction and sends it to the watchtower. The encryption uses the breaching transaction's ID as the decryption key, so the watchtower can only unlock and broadcast the justice transaction if the specific breach it corresponds to appears on-chain. This preserves some privacy: the watchtower cannot see channel balances until a breach occurs.

In practice, watchtower infrastructure for mobile wallets has three problems. First, there is no standard compensation mechanism, so most watchtowers operate altruistically with no economic incentive to maintain uptime. Second, the user must trust that the watchtower is actually monitoring and will respond in time. Third, the user must send updated state to the watchtower after every channel update, which requires the app to be running.

Phoenix sidesteps this by having ACINQ (the channel counterparty and LSP) serve as the implicit watchtower. Since ACINQ is the only party that could attempt a breach, and ACINQ is also the entity monitoring for breaches, the economic incentive to cheat is low: ACINQ would be defrauding its own users and destroying its business. Zeus relies on external watchtower configuration, which most users never set up.

The Self-Custody Spectrum

Mobile Lightning wallets exist on a spectrum from full self-custody to custodial, with most falling somewhere in between. The term "self-custodial" covers a wide range of trust models.

• Phoenix: user holds keys, but depends on ACINQ for channel operations, watchtower monitoring, and backup storage
• Zeus (God tier): user holds keys and runs their own node, but depends on OLYMPUS LSP for inbound liquidity and channel opens
• Zeus (Mortal tier): ecash on a Cashu mint, which is custodial by definition
• Breez Nodeless: user holds keys on Liquid, but funds are secured by a federated sidechain rather than Bitcoin consensus
• Wallet of Satoshi (pre-Spark): fully custodial, removed from US app stores in November 2024 due to regulatory concerns

Each step toward better UX tends to move away from pure self-custody. This is not a failure of wallet developers: it reflects genuine constraints imposed by mobile platforms and the Lightning protocol itself.

Industry Trends: Moving Beyond Channels

The broader Lightning wallet ecosystem shows a clear trend: movement away from managing Lightning channels on mobile. Breez deprecated its channel-based SDK in favor of Liquid swaps. Mutiny Wallet shut down entirely in December 2024, citing the difficulty of building user-friendly wallets in a complex technical landscape. BlueWallet sunset its custodial Lightning service in 2023. Exodus ended Lightning support in August 2025.

Meanwhile, the wallets that continue to thrive have adopted strategies that abstract away channel complexity. Phoenix's single dynamic channel with automatic splicing means users never think about channels. Zeus's graduated model starts users on ecash and only introduces channel management for larger balances. Breez abandoned channels altogether.

The infrastructure layer is also evolving. LDK (Lightning Development Kit), maintained by Spiral, provides modular Rust-based Lightning primitives with bindings for Swift, Kotlin, and other languages. Its design is runtime-agnostic: data persistence, chain interactions, and networking can be customized for mobile constraints. Zeus v13's adoption of LDK Node validates this approach, though the fundamental mobile platform limitations remain regardless of which Lightning implementation is used.

How Spark Simplifies the Mobile Experience

Spark takes a fundamentally different approach to mobile Bitcoin payments, one that sidesteps the architectural challenges described above. Because Spark uses a statechain-based model rather than payment channels, many of the problems that make mobile Lightning difficult simply do not exist.

No Channels, No Channel State

Spark transfers work by changing who can authorize spending a Bitcoin UTXO, not by routing payments through a network of channels. There is no channel state to persist, no revoked states to store, and no risk of losing funds due to a corrupted local database. A user's Spark balance is represented by leaves in a tree structure, and transfers involve the Spark operators generating new keys for the recipient while destroying old key shares. The mobile wallet does not need to maintain persistent connections to preserve security.

No LSP Dependency

Lightning mobile wallets depend on an LSP for inbound liquidity, channel management, and often watchtower monitoring. Spark eliminates this entire dependency. There is no channel capacity to manage, no inbound liquidity to provision, and no channel opens or closes to coordinate. The Spark operators facilitate transfers using FROST threshold signatures, but their role is limited to the moment of transfer: once a transfer completes and old keys are deleted, operators cannot affect the transaction even if later compromised.

Offline Receiving

Spark users can receive payments while offline. Spark Service Providers (SSPs) hold incoming payments conditionally until the recipient comes online. If the recipient does not come online before a timeout, the payment returns to the sender. This is similar to Phoenix's LSP holding pattern but without requiring the recipient to have a channel, maintain channel state, or run any background processes.

No Watchtower Concerns

Spark operators serve as built-in watchtowers, monitoring the blockchain for fraudulent exit attempts by previous owners. Unlike Lightning watchtowers, Spark exit transactions are not "toxic": multiple parties can broadcast simultaneously, and the valid transaction with the lowest timelock wins. The user does not need to configure external watchtowers, trust altruistic operators, or worry about missing a breach window while their phone is in a drawer.

Recovery

Recovering a Lightning wallet after losing a device often involves force-closing channels (incurring on-chain fees and timelocks), hoping the LSP stored encrypted backups, or losing channel funds entirely if backups were not maintained. Spark wallet recovery is straightforward: the user's key material is sufficient to restore access. There are no channels to close, no pending HTLCs to resolve, and no channel state databases to reconstruct.

A different design space: Spark does not solve Lightning's mobile problems. It avoids them by not using channels. The tradeoff is a 1-of-n trust assumption on operators during transfers, but the mobile experience is dramatically simpler: no LSP lock-in, no background watchtower requirements, no channel state to persist, and no force-close risk from an idle device.

Wallets building on Spark, including General Bread, can focus on user experience rather than channel plumbing. Spark also maintains native Lightning compatibility: users can send and receive Lightning payments through SSPs without managing channels themselves. For developers interested in building mobile wallets on Spark, the Spark SDK documentation covers integration patterns, and our wallet SDK comparison provides context on how Spark compares to other development frameworks.

Conclusion

Lightning mobile wallets have made remarkable engineering progress, but the fundamental mismatch between always-on protocol requirements and mobile platform constraints persists. Every wallet must choose where to sit on the spectrum between user experience and self-custody purity, and every choice involves real tradeoffs in trust, reliability, and platform compatibility.

The trend toward channel abstraction (Phoenix's splicing, Breez's Liquid pivot, Zeus's graduated model) reflects a collective recognition that exposing channel mechanics to mobile users does not work. The next generation of mobile Bitcoin wallets may not use channels at all, opting for statechain-based systems like Spark, federated protocols like Fedimint, or Ark-style virtual UTXOs. The common thread: keeping the user's phone out of the consensus loop.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.