Today, it's possible to have a user experience very close to that of a Lightning custodial wallet, while remaining in self-custody. The aim of this chapter is to help you choose the path best suited to your profile.

The first solution is simply not to use Lightning natively, but to use a Bitcoin or Liquid wallet that embeds atomic swaps. For example, Aqua or Bull Bitcoin Wallet applications use this method, by enabling you to pay Lightning invoices without operating a Lightning node yourself, while remaining in self-custody.

The principle is straightforward: your funds stay in Bitcoin, either on-chain or on Liquid, and you access them through a wallet where you hold the keys in the traditional manner. When you scan a Lightning invoice, your wallet initiates a transaction (on-chain or Liquid) to an atomic swap service. This service then manages the Lightning payment through its own node, using the bitcoins you provided on-chain or via Liquid. As a result, you don't have to handle any Lightning channels yourself, yet you can still settle Lightning invoices seamlessly.

The major advantage of this approach, compared with a conventional Lightning custodial wallet, is that you remain in 100% possession of your funds at all times. The bitcoins are in your onchain or Liquid wallet, with your own mnemonic phrase. Even during the swap, you remain in possession of your funds, because the swap is atomic. It relies on a cryptographic mechanism that ensures there are only two possible outcomes: either the swap succeeds entirely, or it fails and the service cannot appropriate your funds.

Most wallets offering this type of functionality rely on Boltz for the technical part of the swap.

This solution also offers interesting advantages in terms of confidentiality, especially when coupled with Liquid. For a beginner, it's also very easy to set up and save: a classic mnemonic phrase, no channels, no liquidity to balance...

On the other hand, this approach has its limitations. Firstly, it's not incensurable: you depend on the availability and goodwill of the swap service. If it no longer wishes to process your account, or ceases to operate, you can no longer pay Lightning invoices through it. Then there are the not inconsiderable fees: you pay both the onchain or Liquid transaction fees, and the swap service commission. Also, if onchain fees rise sharply, it can become very expensive to use Lightning.

So for occasional use, it's still acceptable, but for a very active Lightning user, it's better to do things right with a real Lightning node.

The second category of solutions is based on Lightning nodes embedded directly in a mobile application. Phoenix Wallet pioneered this model and remains a benchmark. Today, other projects offer comparable approaches, such as Zeus (in embedded mode) or BitKit.

The idea is simple: the application actually runs a Lightning node, but all the complex operations are handled automatically in the background. You have a "Lightning wallet" interface with a mnemonic phrase for backup, you see a balance and pay invoices, but you don't manage channels, liquidity or most parameters.

These solutions are always self-custodial. The keys that control the funds are generated and stored on your phone, and backup is via a seed or equivalent mechanism. You don't simply hold an account with a service provider, you actually own bitcoins locked in channels that belong to you and can't be stolen.

The advantages of LN on-board nodes are numerous:

But these embedded wallets also have significant limitations. Firstly, in terms of confidentiality, the service operator (e.g. ACINQ in the case of Phoenix) has a fairly detailed view of the flows passing through your node: amounts, frequencies, recipients, even if this is bound to improve, particularly with the gradual adoption of Trampoline Nodes. Secondly, you are heavily dependent on this operator as your main Lightning peer. If the ACINQ node becomes unavailable (in the case of Phoenix), if the company comes under regulatory pressure or changes its business model, your user experience may be severely degraded, or even compromised.

Finally, this simplicity comes at a price. Embedded LN node services generally charge specific fees on deposits, withdrawals or certain channel management operations. In my opinion, this model makes sense in terms of the service offered, but for intensive use, it can be much more expensive than a well-managed conventional Lightning node.

The third solution, the one we'll be looking at in greater depth in this LNP202 course, is to operate a conventional Lightning node on a dedicated server or device.

By "classic" I mean that you install and configure a Lightning implementation (e.g. LND) yourself on top of your own Bitcoin node. You choose your peers, open your channels, manage your inbound and outbound liquidity, and set your routing fee policies.

In terms of sovereignty, it's the best solution. You are no longer dependent on a specific company for your channels or payments: if a peer censors you or closes a channel, you can open another with a different node. If a service disappears, your sats remain in the channels you control, and you can repatriate them onchain. You can also optimize your long-term costs: once your channels are correctly sized and managed, the overall cost of payments can become very low.

In terms of confidentiality, you're obviously subject to the limitations of Lightning's own model, but you're not handing over your entire business to a single operator.

By contrast, setting up a classic Lightning node is obviously more complex: you have to install, configure, maintain, monitor updates, understand the logic of channels and charge policies, manage channels and cash flow, and so on. Misconfiguration, sloppy backup or careless management can more easily lead to the loss of sats. The node must also run continuously.

This is precisely the path I propose you follow in this course, accompanying you every step of the way to limit risks and structure your approach.

To choose the right solution for your Lightning user profile, you need to consider two factors: how often you use Lightning, and your appetite for technical management.

If you don't make many Lightning payments on an occasional basis, but still want to be able to settle LN invoices from your phone from time to time, without giving up self-custody: a Bitcoin or Liquid wallet with swap functionality is probably the best option. You retain ownership of your funds, manage no nodes, and accept slightly higher fees in exchange for simplicity.

If you use Lightning on a fairly regular basis and want the benefits of a real node, but don't want to spend time managing channels, fees or infrastructure, a mobile embedded Lightning node is a good solution. You retain custody of your funds, the UX remains very accessible, and all the complexity is hidden, at the price of a marked dependence on an operator.

If you're an intermediate or advanced user, willing to invest time in understanding and managing your infrastructure, and want maximum control over your channels, liquidity and costs: a classic server-based Lightning node is the way to go. It's the most demanding solution, but also the most consistent with Bitcoin's idea of sovereignty.