HTTP 402: The Status Code That Slept for 30 Years — and Why It Will Enable the Agent to Agent Economies of the Future

In 1996, the architects of HTTP 1.1 did something unusual. They reserved a status code — 402 Payment Required — for a future they couldn't quite see yet. The spec said simply: "reserved for future use." The vision was micropayments, digital cash, a web where machines could charge machines for resources. Then the future didn't arrive, and 402 sat dormant for nearly three decades.
That future is arriving now. And it's arriving in multiple flavors.

The brief history of a sleeping status code
HTTP's other 4xx codes all had clear jobs. 401 meant unauthorized. 403 meant forbidden. 404 meant not found. 402 meant... eventually, somehow, payment. But "payment" in 1996 had no protocol. No wallets. No settlement layer. Visa and Mastercard were for humans with cards, not machines with API keys. So 402 became the HTTP equivalent of a reserved parking space with no car that could ever fit it.
The web built workarounds. Subscriptions. API keys. OAuth dances. Monthly billing with manual checkout flows. All of it designed for humans sitting at browsers — not for the agent-to-agent economy that was coming.

L402: Bitcoin finally gives 402 a payment layer
Bitcoin's Lightning Network changed the equation. Sub-second settlement. Fees measured in fractions of a cent. Programmable, cryptographically verifiable, requiring no intermediary. It finally provided what the HTTP 402 architects were missing: a working settlement layer.

The result was L402 — a protocol standard that gives 402 Payment Required a real implementation for the first time. The flow is elegant: a client requests a resource, the server responds with a Lightning invoice and a bearer token, the client pays, receives a preimage as proof, and retries with that proof in the Authorization header. No accounts. No API keys. No OAuth. The payment is the authentication.

L402 is implementation-agnostic by design — it runs over the shared BOLT specifications that all major Lightning implementations speak, whether that's Blockstream's spec-first Core Lightning, LND, Eclair, or others. No single vendor owns it. What makes it powerful for the agentic era is that an AI agent can discover an endpoint, pay over Lightning, authenticate, and consume data in a single automated round-trip — no human in the loop, no pre-existing relationship with the server required.

x402: The EVM answer
Coinbase launched x402 in May 2025, reviving the same dormant status code but for the EVM world. Instead of Lightning sats, it uses USDC on Base or Solana. Instead of Lightning invoices, it uses signed payment payloads in an X-PAYMENT header. The flow is the same shape: request, 402 response with payment terms, pay in stablecoin, retry with proof, receive resource.

By December 2025, x402 had processed 75 million transactions worth $24 million. Cloudflare co-launched the x402 Foundation. Stripe began using it in February 2026. Google Cloud integrated it. The coalition backing it — Circle, Alchemy, AWS, Anthropic — signals this isn't a crypto experiment. It's infrastructure.
Both L402 and x402 solve the same core problem: how do machines pay machines, programmatically, at scale, without human-centric billing infrastructure. One is Bitcoin-native, running over the open Lightning specification. One is EVM-native. Both are finally making HTTP 402 mean something.

The coming wave

We are at the beginning of an agent-to-agent economy. AI agents are already consuming paid APIs. Within the next few years, agents will be negotiating services from other agents — buying compute, data, attestations, inference, storage — in real time, at machine speed, across thousands of transactions per hour. L402 and x402 are the payment rails for this.

But payment rails alone aren't enough.

The missing piece: data truth

Here's the problem that nobody is talking about yet.

When an agent pays for data — a price feed, a sensor reading, a market signal — it receives a number. But how does it know that number is accurate? How does it verify the source? How does it prove to another agent or to an on-chain contract that the data it received was legitimately sourced, multi-exchange aggregated, and signed at a specific point in time?

In a world of autonomous agents transacting at scale, the payment problem is solved. The data truth problem is not.

An agent can pay 10 sats for a BTC/USD price. But without a cryptographic signature, a source attestation, and a canonical message format — it just has a number from somewhere. It can't verify it didn't come from a single exchange with a flash crash. It can't submit it on-chain with proof of provenance. It can't delegate it to another agent with the signature intact.

This is the gap we built Mycelia Signal to fill.

Sovereign oracle infrastructure for the agent economy

Mycelia Signal is a cryptographically signed price oracle that natively serves both L402 (Lightning sats) and x402 (USDC on Base). Every response includes not just a price, but a full signed attestation: exchange sources listed, UTC timestamp, canonical message format, and a verifiable ECDSA or Ed25519 signature — depending on which payment rail the agent used.

The flow is exactly what L402 and x402 were designed for: one HTTP call, automatic payment, signed data back. No API keys. No accounts. No trust assumptions.
An agent querying BTC/USD over L402 pays 10 sats and receives a secp256k1-signed attestation aggregated across 9 exchanges. An EVM-native agent pays $0.01 USDC and receives the same price with an Ed25519 signature. Both signatures are independently verifiable without calling home.

This matters for three reasons:

DeFi and smart contracts need price feeds backed by cryptographic proof — signatures that on-chain contracts can validate without trusting the transport layer.

AI agents need data they can pass to other agents, stake on decisions, or submit to protocols — with the signature intact so downstream consumers can verify the provenance without talking to the oracle again.
Regulatory compliance — the SEC/CFTC tokenized collateral framework, the FCA's CP25/40, and MiCA's July 2026 deadline all point toward mandatory independent price attestation. A second signature proving the price was independently sourced isn't a nice-to-have; it's becoming infrastructure.

Why this moment

HTTP 402 waited 30 years for a payment layer. The open Lightning specification (BOLTs) and the x402 standard finally delivered it. The next frontier is data integrity in the agent economy — not just can an agent pay, but can an agent trust what it paid for, and can it prove that trust to the next agent in the chain.

Signed attestations are to data what cryptographic proofs of payment are to transactions. Both are necessary for a machine-to-machine economy that doesn't rely on human trust at every layer.

We're live on mainnet — Lightning mainnet, Base mainnet — serving signed price attestations for BTC, ETH, EUR, gold, SOL, and more, over both rails. MCP server included for agent workflows.

Happy to answer questions about the architecture, the signing schemes, or how agent-to-agent data attestation works in practice.

→ myceliasignal.com Sonnet 4.6