Quick Summary
May 2025
x402 (Coinbase) and h402 (BitGPT) are new payment protocols that work by implementing the long-ignored HTTP 402 Payment Required status code. Their shared insight is that payment can be treated as a standard HTTP concern, enabling the next generation of autonomous, metered, accurate commerce over the public Internet. x402 is the original, minimal schema put out by Coinbase a couple months ago. h402 is a newer superset built by BitGPT that keeps the x402 format but add a richer, five-stage lifecycle and works with more blockchains.
When a user (or agent) requests a monetized online resource, the server, instead of immediately granting access or showing a typical paywall, can reply with this 402 code. This response includes a JSON descriptor detailing the acceptable cryptocurrencies (including stables), the required amount, and the blockchain network where the payment can be settled. This is particularly useful for AI agents as they can handle all this in just a few hundred milliseconds without relying on API keys, credit cards, or separate billing flows.
x402 is the original, minimal schema.
h402 is a newer superset built by BitGPT that keeps the x402 wire format but adds a richer five-stage lifecycle and multi-network settlement.
Once money moves inside the request/response headers, every API on the planet can sell compute, data, or content to machines at the speed of the Internet.
x402 in a nutshell
| Phase | What happens | Where it lives |
|---|---|---|
| 1) Request | Agent asks for /resource | Normal GET /resource |
| 2) 402 Response | Server returns HTTP 402 with a JSON payload that states maxAmountRequired, payTo, asset, network, expiresAt, etc. | Response body & headers (x402) |
| 3) Signed payment | Client signs an EIP-712 message or broadcasts a USDC transfer ≤ maxAmountRequired and retries the same request, attaching the signature/tx-hash in a header. | Request headers |
| 4) Verification & settle | Server verifies the signature or sees the tx in mempool, then serves the resource. | Server middleware |
Key properties
- Works today with ERC-20 tokens (USDC) on Base/Ethereum, but the JSON schema is chain-agnostic.
- Keeps fees near-zero (just on-chain gas) and achieves ~200 ms settlement on L2s
h402 in a nutshell
h402 inherits the x402 schema but layers on a deterministic, audit-friendly flow: Quote → Authorize → Broadcast → Validate → Settle
| Stage | Artifact (hash-stable) | Retry-safe? |
|---|---|---|
| Quote | quote.json (price, routes, nonce, expiry) | ✅ |
| Authorise | auth.sig (permit, PSBT, delegated spend) | ✅ |
| Broadcast | txHash / Lightning pre-image | ✅ |
| Validate | receipt.json (confirmations) | ✅ |
| Settle | settled.json (FX, status) | ✅ |
Enhancements over x402
- Multi-treasury out of the box – EVM, Solana, Bitcoin, and Lightning, not just permit-based ERC-20s.
- Post-broadcast validation & polling so Bitcoin-style confirmation logic is possible.
- Header-only option for edge functions: all artifacts can travel inside standard HTTP headers, no body parsing required.
- Built-in pathways for future payment schemes (upto, streamed, subscription) and facilitator smart-contracts.
The BitGPT maintainers stress that they “preserve the protocol schema, but refuse to be limited by someone else’s tech stack,” hence why they forked x402. (cdn.h402.xyz)
Key shared insight
- HTTP already has a payment primitive, 402. Tim Berners-Lee just left it unused.
- If you surface price, route, and proof inside the same request/response that carries the data, you eliminate separate billing rails, human sign-ups, and delayed batch settlement.
- This unlocks agent-to-agent commerce: an LLM script can spin up GPUs, buy context, pay per function call, and stream results without ever touching fiat rails.
How to decide which to implement
| Need | Choice |
|---|---|
| Quick USDC pay-per-API on Base/Ethereum | x402 minimal middleware |
| Multiple chains (BTC, Solana), non-permit tokens, confirmation-aware flows | h402 |
| Future-proof schemas (streamed, subscription) | h402 |
| Tight coupling to Coinbase tooling | x402 |
Because h402 is intentionally backward-compatible, a service that speaks h402 can interoperate with any x402-capable client that only needs the core Quote + Authorize flow.
Sources
h402 white-paper & lifecycle description (cdn.h402.xyz, cdn.h402.xyz)
h402 GitHub README (builds on x402) (GitHub)
x402 white-paper abstract, flow, and spec details (x402, x402, x402)