Every comparison of agent payment protocols asks the same question: how does the money move? L402 moves it over Lightning. x402 moves it onchain. MPP, AP2 and ACP each layer their own authorization model on top.

That question is close to settled. The one nobody asks is what happens next.

A payment protocol tells you that a buyer paid. It does not tell you what the buyer receives, whether the seller committed to delivering it, or what happens if the seller's server is switched off. For a live API those questions barely matter — the response is generated on demand, and if the server is down there is nothing to sell anyway. For anything that exists as content rather than as request handling, they are the entire problem.

This is a comparison of the delivery model, not the rail.

What L402 actually does

L402 is Lightning Labs' Lightning HTTP 402 protocol. It pairs a macaroon — described in the spec as a cryptographic bearer credential — with a Lightning payment.

The flow is five steps:

1. The client requests a gated endpoint.
2. The server returns 402 Payment Required with a macaroon and a Lightning invoice in the WWW-Authenticate header.
3. The client pays the invoice over Lightning, receiving a payment preimage as proof of payment.
4. The client re-sends the request with both in the Authorization header.
5. The server verifies the credential and serves the resource.

The exact header shapes are:

WWW-Authenticate: L402 macaroon="<base64>", invoice="<bolt11>"
Authorization:    L402 <base64(macaroon)>:<hex(preimage)>

The design is genuinely elegant. As the spec puts it, the macaroon "cryptographically commits to the payment hash of the invoice, so the server can verify payment using only the macaroon and preimage. No database lookups or session state required." Lightning invoices are locked to a payment hash, and only a completed payment reveals the preimage that hashes to it, so presenting one is unforgeable proof that a specific invoice settled. Macaroons also support attenuation: a holder can mint a weaker version of their credential to delegate narrower access.

What the preimage proves is that a payment happened. What it authorizes is a request.

What x402 actually does

x402 revives the same status code and settles onchain rather than over Lightning.

The flow uses three headers, each carrying Base64-encoded JSON:

1. The client makes an initial request.
2. The server responds 402 with PAYMENT-REQUIRED, holding the payment details.
3. The client retries with PAYMENT-SIGNATURE, holding the payment authorization.
4. The server responds with PAYMENT-RESPONSE, holding the settlement outcome.

Its reach is much broader than Lightning's. x402 supports tokens on EVM (any chain via eip155:<chainId>), Solana, TON, Algorand, Stellar, Aptos, Hedera, Keeta, NEAR, Concordium and XRPL. It is also not a stablecoin-only protocol — on Solana it accepts any SPL or Token-2022 token, with USDC offered as a default convenience rather than a restriction. Agents that price work in dollars can use a stablecoin and avoid exchange-rate risk, but nothing forces that.

It is worth noting that x402 defines more than one payment scheme. Exact is the fixed-price case, where the buyer authorizes precisely the advertised amount. Upto is usage-based: the buyer authorizes a maximum and the seller charges actual usage. Batch Settlement adds escrow and off-chain vouchers with batched onchain redemption. So "one payment, one request" describes Exact well and Upto only loosely.

Still, strip away the rail and the schemes and x402 answers the same question L402 does: may this client have this resource?

What both leave open

Because they gate a request rather than an artifact, L402 and x402 inherit the same three constraints.

The seller must be online. The server issues the challenge, verifies the payment, and generates the response. No server, no sale. Your revenue has your uptime as a hard ceiling.

Nothing commits the seller to a response. The buyer pays, then discovers what they bought. There is no hash published in advance, no signed terms, nothing to check the delivered bytes against. In practice this is fine when you are buying a weather lookup from a reputable endpoint and much less fine when you are buying a dataset for real money from a counterparty you have never transacted with. Neither protocol offers the buyer recourse, because neither protocol has an opinion about payloads.

You cannot sell bytes, only responses. You can certainly return a file from behind an L402 or x402 gate. But the file is whatever your server hands over at that instant, and the protocol has no view on whether it is the file that was advertised.

None of this is a flaw. Both protocols solve authorization, and they solve it well. It is simply that authorization is not delivery, and the agent economy keeps treating the two as the same problem.

