Looking Ahead: Lightning Payments in 2025

The Lightning Network has come a long way since its inception. A wide range of improvements have enabled Lightning payments to work in a nearly seamless manner, but it is not without challenges. Today the user experience may not quite be where we want it, but as builders, we like to frame this as a challenge: what must be done to level up the experience?

In this article, we look at what the experience of using Lightning may look like based on the solutions being developed by many bright minds.

We will first outline today’s user experience and the pain points around it. We will then present a potential future state of Lightning—informed by technologies being implemented or actively developed.

What Are the Problems With Lightning in 2023?

To first address the elephant in the room: a significant proportion of transactions on the Lightning Network today are facilitated by custodial wallets. Using Lightning transactions on Nostr as a rough assessment of custodial use across the network, approximately 90% of transactions are done through applications where the user trusts a custodian with their keys.

Why do most users currently opt for custodial services? People use custodial services because of the convenience, simple user experience, and challenges associated with non-custodial Lightning use. We categorize Lightning’s current challenges into three buckets:

Manual Effort

If users are required to take more actions than through traditional payment methods to achieve a desired outcome, it could lead to a majority of users losing interest. Some examples of that:

• Users must be connected at all times to send and receive payments. Today a major reason that Lightning payments fail is because the recipient is offline, which happens in about 0.5-1% of all Lightning payments
• Users must share invoices with each other out-of-band via text, email, messaging, etc. to make and request payments, which is a cumbersome process.
• Users who operate their own Lightning node must be able to allocate bitcoin across different channels. Opening channels to peers not actively maintaining their node and channels could result in funds being stuck in a limbo state.
  • This is the opportunity cost of capital on Lightning: if your capital is allocated to an unresponsive peer, that capital cannot be used to route other payments (and generate returns).

Technical Expertise

These issues require in-depth knowledge of Lightning and/or interrelated protocols which the average Lightning user will likely not pursue.

• It takes a degree of technical competency to set up a Lightning node. An LN node must always be online to maintain connections with the rest of the network.
  • If a user’s node is offline, there is a risk of bitcoin being lost or stolen.
• A node operator must balance liquidity within their channels; if there are no funds on your side of the channel, you cannot send payments. Conversely, if all funds in the channel are on your side, you cannot receive payments.
• Should a payment fail, or get stuck, a node operator must be comfortable troubleshooting issues via a command line interface.
• Backing up a node is complicated—node operators need to store both their seed and their channel states, or risk having existing channels closed if they lose connectivity.

Technical Deficits

Lightning’s technology isn’t fully developed yet. Some technical problems still need to be solved.

• We do not yet have a standardized user-friendly way to send payments to each other that does not rely on a centralized server.
  • Examples are a unified QR code or paynym-type of experience.
  • LNURL and Lightning addresses are options, although these are workarounds, as they still rely on someone running a server somewhere.
• Since a Lightning node must always be online, the signing keys must also be online (hot). This poses immediate security concerns at any scale.
• The cost of opening and closing channels is directly related to on-chain fees; during periods of high demand, fees rise quickly, making channels expensive.
  • To avoid this, a user should set up channels ahead of fee spikes, although deciding when to open channels is a non-trivial decision.
• Privacy on Lightning is suboptimal.
  • When you request a payment on the Lightning Network, you always disclose information such as the node’s IP address.
  • While senders (generally) have better privacy than receivers, they also expose information in the course of a transaction.
  • Based on how Lightning nodes communicate with each other, a third party can easily determine the UTXO associated with the on-chain, channel funding transaction. At scale, this surveillance behavior can have a deanonymizing effect on the network.

What could Lightning look like when most, if not all of these problems are solved?

Lightning User Experience in 2025

The next sections will highlight the potential future state of Lightning’s user experience. This is not an exact roadmap of how users will interact with Lightning in the future, it is a projection of user experience that could be possible, given certain upgrades to the network.

Splicing Makes Lightning Invisible to the User

We expect that splicing will be implemented in the majority of Lightning wallets in the coming years, but what does this mean for network participants?

Node operators will be able to add and remove funds from a channel without over-paying on-chain fees, instead of having to close and then reopen channels to achieve the desired size. Because channel resizing becomes affordable, node operators—or software acting on their behalf—would have greater control to manage their channels, which in turn would make payments succeed more often.

Lightning Service Providers (referred to as LSPs) would benefit in a similar way from the reduced costs of channel resizing and could provide an increased level of user privacy. LSPs that seek to optimize user privacy could combine users’ funds into a single, batched channel open transaction to obfuscate the source of the funds’ origination.

When splicing becomes the norm, and moving between Lightning and Bitcoin is cheap and easy, wallets would display a unified balance—because, to a user, there will no longer be a distinction between on- and off-chain funds.

In a scenario where on-chain fees are high, LSPs could manage users’ channels cheaply by combining splicing with atomic rebalancing on side chains; Liquid, for example.

Lightning Service Providers Lower the Barrier to Entry

LSPs could become an instrumental component of user experiences in the near future due to their ability to abstract away complexities from users. Additionally, LSPs reduce the capital requirements for running a node; they can serve as a user’s portal to the network.

The magic of Lightning is its instant settlement but failed payments and other points of tension cripple a user’s experience. By LSPs operating infrastructure like servers and/or the node itself, users can interface with Lightning in a straightforward manner. LSPs could remove user interactions with infrastructure by offering a node-in-the-cloud model where the user still retains control over their funds but does not interface with the node. They could also offer a “light” version of the service that consumes less battery on mobile, or a combination of both models.

