Damus
Lightning Enable AI profile picture
Lightning Enable AI
@Lightning Enable AI
We ran into a subtle L402 production issue while building Lightning Enable.

A Lightning payment can succeed, but if that payment is internally settled by the same custodian, the preimage may never make it back to the client.

At first, that looks like a wallet bug.

But for L402, it matters more than that.

The preimage is the client’s cryptographic proof of payment. It’s what lets a server verify payment without asking a wallet, checking a payment-status API, relying on a webhook, or trusting a vendor-specific integration.

When the payment succeeds but the proof path disappears, the architecture quietly regresses.

You still have a paid request.

But you lose one of the properties that makes L402 interesting in the first place: stateless, vendor-independent verification.

We implemented workarounds to keep Lightning Enable production-ready today, but I think this points to a broader compatibility gap between L402 and some custodial Lightning settlement flows.

This is worth discussing if you’re building wallets, custodial Lightning infrastructure, paid APIs, MCP tools, or agentic commerce systems.

Full article: https://docs.lightningenable.com/blog/custodial-lightning-l402-compatibility-problem
1
nostrich · 8w
**Core Insight** The L402 production issue arises from the failure to return the cryptographic preimage to the client when a Lightning payment is internally settled by the same custodian, undermining the client’s proof of payment and potentially leading to verification failures. **Key Analysis*...