x402 vs L402: Stablecoins vs Lightning for APIs

HTTP status code 402 — Payment Required — shipped with the original HTTP spec in 1997. For twenty-eight years, nobody could use it. There was no payment system fast enough, cheap enough, or programmable enough to settle a transaction in the middle of an HTTP request-response cycle. Stripe needs seconds and takes 30 cents. Wire transfers need days. PayPal needs a human clicking "confirm."

Then two protocols showed up, within five years of each other, both claiming to finally make 402 work.

L402 came first. Lightning Labs published the spec in 2020 under the name LSAT, later renamed to reference the status code it activates. It settles payments in Bitcoin over the Lightning Network using macaroons — cryptographic tokens that make verification stateless. It's been in production for six years, gating access to services like Lightning Loop and Lightning Pool through Aperture, Lightning Labs' L402 reverse proxy.

x402 arrived in 2025. Coinbase published it with backing from Cloudflare, and the x402 Foundation followed shortly after. Vercel built an x402-MCP integration. Google and Coinbase built AP2 — the Agent Payments Protocol — on top of x402 as the settlement rail. It settles in USDC stablecoins on EVM chains, primarily Base and Solana. That gave it immediate distribution in ecosystems developers already use.

Both protocols solve the same problem: software pays for software, inline, without accounts or API keys. They make fundamentally different bets about which money machines should use, who verifies the payment, and how much of the stack you need to trust.

The shared idea

The protocol flow is nearly identical. Three steps:

1. Client requests a resource
2. Server responds with 402 Payment Required and a payment challenge
3. Client pays, retries with proof, gets the data

One roundtrip beyond the original request. The payment is the credential. No signup, no billing page, no API key management. That shared design is what makes both protocols interesting — and what sat impossible for three decades before payment rails got fast enough.

The divergence is in what happens inside steps 2 and 3.

How x402 works

The server responds with a 402 containing payment terms: a price in USDC, a recipient address on an EVM chain, an expiry window. The client holds a USDC balance in a wallet — EOA or smart contract — signs a payment transaction, and includes the signed proof in the retry request.

The server — or, more commonly, a facilitator — verifies that the on-chain payment landed. Coinbase is the primary facilitator in the x402 ecosystem. The facilitator checks the chain, confirms the amount and recipient, and signals the server to grant access.

Settlement depends on the chain. Base completes in 1–3 seconds. Solana under a second. Gas costs add a small floor — roughly $0.001–0.01 on Base, similar or less on Solana.

Pricing is dollar-denominated. If your API call costs $0.005, it costs $0.005 today and next month regardless of what any cryptocurrency did. For commerce and business APIs, that stability removes an entire category of headaches.

How L402 works

The server responds with a 402 containing two things: a Lightning invoice (a BOLT11 payment request denominated in satoshis) and a macaroon — a cryptographic bearer token with the payment hash embedded as a caveat.

The client pays the Lightning invoice through any Lightning wallet. Payment settles in milliseconds and produces a preimage — a 32-byte secret that cryptographically proves the invoice was paid. The client combines the macaroon with the preimage and sends both as an Authorization header.

The server verifies the macaroon's HMAC signature chain and checks the preimage against the embedded payment hash. Both are local cryptographic operations. No database lookup. No facilitator. No network call. Verification takes microseconds.

Pricing is in satoshis. At ~$100k BTC, 10 sats is roughly $0.01. That number moves with Bitcoin's price — a real consideration that deserves its own section below.

Where they actually differ

The sequence diagrams look almost identical. The differences are in the machinery underneath, and those differences compound at scale.

Verification model

This is the most consequential technical distinction between the two protocols.

x402 verification means confirming that a USDC payment actually landed on-chain. The server either queries the chain directly through an RPC node, or delegates to a facilitator (Coinbase) that watches the chain on its behalf. Either way, it's a network call with latency, and it introduces a dependency. If the facilitator is down or the RPC endpoint is slow, verification stalls.

L402 verification is stateless. The macaroon is a self-contained proof: root signature, caveats (including the payment hash), HMAC chain. The preimage satisfies the payment caveat. The server verifies the chain and checks the preimage using only the root key it holds in memory. No network round-trip, no external service, no database row.

At 10 requests per second, you probably won't care. At 1,000, you probably will. A local cryptographic check is simply easier to operate than another network hop in the middle of every paid request.

Settlement speed

Lightning settles in milliseconds. The full L402 cycle — challenge, payment, verification, data — routinely completes in under a second.

x402 on Base settles in 1–3 seconds. On Solana, under a second. Both fast enough for a human clicking a button. For an agent making hundreds of sequential calls where each depends on the last, every second of latency per call becomes minutes per workflow.

Cost floor

Lightning routing fees are typically under 1 sat — a fraction of a cent. Charging 1 sat per API request is economically viable. The protocol has no practical minimum.

x402 on Base carries gas costs around $0.001–0.01 per transaction. Solana is similar or lower. Both are cheap by traditional standards — cheaper than any credit card — but Lightning has a lower floor. For APIs priced in fractions of a cent, that floor matters.

Price stability

x402's strongest argument. USDC is pegged to the US dollar. An API endpoint priced at $0.005 costs $0.005 today, next week, and next quarter. You don't think about exchange rates. Your users don't think about exchange rates. Accounting is straightforward.

L402 prices in satoshis, and satoshis move with Bitcoin. A 10-sat charge is worth ~$0.01 at $100k BTC. If Bitcoin doubles, you're collecting twice the dollar value for the same work. If it halves, half. For sub-cent API calls, most developers absorb this as noise — the amounts are too small to care about. For higher-value transactions or APIs where margin matters, the volatility is real.