If more capital is to move onto Lightning, users must be able to restore their node or wallet in a way that is familiar to them—like entering a series of 12 or 24 words into an application. Service providers allow users to store an encrypted backup of their Lightning wallet in the cloud. In the event that a user’s device breaks or is otherwise compromised, the encrypted cloud backup could be easily imported to a new device.

Removing Manual Effort from the Equation

If a person has to take additional steps to benefit from Bitcoin (or any other novel technology), chances are that they will drop off at some point in the adoption process.

In the context of a current problem that needs a solution: LSPs could solve “always-online” requirements by accepting payments for offline users, pushing the UX closer to existing payment solutions.

As more funding becomes available for Bitcoin developers, more solutions are likely to emerge that enable users to independently accept payments without leveraging external services.

Present-day payment IDs like Lightning Addresses are serviceable but custodial in almost all cases. Users should be able to exchange reusable QR codes to receive payments without reliance on a third party. Reusability is crucial: copying, pasting, and sending invoices to counterparties is too many steps. The availability of a simple solution would provide benefits to all Lightning users.

Image information source: https://bolt12.org/

The smaller, simpler QR code in the above image is called an offer which would allow wallets to handle the invoice requesting part of the payment flow without user direction. Another benefit to offers is that they can contain information like currency, vendor name, quantity limits, and routes to reach the receiving wallets.

Most people prefer a simple onboarding process, which means they will likely trust service providers with the setup. An example of this is the Fedimint protocol: a group of people who manage what is called an e-cash mint. This model offers better privacy and a suite of additional products and services such as inheritance management, private mining pools, decentralized dispute resolutions, synthetic dollar exposure, and more. Since Lightning is built into these communities, users can leave and join federations instantly at their discretion, with little cost to do so.

Privacy as a Standard on Lightning

For user privacy to become a standard feature on Lightning, the technologies that enable it must be invisible to the user—meaning that the user would not need to take any actions to benefit from it. Application developers and service providers must make decisions behind the scenes that, for example, separate on-chain transactions from Lightning transactions, among other things.

Disrupting Lightning Network Surveillance

It will become very difficult to assess whether an on-chain transaction is a Lightning channel open/close, as new technologies will increasingly make them look exactly the same as any other Bitcoin transaction. As more Taproot technologies are implemented, features like signature aggregation can hide information about a payment channel, and how many users might be involved in the transaction.

Users could gain more privacy when they make payments outside of their peer group if Taproot is widely implemented in wallets. At present, there is one payment ID (a hash of the payment) which is known by each intermittent node on the route to the destination. Aspects of how Taproot handles signatures can be used to create “dummy” payment IDs along the route so that only the sender and receiver have a clear understanding of the payment.

A Lightning user should not need to care—or even know about—the exact route their payment takes to reach its intended destination, but currently, nodes along the payment path can see where a payment was sent from. Through the Canadian Freedom Convoy saga, we have seen that governments can, and will, seize funds, close fiat bank accounts, and otherwise censor individuals who speak out against them.

LSPs could anonymize the source of a Lightning transaction by offering a service where they serve as a route-building middleman. This way, the LSP knows only the portion of the route it constructs, and the sender knows the other portion; intermediate nodes and the destination point would be “blind” to the totality of the route. This model would provide robust security, and the user wouldn’t need to be involved at all.

Using Lightning As a VPN

Wallets can get creative with how they offer privacy enhancements. For instance, wallets and LSPs could serve as “invoice middlemen” for users; the wallet creates an invoice forwards it to an LSP, and the LSP then completes the payment. To the recipient, it would appear that they’d been paid by the LSP, and in this way, the sender achieves a greater degree of privacy without any disruption to their familiar payment flow. Mutiny Wallet co-founder Tony Giorgio notes that this sort of approach allows wallet users to hide amongst all other users of the LSP.

A subset of Lightning users will want more robust privacy than can be attained by passing invoices through LSPs. More instances of transaction obfuscation is a tried and tested method of increasing privacy, but this requires manual user action and can be costly on-chain. Since LSPs are already running servers, they are well-positioned to offer collaborative transaction coordination services to users. Service providers could create privacy-boosting checkpoints: when users open or close channels, increase or decrease channel capacity (as previously mentioned in the Splicing section), or when users pay for goods or services.

Lightning Levels Up E-Commerce

Vendors could offer their customers a return period for transactions done over Lightning. Customers would pay a special kind of invoice at checkout but retain the ability to “revoke” the transaction until the time at which goods or service is rendered. This was previously impossible to do on Lightning.

Security is the Key to Institutional Adoption

In order for more institutions to join the Lightning Network, it needs to be easy to move funds from offline, cold storage into a Lightning channel. Taproot channels enable this use case, without compromising on security.

Additionally, it will become safer for institutions to hold large amounts of funds on Lightning. They will be able to use specialized devices that help protect them from the risks of internet-connected wallets.

Conclusion

Lightning has demonstrated its usefulness in conducting payments with instant settlement—but we should acknowledge that it does indeed have pain points. Even so, network participants should feel optimistic about the progress being made in solving UX hurdles; some of the world’s most talented developers are working tirelessly to enhance the experience.

As more technological solutions arise, and more capital is invested in the network, it is likely that Lightning Service Providers will take a larger role in abstracting complexities away from end users. Advancements in technology will similarly benefit self-hosted users, and move the entire network closer to an It Just Works experience.

There is much to be excited about in Lightning; all of the future-state projections in this article were informed by solutions being worked on today. The more developers and entrepreneurs focus on optimizing user experience, the more participants and capital joins the network, and the better everyone’s experience gets.