Lightning: why an on-chain wallet cannot simply add it
This is the most common question about Sparrow, and it deserves a real answer rather than a one-word refusal. Lightning is not a feature that a Bitcoin wallet can switch on. It is a different system that settles on Bitcoin, and running it means running infrastructure.
What Lightning actually is
A Lightning payment does not touch the blockchain. Two parties lock funds into a two-of-two channel with one on-chain transaction, and after that they update the balance between themselves privately, as many times as they like, by exchanging signed states. Payments route across chains of these channels, so you can pay someone you have no direct channel with. Only opening and closing the channel are on-chain events. That is what makes it fast and cheap, and it is also what makes it structurally different from everything Sparrow does.
Why "just add Lightning" is not a small ask
Four things stand in the way, and none of them are about effort.
- Channels are not addresses. Money in a channel is not a UTXO you can spend at will; it is a jointly held position with a counterparty who has to cooperate, or be forced on-chain through a timelocked closing procedure.
- Liquidity has to be managed. You can only receive what your channel partners can send toward you. Inbound liquidity is an ongoing operational concern, often a paid one, and it has no equivalent in on-chain wallets.
- It wants to be always on. A node that is offline cannot route, cannot reliably receive, and cannot watch the chain for a counterparty who closes a channel using an old state. A desktop wallet you open twice a week is the wrong shape for that job.
- Backups are nothing like a seed phrase. This is the part that catches people. On-chain, twelve words written on paper recover everything forever. In Lightning, your seed is not sufficient: channel state changes with every payment, and restoring an outdated backup can cost you the channel balance. It requires continuous state backup with completely different semantics.
Bolting that onto a wallet whose entire value proposition is deliberate, auditable on-chain construction would compromise both halves. The project's answer is to do one layer properly.
The realistic 2026 setup
In practice people run both, with a clear division of labour. Lightning node software — self-hosted on a small always-on machine, or a mobile Lightning wallet if you accept the trade-offs — holds a modest spending balance for instant, low-fee payments. Sparrow holds the on-chain reserve underneath it: the savings, the cold storage, the multisig quorum, the coins you are not spending this month.
The two touch at exactly two points. When you fund a channel, you are making an ordinary on-chain payment to a two-of-two output, and Sparrow is a good place to make it from because you can choose which coins to use and see the fee before you sign. When a channel closes, the funds land back on-chain at an address you control, and Sparrow is a good place for them to land. Think of it as a current account and a vault, not as a wallet with a missing tab.