The settlement model

The alternative is to make the payment proof release a pre-committed artifact rather than authorize a live request.

Concretely, in the model Hypawave implements:

Content is sealed before it goes on sale. The seller uploads encrypted bytes and declares ciphertext_sha256, the SHA-256 of exactly those bytes. When the activation fee settles, the server streams the stored object back, re-hashes it, and compares. A mismatch fails activation instead of producing a live offer. On a match the bytes are sealed: copied server-side to a storage key the creator never received an upload URL for. That last step matters more than it sounds. Presigned upload URLs stay writable for their lifetime, so without sealing a seller could verify one payload and swap in another afterwards. Sealing closes that window.

The enforcement is conditional in one respect worth stating plainly: it applies when every file on the offer carries a declared hash. Offers predating the commitment scheme still activate, with no content hash recorded.

Terms are hashed and enforced. A terms_hash covers amount, currency, pricing type, description, payment destination and a mint-time sats snapshot. A buyer reads the terms, captures the hash, and presents it when paying. If anything changed in between, the pay endpoint returns 409 terms_changed rather than accepting the payment. You cannot be quoted one price and charged another.

The buyer verifies what arrived. After settlement the buyer receives the decryption key and the committed ciphertext_sha256, re-hashes the downloaded ciphertext, and aborts on mismatch before decrypting. The seller committed to specific bytes; the buyer can prove they got them.

Release is metered, exactly once per payment. Capacity is a finite number of unlock slots rather than a reusable session credential, and one settled payment entitles the buyer to one unlock that cannot be replayed for a second. The buyer can still re-fetch their own key if a download fails, so a dropped connection does not cost them what they bought.

For sealed content, the seller can be offline. The bytes are already sealed in storage and the key releases on verified settlement, so nothing needs generating at purchase time. This is the sharpest break from request gating — but it is specific to content. An offer that runs a job on the seller's own infrastructure works differently: settlement hands the preimage to both sides, the buyer presents it to the seller's API as its credential, and the seller executes. That path needs the seller up, exactly as L402 and x402 do.

The payment primitive is unchanged throughout. It is still SHA256(preimage) == payment_hash — the same check L402 performs, because that is simply how Lightning works. What differs is what that proof is wired to.

Side by side

	L402	x402	Settlement model
Rail	Lightning	Onchain, 11 network families	Lightning
Assets	sats	any supported token	sats
Proof	macaroon + preimage	signed payment header	preimage
Authorizes	a request	a request (Exact / Upto)	an artifact release
Seller online required	yes	yes	no, for sealed content
Content committed pre-payment	no	no	yes (ciphertext_sha256)
Terms fixed at quote	no	no	yes (terms_hash, 409 terms_changed)
Buyer can verify delivery	no	no	yes
Release semantics	reusable credential	per payment	one unlock slot per payment
Sells	API responses	API responses	files, data, responses

When each is right

Use x402 if you are metering an API you already run and your users hold tokens on a supported network. It has by far the widest reach and the most widely installed tooling, and its usage-based Upto scheme fits metered work well.

Use L402 if you are metering an API you already run and want Bitcoin Lightning — genuinely sub-cent pricing, sub-second settlement, no chain fees eating a 3-sat call, and stateless verification with no database lookup.

Use a settlement and delivery layer if what you are selling is not a live request: a file, a dataset, a model output, a report. Or if you have no server at all and do not want one. Or if the buyer needs to know what they are getting before they pay for it.

The honest summary is that these are not competing answers to one question. L402 and x402 answer may this request proceed. A settlement model answers what did the buyer actually receive, and can they prove it. If you are selling request handling, the payment protocols are correct and simpler, and adding a delivery layer buys you nothing.

The moment you are selling bytes, they stop having an answer.

Further reading

• Hypawave architecture — how settlement proof, content sealing and key release fit together
• Agent API reference — the accountless pubkey-signed flow described above
• llms.txt — the machine-readable version an agent can act on directly
• L402 protocol specification — Lightning Labs' spec
• x402 documentation — the official docs