Latest Strikes 30 - Junly 20th-26th 2026

• Wavelength
• Bark
• Bolt12 Zaps
• Quick Strikes

Welcome to Latest Strikes, your weekly report of the latest Lightning-related news. Last week a new Ark implementation by Lightning Labs dropped, Bark got some Lightning improvements, and Ben Carman formalized Bolt12 zaps.

§Wavelength

A new Ark (or Ark-like) implementation joined the party last week, which seems to sit right between the two existing implementations (Arkade and Second). Another interesting aspect is who it was developed by, since LND’s Lightning Labs is behind the wheel here. Wavelength is a “self-custodial” all-in-one Bitcoin wallet, written in Go (Lightning Labs obliges). At its core, it’s an Ark client and an on-chain Bitcoin wallet, with the ability to do Lightning transactions through swaps, powered by Lightning Labs’s Loop service.

I think it’s interesting to see a company such as Lightning Labs take a crack at Ark, for several reasons. First, one of the core propositions of Ark is that the operator (the Ark Service Provider) handles all the liquidity-related complexity, notably (but not exclusively) when it comes to reaching the wider Lightning Network. With their undeniable experience and long established position in the network’s topology (especially with their Loop nodes), Lightning Labs is uniquely positioned to offer high bandwidth to Wavelength users. Secondly, Lightning Labs, which is also behind the Taproot Assets protocol, announced that stablecoin transfers are next on the roadmap, which positions Wavelength right between Arkade (huge on programmability) and Second (huge on payments).

One thing to bear in mind is that, from what I could tell, the server side of the protocol (which seems to be called Lumos) is not released in the open. One may wonder whether it will be once deemed ready¹, or whether Wavelength will follow the same model as prior Lightning Labs products such as Loop and Pool, where the client is open source but the server is proprietary². A key difference is that in Loop the interaction is completely self-custodial because the client cosigns and can verify the existence of UTXOs on-chain. Here, when receiving via Lightning on Wavelength, you have no choice but to trust the server that the VTXOs handed to you against your (Lightning) sats are backed by real bitcoin.

Overall, I think Wavelength is a nice complement to LND for use cases where running a full Lightning node is impractical. Being born in the age of agentic coding, it comes with all the niceties that’ll allow agents to quickly build on top or around it. But as always, tradeoffs must be carefully acknowledged.

§Bark

Speaking of Ark, the team at Second has been shipping interesting new Lightning-related developments lately:

• Bark Pay is a self-hosted payment processor that lets you easily accept Bitcoin, Lightning and Ark payments. From the video demo it looks pretty smooth!
• Bark 0.4.0 uses BIP321 payment URIs to fit all 3 payment rails into one QR Code. Funnily enough, Bark Pay doesn’t seem to use this.
• The team is also working on client-side pathfinding for Lightning payments, which is quite important from a privacy standpoint, while also enabling more micro-payment use cases by getting rid of the current 20 sats minimum Lightning fee in bark. The POC uses the LDK pathfinding module together with a Rapid Gossip Sync server that serves the network’s topology data to the client.

§Bolt12 Zaps

Ben Carman proposed Bolt12 Zaps in the nostr specification. They basically follow the same core flow as NIP57 zaps, except they don’t require the recipient to run or use a LNURL server. The crux of the flow is:

1. Recipient publishes a replaceable nostr event specifying one or many Bolt12 Offers.
2. The sender creates a “Zap Intent” event which contains the sender identity (or a fake one for anonymous zaps), the recipient’s identity, the amount and the Bolt12 offer used, as well as a 128-bit unique identifier (the zap_id).
3. The sender requests an invoice, using the Bolt12 Offer. In doing so, the sender passes the Zap Intent event ID (i.e. its hash) to the recipient as a payer note inside the invoice request.
4. The recipient responds with an invoice, which also contains the Zap Intent event ID.
5. The sender pays the invoice.
6. Now knowing the preimage, the sender can generate a Bolt12 Payer Proof.
7. The sender publishes an event that contains the serialized Zap Intent event and the payer proof.

It’s interesting to note that Bolt12 Zaps payer proofs carry more weight than Zap receipts: the latter are generated by the recipient, and may or may not contain the preimage (it doesn’t prove anything anyway, since by construction the recipient knows the preimage); the former are generated by the sender, which can only learn the preimage by actually paying the invoice.

StackerNews Discussion

§Quick Strikes

• A small Core Lightning release was published, notably with a fix that rejects a channel that reuses the same funding outpoint as an already known channel
• lxdev built a dark pools prototype where users can trade bitcoin against stablecoins in a privacy-preserving fashion. It leverages a Mercury-like statechain (i.e. with blind signing) for private Bitcoin offchain transfers; and a private zero-knowledge rollup executed by Citrea contracts for the stablecoins part. Looks quite promising.

That’s it for today. Thank you so much for reading this far, and until next week!

https://stacker.news/items/1537111