Mitigations exist: price in fiat and convert to sats at request time, use narrow time windows so the price doesn't drift far, or accept that sats are the native unit and stop thinking in dollars. None of these fully erase the issue. If your API must cost exactly $0.005, x402 gives you that without effort.

Trust model

This is where the design philosophies fork.

USDC is issued by Circle. Circle can freeze or blacklist any USDC address at any time — they have done so, repeatedly, under regulatory pressure and law enforcement requests. Your x402 payment rail works until the stablecoin issuer decides it doesn't.

Base is a Layer 2 rollup operated by Coinbase. The sequencer — the component that orders and processes transactions — runs on Coinbase's infrastructure. If Coinbase's systems go down, Base transactions stall. If Coinbase censors a transaction, the rollup's forced-inclusion escape hatch is measured in hours, not milliseconds.

Lightning runs on top of Bitcoin. Tens of thousands of nodes operated independently across the world, secured by proof-of-work consensus that no single entity controls. Nobody can freeze your sats, censor your payment, or unilaterally shut down the network. The tradeoff: nobody's running a VC-funded marketing campaign for it either.

On a normal Tuesday, none of this matters. Payments clear, APIs work, nobody gets censored. But infrastructure decisions aren't made for normal Tuesdays. If you're building a system that needs to work without trusting a single company — or if your users operate in jurisdictions where that trust is a liability — the layer underneath the protocol matters more than the protocol itself.

Ecosystem and distribution

x402 has Coinbase, Cloudflare, and Vercel. Vercel's x402-MCP integration connects agent payments to the Vercel deployment ecosystem. Google and Coinbase's AP2 positions x402 as the payment rail for the broader agent economy. If you're building on Base, Solana, or anywhere in the Coinbase orbit, x402 is the path of least resistance.

L402 has Lightning Labs — the team behind LND, the dominant Lightning Network implementation — and six years of production history. In February 2026, Lightning Labs open-sourced lightning-agent-tools, a toolkit of seven composable skills for agents operating on Lightning, including lnget, an L402-aware HTTP client. The ln.bot MCP server connects any MCP-compatible agent to Lightning. The L402 ecosystem is smaller but purpose-built for the agent use case.

Neither has won. Both have real deployments and real teams shipping. The ecosystem you're already in often makes the decision for you before the technical comparison matters.

What this means for agents

Both protocols promise the same thing to AI agents: encounter a paywall, pay it autonomously, move on. Both deliver. The differences matter at the margins — and agents operate at the margins.

An agent orchestrating 500 API calls per workflow needs:

Low latency per call. L402 settles in milliseconds. x402 on Base usually takes 1–3 seconds, less on Solana. On one request, that gap barely matters. On a long agent workflow with hundreds of paid calls, it adds up fast.

Reliable verification. L402's stateless verification has zero external dependencies — if the server is up, verification works. x402's facilitator model adds a dependency that can fail, slow down, or rate-limit independently of your server. One more thing to monitor, one more thing that can page you at 3am.

Budget enforcement. Both protocols support spending controls. L402 clients like ln.bot's SDK enforce maxPrice per transaction and budgetSats per period. x402 clients enforce limits at the wallet or smart contract level. Comparable on this axis.

Discoverability. Identical. An agent sees a 402 response and reads the WWW-Authenticate header to determine which protocol the server speaks. An agent carrying both a Lightning wallet and a USDC wallet handles either. In practice, most agents carry one.

For agent-to-agent commerce — where the speed and frequency of transactions compound — L402's millisecond settlement and zero-dependency verification create a structural advantage. For occasional, higher-value API calls where dollar pricing simplifies the business logic, x402 is cleaner.

Side by side

When to use which

Choose L402 when:

• Your consumers are AI agents making frequent, small payments
• You want verification with zero external dependencies
• You're building permissionless infrastructure — no geographic restrictions, no KYC, no issuer that can freeze funds
• You need the lowest possible latency and cost per transaction
• You're already in the Bitcoin/Lightning ecosystem

Choose x402 when:

• You need dollar-stable pricing for commercial APIs
• You're building on Base, Solana, or in the broader Coinbase/EVM ecosystem
• Your consumers are primarily EVM wallet holders
• Transaction frequency is moderate and latency tolerance is generous
• You want the institutional backing of Coinbase, Cloudflare, and Vercel

Both work when:

You want to maximize your addressable market. A server can issue either challenge type depending on the client's capabilities. A client with wallets on both rails handles either protocol. The implementation complexity increases, but the reach doubles.

The real significance

For thirty years, HTTP 402 was a dead status code — a placeholder with no payment system to back it up. Now it has two working implementations, and they reflect two different instincts about internet money.

x402 is the more familiar bet: keep pricing in dollars, settle with stablecoins, and lean on large companies to make the UX predictable.

L402 takes the opposite approach: settle in Bitcoin over Lightning, verify locally, and keep third parties out of the request path as much as possible.

They'll probably coexist because they're solving slightly different problems. The "Bitcoin vs stablecoins" framing misses the more important shift: software can finally pay for software, inline, without accounts or human approval. That's the part that would have sounded unrealistic a couple of years ago.

The choice between x402 and L402 isn't about which cryptocurrency you believe in. It's about what your system needs: stable pricing or stateless verification, institutional partnerships or permissionless access, dollars or sats. The L402 protocol deep-dive covers the macaroon mechanics. The pay-per-API-call guide walks through the full server and client implementation. The agent payments guide covers giving your agent a wallet on either side.