Title: X402 Explained: HTTP Native Micropayments for AI Agents

The X402 spec reuses the standard HTTP 402 Payment Required status to turn a regular API call into an on-chain micropayment. AI agents can now settle fees for LLM queries or data feeds without a human, and providers can charge per request without building a custom invoicing system.

Why AI agents need a payment protocol

Autonomous agents stitch together language models, web-search tools, and proprietary data sources. Each stitch costs something—per-token fees for a model or per-call charges for a market-data API. Today’s business models rely on API keys tied to subscription accounts, manual credit top-ups, or post-hoc billing. Those methods break the “no-human” promise of autonomous agents and add operational overhead for providers.

X402 offers a middle ground: a request-response flow that looks like any other HTTP call, but with a built-in payment step recorded on a public blockchain. The only requirement is that the client can sign and broadcast a transaction on the chain the server specifies.

The X402 handshake in detail

  1. Initial request – The agent sends a normal GET or POST to a paid endpoint. No special headers are needed.
  2. Server replies with 402 – The response carries status 402 and a JSON body that lists:
    • amount – the fee the server expects, in the smallest token unit;
    • token – the ERC-20 (or equivalent) contract address;
    • chain – the blockchain identifier where payment must be recorded;
    • optional nonce – a unique value that stops replay attacks.
  3. Client prepares payment – The agent checks the token address and chain against its policy (e.g., only trusted chains). It then creates a transaction that transfers the required amount to the server-provided address, signs it with its private key, and broadcasts it.
  4. Payment hash submission – When the transaction hash is available, the client repeats the original request, this time adding an X-Payment header that contains the hash. The payload stays unchanged.
  5. Server verifies on-chain – The server looks up the blockchain for a confirmed transfer that matches the amount, token, chain, and nonce. If it finds a match, it returns the requested data with a 200 OK status.

Any HTTP client library that supports custom headers and can call a blockchain SDK can perform these steps. No new transport protocol or custom socket layer is required.

Trade-offs to keep in mind

  • Latency – Public-chain confirmation adds delay.
  • Gas costs – Even cheap chains charge gas; payments under $0.001 may be uneconomical.
  • Complexity – Agents must handle failed transactions and chain reorganizations; robust retry logic is a must.
  • Security – The nonce stops replay attacks, but agents still need to safeguard private keys and avoid reusing them across unrelated services.