The short version
- Sub-cent fees, sub-minute settlement. Lightning is the fastest, cheapest BTC settlement layer for swap-sized amounts.
- Better privacy than on-chain BTC for free. Multi-hop routing obscures the sender-receiver path.
- Practical size limit ~$5–10k. Above that, on-chain is more reliable.
- The send experience is paying a normal Lightning invoice. No new mental model required.
How Lightning works, briefly
The Bitcoin base layer can process about 7 transactions per second worldwide. That is not enough for a global payment system. Lightning solves the problem with a layer-2 architecture: pairs of users open channels by jointly funding a 2-of-2 multisig output on-chain; thereafter, they can exchange BTC inside that channel by signing channel-state updates that never hit the chain. When the channel closes, the final state settles to the chain.
Routing across the network is via multi-hop forwarding: if Alice has a channel with Bob and Bob has a channel with Carol, Alice can pay Carol by sending through Bob (Bob keeps a small routing fee for the hop). The cryptography ensures Bob cannot steal mid-route. This generalises to arbitrary path lengths.
The result is a payment network with sub-second finality, sub-cent fees, and a different privacy model than on-chain Bitcoin — channels are not visible on-chain until they close, and routing obscures the end-to-end path.
Wallet setup
Pick a self-custody Lightning wallet that fits your use case:
- Phoenix (iOS, Android). Best mobile UX. Uses a single channel to an embedded Lightning Service Provider (LSP); receive capacity is managed automatically.
- Zeus (iOS, Android, desktop). The most flexible client. Connects to your own LND/Core Lightning node remotely, or to a public node, or to embedded nodes. The right pick if you run your own node.
- Blixt Wallet (Android). Open-source, embedded node. Strong privacy posture.
- Breez (iOS, Android). Embedded LSP, podcast-streaming integration. Good for users coming from BlueWallet.
- BlueWallet Lightning. Easier to start with but the Lightning side is custodial — you trust BlueWallet's LSP. For privacy-serious use, prefer one of the above.
Funding the wallet
You fund a Lightning wallet by sending on-chain BTC to it, which the wallet uses to open a channel. The source of that on-chain BTC matters — if it comes from a KYC'd exchange, your Lightning channel is linked to that identity on-chain at the channel-funding step. For privacy-sensitive use:
- Fund the wallet from a self-custody on-chain wallet that has previously been cycled (received from multiple sources, mixed UTXOs).
- Alternatively, fund via a swap of a non-BTC asset into Lightning BTC — the source asset's chain analysis story does not carry forward to the Lightning channel.
The swap flow
A Lightning-source swap is mechanically simple from the user's perspective:
- Open the widget with Lightning as the send asset. See /coins/bitcoin-lightning/ for the dedicated page, or pick BTC-LN from the asset picker.
- Pick the destination asset. Any of our 1,000+ supported coins. Common destinations: XMR, USDT, on-chain BTC.
- Paste the destination wallet address.
- The widget displays a Lightning invoice. Copy or scan it.
- Pay the invoice from your Lightning wallet. One tap; settles in seconds.
- Receive the destination asset. Median total time: under 2 minutes.
The reverse — non-Lightning to Lightning
Receiving Lightning BTC via a swap is equally straightforward:
- Open the widget with any source asset (BTC on-chain, USDT, ETH, etc.) and Lightning as the destination.
- Generate a Lightning invoice in your wallet for the receive amount. The widget will display the exact amount needed including the platform fee.
- Paste the invoice as the destination address.
- Send the source asset. After confirmation, the aggregator pays the Lightning invoice and you receive BTC-LN in your wallet.
The Lightning privacy story
Lightning has a more favourable privacy profile than on-chain Bitcoin for swap-sized amounts. The reasons:
- Channel state is private. Until a channel closes, the balances and individual payments inside it are not visible on-chain. An observer sees the opening funding transaction and (eventually) the closing transaction; the activity between is opaque.
- Routing obscures sender and receiver. A multi-hop payment looks similar to any intermediate node — they see the previous and next hop, not the endpoints. Onion routing is built into the protocol.
- Invoice metadata is minimal. A Lightning invoice contains the amount, an optional description, and a payment hash. No identity, no address chain.
The caveats:
- Channel funding is on-chain and observable. Your channel open is forensically linked to the on-chain source.
- Probing. A determined observer running multiple Lightning nodes can probe other channels for balance information by attempting payments. Privacy improvements here are an active research area.
- Service-side correlation. A swap service that processes both your Lightning invoice and your destination address obviously sees both — same trust model as any aggregator.
Channel hygiene
The basics:
- Fund channels from clean sources. The on-chain channel-open transaction binds your channel to whatever source funded it.
- Separate compartments use separate channels. Mixing a personal-spending channel with a privacy-swap channel reduces both compartments' privacy.
- Prefer wallets with embedded LSPs you can verify. A custodial Lightning service can correlate your activity. Phoenix's LSP is operated by ACINQ; review their privacy posture if it matters to you.
- Run your own node when feasible. Self-hosted nodes do not phone home with your channel activity.
Related routes and reading
- BTC-LN → XMR swap page
- BTC-LN → BTC on-chain swap page
- BTC on-chain → BTC-LN swap page
- Bitcoin Lightning — coin overview
- Bitcoin to Monero swap guide
- Wallet hygiene for privacy swaps