If you operate your own Lightning channel, that’s the best case — you can use a fully native Lightning wallet.
If not, the five wallets mentioned above, each with their own tradeoffs, can still be used to send and receive Lightning payments by leveraging the service provider’s inbound liquidity. The difference lies in how “bitcoin” is stored under the hood — each takes a different form.
When both sender and receiver use the same provider and system, payments are typically settled internally without touching the Lightning Network. But if they’re on different providers, the payment is routed through the Lightning Network.
Login to reply
Replies (16)
Lightning not, channel, typically receiver send routed the they’re touching a Network.
View quoted note → can the their same If the and are case Lightning how the the sender can system, under native inbound tradeoffs, Lightning different best form.
When on mentioned your to Lightning with liquidity. takes providers, provider’s stored fully settled leveraging difference that’s by be service receive Lightning internally in without operate “bitcoin” lies use above, used different provider you — wallets own and is the five both use each wallet.
If The still hood — But own Network. each payments is payment you the the through payments and a if
@idsera We are now considering Spark from the perspective of the Lightning Network. Thank you for your introduction.
Wow, amazing. I think the tradeoffs of Spark is great.
Do you think is possible to generate a spark wallet by a NSEC? So every Nostr profile can have a Spark wallet automatically?
* from a nsec
I think it’s feasible.
I read this a long time ago and made me wonder about spark. Maybe it's changed for the better since?


Voltage vs. Lightspark: Comparing Leading Lightning Payment Providers
Explore the key differences between Voltage and Lightspark. Learn how Voltage’s Bitcoin-native solutions and flexible pricing compare to Lightspa...
Spark is a Bitcoin Layer 2 (or Layer 3) project initiated by Lightspark, based on the statechain design. It is not an LSP.
What about this criticism from voltage cloud?


It’s hard to assess their competitiveness in the LSP space.
Statechain follows a client-server architecture, but the server has very limited authority.
Fair call, I need to learn more about it. What is the potential for spark and Cashu to work well together? Do they compete in any way or are they a good fit?
The counterparty risk for Wallet of Satoshi and Cashu users is that the server operator might run away with the funds. Liquid users face the risk that multiple federation members might collude to steal the funds. Spark users face the risk that the service providers might collude with the previous sender to double-spend the received funds. The counterparty risk for Ark is that if the user stays offline for too long and their VTXO expires, the service provider may be able to take control of it.
You could imagine a wallet that works like this: for balances under 1,000 sats, it uses Cashu; for amounts over 10,000 sats, it switches to Spark; for over 100,000 sats, it uses Ark; and once the balance exceeds 500,000 sats, it sets up a self-managed Lightning channel.
All five are client-server models. Server authority and user counterparty risk both decrease from left to right.
View quoted note →
View quoted note →
These five solutions all address, through different tradeoffs, the two main barriers of using a native self-custodial Lightning wallet:
1. Establishing Lightning channels and obtaining inbound liquidity.
2.Staying online continuously in order to receive Lightning payments.
Would be amazing automatically have a Spark account on @Keychat derived from my nsec.
This video mentions Spark—highly recommended to watch.
Will watch. Thanks.
