Agents can read documentation (Hi agents! 👋), write code, orchestrate multi-step workflows, and call APIs across the web. They cannot, by and large, pay for things. Credit cards require identity. Billing dashboards require a browser. Subscription tiers require a human clicking through a pricing page. None of these work for software that operates autonomously, at agent scale, in milliseconds.

The internet's creators saw this coming. When the early authors of the HTTP specification designed the protocol's status codes, they included 402 Payment Required, a placeholder for a future where the web had its own native payment layer. This status code was Reserved for Future Use. The problem was that in the 1990s, no decentralized digital currency existed to make it work. So 402 sat dormant for decades, reserved for a future that hadn't arrived yet.

That future is here. L402 is a protocol standard that activates the internet's long-forgotten 402 status code by combining it with Bitcoin's Lightning Network (a payment network capable of instant, high-volume, low-cost transactions) and cryptographic authentication tokens. The result is a protocol where any client with access to the Lightning Network can pay for and authenticate with any L402-enabled API instantly, with no signup, no API key, and no pre-existing relationship with the server.

We recently released Lightning Agent Tools, a set of seven composable skills that give AI agents the ability to operate natively on the Lightning Network, including paying for L402-gated APIs, hosting paid endpoints, and orchestrating end-to-end buyer/seller workflows. Today, we want to go deeper on the protocol that makes all of that possible, explain how L402 works from the ground up, highlight the latest updates to the L402 bLIP specification, and explain why L402 is the right payment protocol for the agent economy.

How L402 Works: Four Steps, No Signup 🔐

The L402 protocol operates as an HTTP authentication scheme. A server protects a resource behind a 402 status code. A client pays a Lightning invoice to gain access. The entire exchange takes four steps:

1. The request. A client (your agent, a CLI tool, a browser extension) sends a standard HTTP request to a protected endpoint.

2. The challenge. The server responds with HTTP 402 Payment Required and a WWW-Authenticate header containing two values: a token (a cryptographic credential encoding the access grant) and a BOLT 11 Lightning invoice (the payment request). The token commits to the payment hash of the invoice, which makes stateless verification possible.

3. Payment. The client decodes the invoice, confirms the amount is acceptable, and pays it through the Lightning Network. Payment settlement reveals a preimage, a 32-byte value that serves as cryptographic proof of payment. The preimage satisfies the relationship H = sha256(preimage), where H is the payment hash embedded in the token.

4. Access. The client retries the original request with an Authorization: L402 <token>:<preimage> header. The server validates the token, checks that the preimage matches the committed payment hash, and serves the resource.

That's it. The credential is purchased, not provisioned. There is no OAuth dance, no API key management, no billing dashboard. Any client with Lightning access can authenticate with any L402 server instantly. This is what makes L402 native to agent workflows: agents can discover and pay for resources on the fly without a human pre-registering accounts on their behalf.

Once a token is obtained, it can be cached and reused for subsequent requests to the same service until it expires or is revoked. An agent pays once per endpoint, not once per request.

Credentials That Get Smarter, Not Just Valid 🎟️

The L402 protocol is token-format agnostic. Any authentication token that can commit to a payment hash works. But the specification recommends macaroons, a hash-based message authentication bearer credential format originally designed by Google for distributed systems authentication.

Macaroons matter for agents because they support two properties that standard API keys and bearer tokens do not: attenuation and delegation.

