Short answer: x402 and x401 are two HTTP challenge-and-retry protocols for agents that solve different problems. x402 uses status 402 and a PAYMENT-REQUIRED header to ask for money; x401 uses a PROOF-REQUEST header, with status 401 in the spec's examples, to ask the agent to prove which verified person it acts for and what that person approved. They are written to run one after the other on the same request, not to replace each other: x401's own spec reserves 402 for "an appropriate payment protocol" and hints at x402 by name. As of 18 October 2026, x402 is a Linux Foundation project with tens of millions of transactions a month; x401 is a draft specification from one identity company, launched publicly on 15 October 2026 with a wallet, the published protocol and an MCP server.
Some background: x402 lets a client, usually an AI agent, pay for an HTTP request in stablecoins, and it has been covered on this blog from the payment challenge to the facilitators. The number in its name is the HTTP status code it builds on. x401 borrows the pattern and the naming: 401 is the status code for "unauthorized", and the protocol's full name is the "HTTP Proof Requirement Protocol". The obvious question is whether it competes with x402, extends it, or has nothing to do with it. The specifications answer that.
What each one is
x402 was started at Coinbase and contributed to the x402 Foundation, which the Linux Foundation announced as operational in July 2026 with 40 member organizations, among them Adyen, AWS, Circle, Cloudflare, Coinbase, Google, Mastercard, Stripe and Visa. The v2 specification defines PaymentRequired, which a server sends when a request needs payment, PaymentPayload, which the client sends back with a signed transfer, and SettlementResponse, the receipt. The x402.org home page reported 75.41 million transactions, $24.24 million in volume, about 94,000 buyers and 22,000 sellers over the last 30 days when we read it on 18 October 2026.
x401 was published by Proof, an identity-verification company, first as a draft in June 2026 and as a public launch on 15 October 2026. The launch release lists three parts: a consumer identity wallet in which the person reviews and approves what an agent is about to do, the protocol itself, and an MCP server that the release says works with Meta's Muse, ChatGPT, Grok, Claude and other MCP clients (for how MCP servers charge, see x402 over MCP). The specification is at version 0.2.0 and marked as a draft; the repository is under the Apache 2.0 license, and Proof says it intends to move the protocol under neutral governance. Those are Proof's statements; we found no independent implementation to verify them against.
The two challenges side by side
| x402 | x401 | |
|---|---|---|
| Asks for | Payment | Proof of a verified identity and of what the person approved |
| Status code | 402 | Independent of the proof state; examples use 401, and a PROOF-REQUEST may accompany 2xx or 4xx responses |
| Server to client | PAYMENT-REQUIRED: base64 JSON PaymentRequired |
PROOF-REQUEST: base64url JSON with scheme: "x401", version, credential_requirements |
| Client to server | PAYMENT-SIGNATURE: base64 JSON PaymentPayload |
PROOF-RESPONSE: a result artifact or an x401 token object |
| Receipt or error | PAYMENT-RESPONSE: success, transaction, network, payer |
PROOF-RESULT: an x401 error object or other response information |
| What gets signed | An EIP-3009 transfer of a fixed amount to a fixed address (exact scheme), signed by the agent's wallet |
A presentation of credentials signed in the person's wallet, requested through the W3C Digital Credentials API using OpenID4VP and a DCQL query |
| Third party | A facilitator that verifies and broadcasts the transfer | A credential issuer and a wallet; Proof's launch uses its own certificate authority |
| Reusable session | None; every request is paid separately. The v2 spec defines a generic extensions field |
Optional OAuth 2.0 token exchange turns one proof into a short-lived bearer token |
Sources: the x402 HTTP transport spec, the exact EVM scheme and the x401 specification.
Three details from the x401 spec worth knowing if you implement either side:
- Each header carries exactly one base64url-encoded JSON object. A header with several field lines or a comma-separated list is invalid. x402 uses plain base64; x401 uses base64url without padding.
WWW-Authenticateis explicitly not used. x401 does not plug into HTTP's built-in authentication header; the proof requirement travels inPROOF-REQUEST(or, for browser clients, embedded in HTML), never inWWW-Authenticate.- The header names changed between drafts. A June 2026 write-up by Proof's Daniel Buchner used
PROOF-REQUIRED,PROOF-PRESENTATIONandPROOF-RESPONSE, withPROOF-RESPONSEflowing from server to agent. The current spec and README usePROOF-REQUEST,PROOF-RESPONSEandPROOF-RESULT, andPROOF-RESPONSEnow flows from agent to server. Code written against the earlier article will send the wrong header in the wrong direction.
How they chain on one request
The x401 spec keeps payment out of scope on purpose: it says 402 is reserved for payment, which x401 does not define, and its security considerations include a section on payment separation. The hook between the two is a small optional payment object in the PROOF-REQUEST payload with required, scheme_hint and notes; the spec's example sets scheme_hint to "x402". So a resource that needs both looks like this from the agent's side:
GET /resourcewithout anything. The server answers 401 withPROOF-REQUEST, and the payload may say payment will be required too.- The agent obtains a presentation from the person's wallet and retries with
PROOF-RESPONSE. - The server validates the proof. If payment is still owed it answers 402 with
PAYMENT-REQUIRED, and the ordinary x402 loop runs: the agent signs a payment and retries withPAYMENT-SIGNATURE. - The server verifies and settles through its facilitator and returns the resource with
PAYMENT-RESPONSE.
An agent that already has a verification token from the optional OAuth exchange can skip step 2 on later requests by sending it as a bearer token. Nothing in x402 changes; a paid endpoint that adds x401 is still the same paid endpoint, with one more challenge in front of it.
What this means if you build agents
- They answer different trust questions. x402 tells the server it has been paid; it says nothing about who the buyer is beyond a wallet address, and some facilitators screen payments against sanctions lists on top (facilitators compared). x401 tells the server which verified person stands behind the agent and what they signed off on, so a dispute later has evidence. Neither tells the agent anything about the server. Whether an endpoint is up, charges what it advertises and pays out to the address it did last week is a separate question, which is what ToolVet's checks and the free x402 checker are for.
- Expect x401 at the kind of endpoints that would otherwise ask for a login. Account opening, age-gated content, anything with legal weight. Proof's release names identity claims such as legal name, age and nationality at a required assurance level, and a signature over transaction terms. A data API priced at a fraction of a cent has little reason to add a human approval step per call. Note that ToolVet's check expects an unpaid request to get a 402 with a payment challenge, so an endpoint that answers 401 with a
PROOF-REQUESTfirst would fail the check as it runs today. - The human stays in the loop by design. In Proof's wallet, per the release, the person authenticates on their own device and signs the specific terms; if the agent changes an amount or recipient afterwards, verification fails. That is a different model from the spend caps in x402 client SDKs, where the agent pays within a cap without asking. If you run agents that do both, make sure the client's
maxAmountPerPaymentcap (see the spend-control notes) matches what the person approved in the x401 step, since the two are enforced in different places. - Watch the spec, not the press release. Version 0.2.0 is a draft with an "Open Questions & Future Additions" section (one item is "Machine Payments and 402"), one third-party implementation named at launch, and header names that have already changed once. x402 v2 has shipped SDKs, a foundation and a catalog (the Bazaar). Treat x401 as something to read now and implement when a resource you need demands it.
Frequently asked questions
Is x401 a replacement for x402?
No. x401 handles proof of identity and approval and leaves payment to "an appropriate payment protocol" under status 402; its payload can hint at x402 as that protocol. A resource that needs both sends the x401 challenge first and the x402 challenge after the proof is accepted.
Which headers does x401 use?
PROOF-REQUEST from the server to the agent, PROOF-RESPONSE from the agent back, and PROOF-RESULT for the server's errors or other results, each carrying one base64url-encoded JSON object. An earlier draft used PROOF-REQUIRED, PROOF-PRESENTATION and PROOF-RESPONSE with different directions, so check which version an implementation follows.
Does x401 use HTTP 401 the way x402 uses 402?
Not quite. x402 is tied to 402. x401 says the status code is independent of the proof state: the examples use 401, but a PROOF-REQUEST may accompany a 2xx or 4xx response, and the protocol deliberately does not use WWW-Authenticate.
Who is behind x401 and is it open?
Proof, an identity-verification company, wrote it and runs the first wallet and MCP server. The specification is public under the Apache 2.0 license at version 0.2.0 (draft), and Proof says it intends to move it to neutral governance. x402, by comparison, is governed by the x402 Foundation under the Linux Foundation.
Do I need x401 to pay x402 endpoints?
No. x402 payments work without any identity layer. You need x401 only when a specific resource sends a PROOF-REQUEST. ToolVet's checks, as of 18 October 2026, record the 402 challenge and nothing about identity; how we check and score explains what they record.