Lightning Mobile Wallets: Architecture and Implementation Patterns | Spark

Contents

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.<br>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.<br>Why Mobile Lightning Is Hard<br>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.<br>Background Execution Limits<br>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.<br>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.<br>Channel State Storage<br>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.<br>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.<br>Online Requirement for Receiving<br>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.<br>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.<br>The Role of Lightning Service Providers<br>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.<br>What LSPs Provide<br>Channel opens with pre-allocated inbound liquidity so users can receive payments immediately<br>Zero-confirmation channels for instant onboarding without waiting for block confirmations<br>Payment routing when the user's node is behind NAT or on a mobile network<br>Watchtower services to monitor for channel breaches while the mobile app is suspended<br>Wrapped invoices that hide the user's node public key for privacy<br>Channel lifecycle management including splicing and rebalancing<br>Trust Model<br>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...