With the increased attention now on CLINK, several people have asked me how it compares with L402.

Now, I've long been dismissive of L402 for a number of reasons, not just because it's a meme built on resurrecting a forgotten HTTP status (failure) code, but because it never attempted to solve the ingress or identity issues I've been targeting with CLINK. I never considered them as being in the same problem space, but then the agent hype train started.

Agentic payments were not on anyone's radar years ago when I started using socket-based protocols for Lightning (first GUN, which later evolved into Nostr). My thesis has always been a more general machine-to-machine and web-to-node payments future, and the biggest inhibitor to that since the advent of Lightning, is traditional web infrastructure. The desired end state has always been being something anyone can trivially plug in a box at home and use it, not having to deal with domains, ssl, firewall rules, a static IP, p2p unreliability, and all that associated friction.

The constraints on agents themselves were of course not a consideration either. Who could have foreseen "skills" for everyone running an agent with a sandboxed set of default Linux tools?

This was kind of an "oh shit" revelation. L402 can work with curl. Maybe there's something there?

I pondered it a bit more given that, and how a sandboxed tool actually has to interact with with these systems. It didn't take long before the illusion of the curl-and-pay simplicity as portrayed by the L402 bandwagon falls apart.

The lowest hanging fruit is that L402 is a failure-driven protocol. It literally relies on your calls erroring (402 Payment Required) and interrupting the application flow. Once that happens you have to hand the data to an external tool whether that be to manipulate macaroons, connect to a payment source, retry, etc.

The recent release of lnget would seem to acknowledge that you cannot evade shipping a non-standard binary or other external orchestration just to handle that logic. Asking an autonomous agent to download network-client binaries works, with trade-offs (including security ones), but also negates the advantage of being a raw HTTP request.

It reveals the true problem as being "How does the agent connect to YOUR Lightning node?". Receiving an invoice through HTTP is easy (receiving an invoice request, not so much), but paying it still requires access to a wallet.

This is where I believe CLINK has solved the correct problem, the end-to-end connectivity and identity afforded by Nostr.

CLINK is bidirectional. An agent can spend, receive, request an invoice, expose an offer, manage a standing authorization, or respond to a payment request. It is not confined to the merchant-initiated flow where a server rejects a request and tells the client what to pay.

The identity layer then allows the payment relationship to persist above any individual request. A service does not need to rediscover and rechallenge the payer every time its balance reaches zero. It can identify the agent, report its remaining credit, request a top-up before exhaustion, or allow the wallet to replenish automatically within a defined budget. CLINK was built for policy-driven payments rather than failure-driven ones.

Beyond CLINK specifically, remote signing is already a common pattern in Nostr. An application holds an identity and communicates with a separate signer that retains the authority to approve sensitive operations. CLINK just extends that to money.

The agent does not need direct access to the node, its RPC interface, or its wallet secrets. It sends a request to an identity. The wallet receives it, applies policy, performs or rejects the operation, and returns the result. This also means the agent is not tied to a specific Lightning implementation or connection method. The wallet can be local, remote, mobile, self-hosted, or migrated later. The CLINK identity and relationship remain stable while the infrastructure behind them changes.

L402 has had timing on its side. It maps cleanly onto the current AI-agent narrative: give the agent curl, return an invoice, and let internet-native money handle the rest.

But the rest is the entire problem. Those requirements do not disappear because the first interaction fits inside an HTTP response header. L402 looks like a compelling diagram at first, because most of the payment system sits outside its frame. CLINK begins where that diagram ends.