Welcome to your weekly summary of noteworthy news and developments in the Lightning Network ecosystem. Last week was quite quiet, but still brought a few interesting updates, blog posts and announcements.

Version 5.1.4 of the Blockstream App introduced submarine swaps between Lightning and Liquid, via Boltz. This comes as a replacement for the previous Lightning support in the app, which relied on Blockstream Greenlight and was discontinued.

Users of the Blockstream App hold their funds as on-chain Bitcoin and/or Liquid balances, and can now pay Lightning invoices directly from the Liquid balance via a Liquid-to-Lightning swap ; and conversely receive a Lightning payment into their Liquid balance via a Lightning-to-Liquid swap.

This move by the Blockstream App team away from Greenlight and into LN <> Liquid swaps is reminiscent of the similar pivot operated by Breez with the introduction of the Nodeless SDK which quickly gained "market shares" over the Native/Greenlight SDK, which is no longer maintained.

Fountain, a Lightning-native podcasting 2.0 app, now supports Nostr Wallet Connect (NWC) and paying any Lightning Address. The NWC integration lets users send and receive payments on Fountain directly with their own external Lightning wallet (e.g. Alby Hub) without having to deposit sats on Fountain.

This release also brings a tight Strike integration, which enables podcasters to withdraw to Strike in their currency of choice.

Continuing on their previous post (which we covered 2 weeks ago), the Alby team shared a glimpse of their experiments around suspendable signers. As a reminder, their goal is to find ways to propose a hosted but "self-custodial" Lightning solution with a free tier. Currently, Alby Hub is a paid service, because it runs 24/7 and Alby cannot afford to offer this as a free tier given the associated hosting costs. The alternative is self-hosting (which is great!), but a third path could be a "suspendable Alby Hub", which would make some compromises but be available for free.

In this post, the Alby teams explores the idea of users running their "suspendable hub" in a serverless environment such as Vercel. This enables users to "own" the code they deploy, while keeping the service free since normal users should typically fall under the free tiers of serverless providers. This also makes it possible to handle "offline receive", since serverless environments allow the "apps" running on them to be woken up on demand¹. To make setup easier, the Alby website could offer an integration with serverless hosting providers via their OAuth APIs.

In the blog post, they share their preliminary work on an Arkade signer proof-of-concept. It remains to be seen if the step of having "layman" users interact with serverless services isn't one that is too big to take, but surely LLMs could also help in that regard.

The Spiral team published a blog post on DNS-based payment identifiers (as described in BIP0353), which they refer to as Human Bitcoin Addresses (HBAs). HBAs are meant to be easier to read and transmit for humans that Bitcoin addresses or Lightning invoices.

HBAs follow a user@domain structure (e.g. fanis@fanismichalakis.fr), much like Lightning Addresses, but using DNS instead of web servers for resolution. It is also more versatile than Lighting Addresses, since it can be used to resolve any static payment identifier (e.g. a Silent Payment address). Since HBAs don't rely on centralized web servers, they should also provide better privacy and censorship resistance, as well as enhanced security. However, it still relies on the DNS infrastructure and authority hierarchy, which is a bit counter to Bitcoin's ethos.

The blog post sparked interesting discussions on X regarding the "spoofability" of HBAs. For example, someone trying to pay me could be convinced by a scammer to send sats to fanis@fanismichalakis.gr, believing the address belongs to me, while it is actually controlled by the scammer. Traditional fintech apps largely circumvent this scenario due to the large walls they erected around their garden, but that's not the case for open systems such as Bitcoin or Lightning².

I think to some extent contacts, as implemented in Phoenix, solve this issue: you have to be very careful the first time you pay someone to make sure you got their HBA right³ ; but then you can just save it as a contact and reuse it very easily later on with the touch of a button.

That's it for today. Before you leave, I wanted to tell a few words about the ₿OSS Challenge, a Chaincode Labs initiative for developers wanting to bootstrap a career in Bitcoin open source software. Admissions are open until the end of the month. If that rings a bell and you're serious about it, check their website out and apply. Developers of the 2025 program now work on very diverse Bitcoin-related projects and receive funding, with for example Second and Vora announcing last week that they are funding a year-long grant to Beulah Evanjalin to implement nested MuSig in libsecp256k1-zkp, which will benefit all Bitcoin L2s.

Again, thanks for reading this for, and see you next week!