L402 is a suitable internet-native payment protocol for agents.

Author: Michael Levin

Source: https://lightning.engineering/posts/2026-03-11-L402-for-agents/

AI agents can read documents (so hello agent!), write code, organize multi-step workflows, and call APIs (Application Programming Interfaces) on the network. But they can't reliably and scalably buy things. Credit cards require identity verification; usage dashboards require a browser to view; memberships usually require human confirmation on payment pages. These are not suitable for fully automated, agent-like, millisecond-triggered software.

The creators of the internet saw this trend. When the originators of the HTTP specification designed the status codes, they included 402 Payment Required , so that it could be used someday when the internet developed its own native payment layer. In other words, this opcode was reserved for future use. The problem was that in the 1990s, no decentralized currency could utilize this opcode. 402 remained dormant for decades, left in reserve because the future never came.

But things are different now. L402 is a protocol standard that revitalizes this long-forgotten state code on the internet by combining the 402 status code, Bitcoin's Lightning Network , and cryptographically authenticated tokens. The Lightning Network is a payment network that can process transactions instantly, with high throughput and low cost. As a result, this protocol allows any client that can connect to the Lightning Network to instantly make payments to any L402-enabled API (and authenticate its own identity), without needing to "log in," without needing an API key, and without needing to establish a pre-existing relationship with the server.

We recently released Lightning Agent Tools , a combination of seven complementary skill descriptions that enable AI agents to live directly on the Lightning Network, including making API payments with L402 gateways , hosting payment endpoints, and organizing end-to-end buyer/seller workflows. Today, we want to delve deeper into the protocol that makes all this possible, explain how L402 works from start to finish, distill the latest changes to the L402 bLIP specification , and demonstrate why L402 is the right payment protocol for the AI agent economy.

How L402 works: Four steps, no login required.

L402 is an HTTP authentication scheme. The server uses the 402 status code to protect a resource; the client pays a Lightning invoice to gain access. The entire exchange process consists of four steps:

1. Request : The client (your AI agent, a command-line tool, or a browser plugin) sends a standard HTTP request to a protected endpoint.
2. Challenge : The server returns HTTP 402 Payment Required response along with a WWW-Authenticate response header containing two values: a token (a cryptographic certificate encoding access rights) and a BOLT 11 Lightning Invoice (payment request). This token promises the payment hash of the invoice, allowing the client to verify it statelessly.
3. Payment : The client decodes the invoice, confirms the amount is acceptable, and then sends the payment via the Lightning Network. Payment settlement reveals a preimage, a 32-byte value that serves as cryptographic evidence of the payment. This preimage satisfies the following relationship: H = sha256(preimage) , where H is the payment hash embedded in the token.
4. Access : The client retryes the access request using Authorization: L402 <token>:<preimage> header. The server verifies this token, checks if its preimage matches the promised payment hash, and then provides the resource.

It's that simple. The certificate is purchased, not pre-configured. There's no OAuth process, no need to manage API keys, and no need to monitor usage dashboards. This is also why L402 is a natural fit for AI agent workflows: AI agents can discover and purchase resources on the fly, without requiring humans to pre-register accounts for them.

Once you obtain the token, you can cache it and use it in subsequent requests to the same service until it expires or is revoked. AI proxies are charged per endpoint, not per request.

Useful and smart certificates

L402 is not picky about the token format; any authentication token that can promise a payment hash value will work. However, the L402 protocol specification recommends " macarron ," a message authentication bearer certificate format based on a hash function, originally designed by Google for authentication in distributed systems.

Macarons are useful for AI agents because they have two properties that standard API keys and anonymous tokens do not support: "attenuation" and "delegation".

The characteristic of downgrading is that the holder of a Macaron certificate can add restrictions to it without contacting the certificate issuer. For example, a parent proxy, after obtaining a Macaron certificate, can add restrictions (conditions limiting token usage), such as spending limits, service constraints, and expiration times. The resulting restricted certificate can still be cryptographically verified, but carries stricter permissions and does not require communication with the server that issued it.

The nature of delegation is that a restricted certificate can be delegated to a sub-agent. An agent responsible for coordination can create a macaron that can only be paid for, setting a spending limit of 500 satoshis, and then pass it on to an employee agent responsible for acquiring market data. This employee agent can then purchase resources within these limits and cannot exceed them. This sub-agent cannot relax its own permissions. The certificate is designed to enforce minimum permissions.

This is essentially the hierarchical licensing system required by a multi-agent system. A single certificate can combine payment evidence, scoped permissions, and delegated authority into a single token—all of which can be verified without querying a database.

L402 bLIP: An open specification, a new upgrade

The official document for L402 is bLIP-0026 , which is a "Bitcoin Lightning Network Optimization Proposal (bLIP)" submitted to the Lightning Network Specification Repository . bLIPs are community-reviewed design documents for Lightning Network features, and L402 bLIP contains the complete protocol specification, allowing everyone (every agent) to implement a compatible client or server.

The latest proposed update to this bLIP includes several important changes, reflecting feedback from multiple teams actively developing this protocol:

