Welcome to Latest Strikes, your optimistic-weekly report of the latest Lightning-related news. Last week's thunder was very much AI and payments, but we'll also cover Rootstock prisms and a few other exciting things. Let's dive in!

Are Payment Channels Cool Again?Are Payment Channels Cool Again?

Agentic payments (the ability for AI agents to pay for things) was the big thing last week, with the launch of the Machine Payment Protocol (MPP) open standard, co-authored by Tempo (a "payment at scale" blockchain) and Stripe (probably the #1 online payment processor). The goal of MPP is to coordinate payments between a client (e.g. your AI agent environment) and a server, while minimizing the added complexity and round trips.

An MPP server uses the 402 HTTP error code ("Payment Required") to signal that a payment is expected to release the requested ressource. The server response also comes with one or many WWW-Authenticate: Payment headers, each containing a payment challenge. The client has to fulfill one of those challenges and provide a proof of such fulfillment in its follow-up request in order to be granted access to the ressource. MPP supports many payment protocols, but with Lighting the header would typically contain a Bolt11 invoice, and the corresponding preimage would be the challenge response, proving that the client paid the invoice.

The MPP launch also brought back to a wider audience the idea that payment channels are especially well-suited for agentic payments, due to their ability to easily handle high-frequency, small amounts payments without delaying settlement.

MPP comes with 2 basic payments "intents": charge and session:

• charge: one payment per request,
• session: prepay some usage on the first request, and only pay again once the prepaid credit is exhausted. Between payments, a bearer token authenticates the client so that the server can attribute requests to the corresponding balance.

Another neat thing about MPP is how agnostic it is. Not only does it support virtually every payment method (as long as a proof can be provided and easily verified), it also leaves the more intricate details open. For instance, while the immediate implementation of Lightning MPP is to use the invoice's preimage as proof of payment for both charge and session intents (as is the case in Spark's Lightning MPP SDK), one could imagine using Lightning Labs' L402 with macaroons instead. The core idea is the same, but macaroons allow for more flexibility by decorrelating payment reception from payment verification. The Lightning Labs team even seem to have the client part.

Of course, this freedom comes with a price: will both server and client support the same flavor of Lightning MPP? But that's precisely where MPP's ability to issue multiple payment challenges in the same response comes very handy.

MDK CloudflareMDK Cloudflare

Joh Cantrell released mdk-cloudflare, porting MoneyDevKit (MDK) into Cloudflare Durable Objects. This makes a ton of sense because:

• MDK is built around the idea of integrating the Lightning node (LDK) directly into the web app, on the server side, waking up the node on demand ;
• Durable Objects are a special kind of Cloudflare workers that combine quick on demand start^[1] with a durable storage (as the name implies), perfect to store the Lightning node's state.

Shipping this required "building a custom [LDK] node that compiles to wasm to run on cloudflare’s js runtime", which is a feat the creators of the Mutiny LDK-based web wallet had envisioned a few years ago, assessing it would be possible but also quite a piece of work.

By the way, John also added support for MPP into mdk-cloudflare.

ClawCashClawCash

Marco Argentieri built ClawCash, a "wallet" designed to be use by your agent (e.g. OpenClaw, Claude Code, etc.). It runs in a TEE (AWS Nitro), is able to pay and receive on Lightning or various stablecoins through Arkade, and understand things like the MPP protocol. If you give it money, it'll be able to pay other agents or services required to fulfill the tasks with set it to do. Conversely, it can also work for you and charge other agents or even humans.

"Native" Prisms Via Rootstock"Native" Prisms Via Rootstock

The Geyser team announced the release of a self-custodial "prisms" mechanisms, aimed at improving payment reliability while ensuring every participant (creators, affiliates and Geyser themselves) get their cut on donations.

Self-custodially and atomically splitting a Lightning payment between different beneficiaries has been a long-standing difficult problem to solve. The historical practical way to achieve that has been the Lightning Prisms idea, but it relies on Lighting Address server sending funds received to a Lightning Address to a set of other Lightning Addresses, some of which might be "prism addresses" themselves. Each server along the way needs to be trusted to properly split the payment, so this puts "self-custodial" part of the narrative into question.

Geyser approached the problem differently by using the Rootstock sidechain to perform the "business logic" part of the splitting. Each creator, when launching their project, get their own Rootstock wallet. When someone wants to donates to them, their Lightning or on-chain payment reaches Rootstock through a Boltz swap, and is then split between the creator, Geyser and any potential affiliates^[2], via a Rootstock smart contract. When the creator wants to withdraw their funds, they can initiate another Boltz swap from their Rootstock wallet to on-chain or Lightning.

This allows the Geyser team to process payments to creators:

• without having to take custody of the funds
• without having to run a Lightning node
• while taking a share of the payment, and ensuring affiliates can also pocket their part of the revenue.

Prior to this, Geyser relied on hodl invoices to process payments to creators in a self-custodial manner. The creator would provide a Lightning Address beforehand and every time someone wished to make a donation, Geyser would query the creator's Lightning Address for an invoice, wrap this invoice with one of theirs that requested a slightly bigger amount, forward the payment to the creator and pocket the difference. A big drawback of this method was that if the Lightning Address of the creator didn't work, or they didn't have enough inbound liquidity, the donation would fail. With Rootstock prisms, the donation and the final on-chain/Lightning settlement to the creator are two different steps, improving reliability.

Quick StrikesQuick Strikes

• USDT payments are back in Boltz. Any flavour that is part of the USDT0 standard is supported ;
• seems like support for multiple Lightning implementations is coming to ThunderHub. Until now, the OG node interface software only supported LND ;
• BlitzWallet shipped an interesting "contact check" feature, letting users quickly verify that they're sending money to the right contact
• Voltage is hiring an Infrastructure Engineer!

That's it for last week! As always, thanks a ton for reading this far! Feel free to drop comments or questions below. And until next week!

1. See this article for a better understanding of the challenge Cloudflare Workers tackle. ↩

2. People who shared the crowdfunding campaign with an affiliate link. ↩