Attenuation means a macaroon holder can add restrictions to an existing credential without contacting the issuer. For instance, a parent agent can take a macaroon and append caveats (conditions that restrict the token's use) like spending caps, service restrictions, or time-based expiration. The resulting restricted credential is cryptographically valid, carries tighter permissions, and requires no round trip to the server.

Delegation means that restricted credential can be handed to a sub-agent. A coordinating agent can create a pay-only macaroon with a 500-sat spending cap and pass it to a worker agent tasked with fetching market data. The worker agent can pay for resources within those bounds. It cannot exceed them. It cannot escalate its own permissions. The credential enforces lowest privilege access by design.

This is the kind of permission hierarchy that multi-agent systems need. A credential that combines proof of payment, scoped capabilities, and delegated authority in a single token - all verifiable without a database lookup.

The L402 bLIP: Open Specification, New Updates 📋

L402 is formalized as bLIP-0026, a Bitcoin Lightning Improvement Proposal (bLIP) submitted to the open Lightning specification repository. bLIPs are community-reviewed design documents for Lightning Network features, and the L402 bLIP encodes the full protocol specification so that anyone (or any agent) can implement a compatible client or server.

The latest proposed update to the bLIP includes several significant changes informed by feedback from teams actively building on the protocol:

Version field. We're enabling the protocol to evolve without breaking existing clients by including a version parameter (currently "0") in WWW-Authenticate challenge header. Clients that don't understand the version parameter ignore it per the spec's forwards-compatibility rule.

Token-agnostic design. The specification now expands the language beyond just macaroons, using token instead of macaroon as the key name in the challenge header. The only hard requirement is that the token commits to the payment hash of the invoice, enabling stateless server-side verification. Macaroons remain the recommended format due to their attenuation and delegation properties, but the protocol no longer mandates them. A suggested macaroon structure has been moved to an appendix.

Condensed specification. The overall document has been significantly streamlined, cutting unnecessary verbosity while preserving the full protocol detail needed for implementation.

These proposed changes make L402 easier to implement, more flexible in token format, and better positioned for forward compatibility as the protocol matures. The bLIP also includes backwards compatibility provisions like servers accepting parameters for both tokens and macaroons.

Why L402 for Agent Commerce 🦞

2026 is shaping up to be the year of agentic payments. We've already seen the release of a number protocols targeting the space. The goal is for AI agents to autonomously discover, pay for, and consume services without human intervention. L402 was purpose-built for this from the start. Compared to alternative solutions, L402 has structural advantages that matter as agents move from simple tool-calling to true autonomous commerce.

Cryptographic proof of payment, built into the credential. When an agent pays an L402 invoice, the Lightning Network reveals a 32-byte preimage. That preimage, combined with the token, constitutes a self-contained proof that payment occurred. The server verifies this with a single hash check: sha256(preimage) == payment_hash. No database lookup. No RPC call to a blockchain node. No external verification service.

Alternative approaches typically separate the payment signature from settlement. A client signs a payment intent, a third-party facilitator broadcasts the transaction, and the server must verify against on-chain state or trust the facilitator to confirm settlement. This introduces external dependencies and latency that L402 avoids entirely. L402 verification is a local computation. The cryptographic artifact is the proof. There is no intermediary to ask, and no one who can fail to confirm.

For agents making thousands of API calls per minute, the difference between "verify locally with math" and "call an external service to check payment status" compounds fast.

Privacy as architecture, not a feature toggle. L402 runs on the Lightning Network, which uses onion-routed payments where each intermediary node sees only its immediate predecessor and successor. Individual payments leave no on-chain footprint. The L402 credential itself is a bearer token tied to a random identifier, requiring no email, no account, and no real-world identity.

Alternative protocols that operate on public blockchains record every payment permanently, with sender address, recipient address, amount, and timestamp visible to anyone. For agents conducting frequent microtransactions across dozens of services, this creates a visible pattern of every resource accessed, when, and for how much. Agent activity metadata can be commercially sensitive so a protocol that exposes it by default is a liability.

No intermediaries, no down time. The Lightning Network is permissionless. No single entity operates it. L402 servers verify credentials using only their own root key and the presented token, with no dependency on any third-party service being online or cooperative.

Many alternative agentic payment protocols route through a single company's infrastructure for sequencing, facilitation, and token issuance, meaning that company's outage is your agent's outage. L402's architecture distributes these functions across thousands of independent nodes.

Credential sophistication for multi-agent systems. As covered above, L402's macaroon-based credentials support hierarchical delegation, attenuation without issuer contact, and reuse until revocation. An agent obtains a credential once and uses it repeatedly, with the token encoding what services, capabilities, and constraints apply. Alternative approaches treat each request as a standalone payment: stateless and simple, but without a persistent credential layer for managing permission hierarchies across agent teams. That means, with L402, multi-agent systems can manage budgets, permissions, and service access programmatically, without a human re-authorizing every sub-task.

Start Building 🛠️

The L402 protocol is production-ready. Lightning Loop has used L402 via Aperture (the L402-aware reverse proxy) since the initial release five years ago.

If you want to get your agents transacting over L402 today, Lightning Agent Tools ships the full stack: an lnd skill for running a Lightning node, lnget for paying L402-gated APIs automatically, aperture for hosting paid endpoints, scoped credential management via the macaroon bakery, and a commerce meta-skill that orchestrates buyer/seller workflows end to end. Read the launch blog post for the full breakdown, or dive straight into the L402 and lnget documentation.

The L402 bLIP specification is open for review and contribution. We invite the community to explore, give feedback, share use cases, and ask questions on the L402 repo. Open source client and server libraries exist in JavaScript, Go, Rust, and Python. The Aperture developer documentation covers server-side setup. And if you're building with agents, the skills work with any framework that can execute shell commands: Claude Code, Codex, OpenClaw, or your own tooling.\

Check out the L402 docs, join our Slack community, follow us on Twitter/X, contribute a PR, or subscribe to our newsletter. The machine-payable web won't build itself. Actually, it might. And the agents are here to help. 🤖