Howdy Folks 🤠
My nym is bitdern and I work at River – primarily making educational content and maintaining our Learn content repository.
I want to share this article I wrote recently with you all 👉 Looking Ahead: Lightning Payments in 2025
  • This article is centered around the current—and potential future—of the Lightning Network from a user-experience perspective. We think this framing makes sense because the experience is what’s most tangible to users, as opposed to the underlying technology.
  • I’m assuming the majority of you use Lightning on a semi-regular basis so you will understand when I say that there are aspects of the UX that definitely need an upgrade 😅 (e.g. wallet interactivity requirements).
  • One argument made is that LSPs will likely take a larger role in the future to alleviate some of the present-day UX hurdles. They could also perform valuable services in a privacy context; check out what Mutiny Wallet is doing with their LSP, for example!
I’m looking for some general feedback: → are there UX aspects that I missed, or didn’t fully nail? → is the article approachable for not-so-technical folks? → for the LN big-brains out there: did I get anything dead wrong?
🙏 Hope that y’all find the article interesting, thought-provoking, or valuable in some way; much love! 🧡
100% of sats boosted to this post will be passed through to OpenSats
As a UX designer by trade and a newcomer to Lightning, I cannot agree more about the UX being a huge barrier for newbies to move towards non-custodial solutions with Lightning. Two big issues come to mind when I think about improving the experience of using Lightning: running your own node and channel payments, which is mentioned in the article.
The current experience of moving funds
Most people are used to using apps/services like Cash App, Zelle, Venmo, PayPal, etc. where the UX is fairly simple. Find the person you want to send to (usually by username, phone number, or email), enter the amount you want to send, and hit the button. That's it.
I'd wager no one really knows about the technology that's under the hood that makes it happen (hell, I don't either lol) but it works and they don't question it. The majority of other cryptocurrencies operate in a similar fashion where you enter the address, enter the amount, and hit send. The technology is invisible and isn't really discussed, unless you're actively working on it or you're just super curious about it.
My initial experiences with Lightning were using Cash App's and Exodus's Lightning features, so I always thought Lightning functioned similarly to on-chain BTC and that at least Exodus's Lightning feature was non-custodial. But once I took a deeper dive, I discovered that I was completely wrong.
Non-custodial = running your own node
You're 100% right in that it definitely takes some tech-expertise and some enthusiasm to set up and run your own node. I do have a Raspberry Pi that I like use to tinker with, but I do not have a strong development background.
When I learned that true non-custodial solutions required running your own node, I was already put off a little bit. I understand that there are solutions that should be easy to set up and even run on my Raspberry Pi, but I really do not like the idea of having to make sure I understand how to set up everything properly from the beginning and also how to troubleshoot any issues.
That's a huge part of the reason why I'm using Alby, Cash App, and Strike as ways to partake with the Lightning network.
The mental model of channels
I tried using Electrum for a bit since that's the OG wallet that everyone seems to love. The UX is obviously not as up to snuff as other wallets, but I didn't have any issues for on-chain BTC payments. However, setting up Lightning was a different story.
If I recall, Electrum had a sort of Lightning node solution you can use (I remember looking up what trampoline meant or something), but I had no idea that you had to "open" a channel first by sending sats and that also dictated the max amount of sats you can send to that specific channel. Definitely lots of confusion/frustration and I ended up just closing everything and moving all my funds out of Electrum lol.
It just didn't make sense from a UX perspective that in order to send a specified number of funds to an address, I had to first open a channel with the same amount. The whole mental model of this still baffles me, and it's hard to justify how this makes sense from a usability perspective without having a deeper understanding of the technical reasons.
There are apps that handle channel creation very well by keeping it under the hood, such as Phoenix so maybe this isn't as large of an issue. Electrum is a wallet for people who have a technical understanding anyways.
Phew, I wrote a lot. Regardless I am excited to see more non-custodial solutions in the future where everyday folks can jump into Lightning with both feet. Having a good UX increases accessibility which in turn creates adoption.
reply
Thank you for this Brian!! Really nice to have an actual UX designer share their perspective on these issues.
Non-custodial = running your own node -On this point, have you checked out or used Phoenix, Breez, Blixt or Mutiny wallets? These wallets enable users to hold their keys, but they provide node solutions and have built-in LSPs for channel/liquidity management. From what I can tell, the average pleb will have a really hard time maintaining the end-to-end operation of an LN node.
reply
Yes, I have used Phoenix a little bit and I agree that their built-in channel management makes the experience much easier for newbies like me!
reply
Hey bitdern, great article! I think you did a great job in all the aspects you covered (btw I mentioned your piece here last week 😉).
You're touching a bit on this, but I think "mixed" solutions will probably be a thing in 2025. In such a solution, when a user receives a small amount it is kept by the LSP in a custodial way (for example as e-cash). Only when the balance is big enough and/or on-chain conditions are more favorable will an actual channel creation be triggered. This also allows for batching, and hence more fee savings. That's not ideal, since it involves a custodian at some point, but 2025 is quite near and I doubt we'll have things such as channel factories by then.
Something that is also a bit under-explored in today's wallets and might be a bigger thing in 2025 are "contacts". Blixt and Bitkit are the only wallets I can think of that are implementing some sort of contact repository for easier payments. There are technologies and networks seeing great development (Nostr, Slashtags, etc.) that can be abstracted from the user and provide dynamic contacts. This addresses the need for static payment "endpoints", in a different and complementary manner to Bolt12.
That's all I can think of right now, but there's probably more 😄 2025 is both so close and so far away 😅
reply
Fanis! Thanks for saying so & for featuring it in the LN Markets newsletter, that means a ton to me.
  • On your first point, yes "mixed solutions" are approximately what I had in mind! I wonder if one version of that might be where the LSP opens (one) private channel to the user, and when the user goes to make payments, it's routed directly through the LSP. That way the # of channels doesn't spiral out of control.
  • Contacts is a reeeeeeally good point to bring up! I didn't realize that Blixt had implemented a contacts scheme, are they using nostr? I've played around with Bitkit and I like the idea & tech behind slashtags, too.
Thank you for your perspective here, much appreciated!
reply
My pleasure, really!
The contact thing in Blixt seems to be essentially storing payment info (such as a Lightning Address or LNURL-Pay link) under a contact name. So it lacks automatic updatability, but can still be very useful for frequent payments.
I'm not sure what you mean regarding the LSP opening only one private channel with each user. That's pretty much what Phoenix does already with splicing, resizing the channel every time its needed. But it's not possible to receive a 10 sats payment for the first time, because it doesn't cover the on-chain fees of opening a channel. So the idea behind a "mixed solution" is that the LSP would take the Lightning funds for themself and send the user e-cash tokens instead. Once the user's balance is big enough (say 10k sats), the LSP will open a private channel with them. If many users reach this balance threshold approximately at the same time, it becomes possible for the LSP to batch the channel opening of many users into only one bitcoin transaction.
reply
Yes that makes sense -- about the LSP not being able to open a channel for 10 sat transaction. I saw that Calle posted about this sort of model on twitter yesterday: https://twitter.com/callebtc/status/1696897866936053927?s=20
I think I am going to include the contacts aspect and this hybrid model in the article. Great suggestions!
reply
It will be a github redirect to Drivechain Thunder.
reply
I feel like major improvements in the bitcoin space happen during bear markets, so I wouldn't expect 2025 to look that different. 2027 on the other hand.. Hoping to see more wide adoption of LN address in wallets and wider adoption of LN in general by the Coinbases of the world.
reply
Yeah, totally understandable on the timeframe distinction! We wanted to put a year on it that was close enough to be "exciting", but 2027 is probably more realistic for some of the upgrades - especially stuff like widespread use of Taproot channels, async payments, TARO, non-interactive node packages etc.
reply
2025? Not far away from what we have today. Developing new features is not so easy/fast and most of wallet apps UX depends mostly on base code to evolve.
I consider UX for wallets not an important thing, right now. We are far away from mass adoption. Many people still have no fucking clue what is Bitcoin, nor using it... LN is just a small 4 years baby. Is not even going to school.
Do you really think that these so called people will bother for LN UX? I really doubt it.
reply
Developing new features is not so easy/fast and most of wallet apps UX depends mostly on base code to evolve.
  • This is why I argued that LSPs will take a larger role in the future. For example, LDK is working on Async payments, but that will take time. In the meantime, LSPs could work on ways to accept payments for offline users.
I consider UX for wallets not an important thing, right now. We are far away from mass adoption. Many people still have no fucking clue what is Bitcoin, nor using it...
  • IMO the ideal state is that folks use Lightning wallets and there's no/few mention of Lightning or even bitcoin, they just send payments as they would in other apps. But that means that prioritizing UX is paramount, because from what I can tell, it's not going to be easy to educate newcoiners on how lightning works. Better to give them a good experience.
People like sleek experiences, well-designed apps, and not being bashed over the head with educational content 😂 🤷
reply
Please show me you convince these people to use any Bitcoin wallet app you want...
People are really retarded nowadays.
reply
Haha I see your point man! Mine is that we need to be clever insofar as that relates to "hiding" Lightning/Bitcoin stuff from newbies.
For example, I think CashApp does a really good job with this already!
reply
Strike as well. I can have USD balance on my account and pay a Lightning invoice direct from that. They handle the BTC purchase on the back end. I see a lot of CashApp terminals. I would love to be able to choose to pay in BTC there and the business could decide if they wanted to keep the BTC or convert it to USD right away.
reply