Version field . By adding a version parameter to WWW-Authenticate challenge header, we allow the protocol to evolve independently without breaking existing clients (currently, this version number is "0" ). According to the specification's forward compatibility rules, clients that do not understand the version number parameter can ignore it.

The token design is no longer selective . The specification now supports languages other than macaroon, using token instead of macaroon as the key name in the challenge header. The only hard requirement is that this token must be able to commit to the payment hash of the invoice to allow stateless client verification. Macarons remain the recommended format (due to their degradation and delegation properties), but the protocol no longer mandates their use. A recommended macaron structure is provided in the appendix.

A concise specification . The entire document has been significantly streamlined, removing unnecessary and redundant statements, but retaining all the protocol details that guide implementation.

These proposed changes will make L402 easier to implement, more flexible in token format, and better prepared for forward compatibility. This bLIP also includes backward compatibility provisions; for example, servers will accept both token and macaron parameters equally.

Why is L402 suitable for AI agent economy?

2026 is poised to be the year of AI-powered agent payments. We've already seen several protocols targeting this area emerge. They all share the same goal: to enable AI agents to automatically discover, purchase, and consume services without human intervention. L402 has had this goal from the outset. Compared to other solutions, L402 possesses a structured advantage, which is crucial for transforming AI agents from simply calling tools into truly autonomous businesses.

The cryptographic evidence of the payment is built into the certificate . When an AI agent pays a Lightning invoice to an L402 endpoint, the Lightning Network reveals a 32-byte preimage. This preimage, combined with the token, forms a self-contained piece of evidence proving that the payment has occurred. Server-side verification uses a simple hash operation sha256(preimage) == payment_hash . No database queries, RPC calls to a blockchain node, or external verification services are required.

Methods other than L402 typically separate payment signing from settlement. A client signs a payment intention, a third-party coordinator broadcasts the transaction, and the server must then verify it using on-chain state or trust the coordinator to confirm the payment. This introduces external dependencies and latency, which L402 completely avoids. L402 verification is a local computation. The cryptographic credentials are evidence in themselves; no intermediaries are needed, and no one can fail to confirm the payment.

For an AI agent that might call an API hundreds of times per minute, "verifying locally using mathematics" and "calling an external service to check the payment status" are worlds apart.

Privacy is part of the architecture, not a feature toggle . L402 runs on the Lightning Network, which uses torrent routing to forward payments. Each intermediate node can only see its previous hop and its next hop. Payments leave no trace on the blockchain. The L402 certificate itself is a bearer token, bound to a random identifier, unrelated to email, account, or real-world identity.

Other protocols running on public blockchains permanently record every transaction: its sender address, receiver address, amount, and timestamp, making it visible to everyone. For AI agents that frequently initiate micropayments to dozens of services, this exposes visible patterns: every resource they access, when they access it, and how much they use. The metadata of AI agent activity can be commercially sensitive, so protocols that expose this metadata by default are considered a liability.

No intermediaries are needed, and there is no downtime . The Lightning Network is permissionless. It is not operated by a single entity. An L402 server only needs its own root public key and the received token to verify the certificate, without relying on any third-party online services or requiring their cooperation.

Many other AI-powered payment proxy protocols rely on a single company's infrastructure to order transactions, facilitate transactions, and issue tokens. This means that if that company's service goes down, your AI proxy stops working. L402's architecture distributes these functions across thousands of independent nodes.

The complexity of certificates in multi-agent systems . As mentioned earlier, L402's macaron-based certificates support hierarchical delegation and decrementing permissions, require no contact with the issuer, and can be reused until revoked. Once an agent obtains a certificate, it can be reused, and the token itself encodes the service content, permissions, and constraints. Other methods treat each request as a separate payment: indeed, stateless and simple, but lacking a persistent certificate layer to manage the hierarchy of permissions for the AI agent team. In other words, using L402, multi-agent systems can automatically manage budgets, licenses, and service access rights without requiring human reauthorization for each subtask.

Let's develop it!

The L402 protocol is ready for production environments. Since its first version five years ago, Lightning Loop has been using L402 through Aperture (an L402-aware reverse proxy).

If you're looking to have your AI agent send transactions via L402, Lightning Agent Tools offers a complete technology stack: lnd skill description for running a Lightning node; lnget skill description for automatically paying for L402-protected APIs; aperture skill for hosting paid endpoints and managing restricted certificates via macaron baking; and a business quasi-skill for coordinating end-to-end buyer/seller workloads. Read this blog post ( Chinese translation ) for more details, or you can directly read the L402 and lnget documentation .

The L402 bLIP specification is open for review and supplementation. We invite the entire community to explore it, provide feedback, share application scenarios, and ask questions in the L402 library . Open-source client and server libraries already exist in multiple languages: JavaScript , Go , Rust , and Python . This Aperture developer documentation describes the server setup process. If you are already using AI agents, these skill descriptions can work with any framework that can execute shell commands: Claude Code , Codex , OpenClaw , and your own tools :).

Check out the L402 documentation , join our Slack community , follow us on Twitter/X , submit a PR , and subscribe to our weekly newsletter . Machine-paid internet doesn't generate itself. Well, maybe it does. So let's work together with AI agents!

(over)