What Is x401? Proof's Agent Identity Protocol, Checked Against a Live x402 Endpoint
x401 is Proof's open, HTTP-based proof-requirement protocol: a server answers with a 401 plus a PROOF-REQUEST header naming the credential an agent must present — personhood, residency, accreditation, membership, or a signed authorization — and the agent retries with PROOF-RESPONSE. It is deliberately separate from payment: x401 proves who stands behind an agent and what that person approved; HTTP 402 plus x402 still handles the money.
On October 15, 2026, Proof put the identity side into production: an agent identity wallet (verified legal identity; the person approves on their own device with a biometric; changing a signed amount or recipient invalidates the signature), the x401 protocol, and a production MCP server. Websites can also pay Proof per identity claim over x402.
The quotable measurement: ScriptMasterLabs' October 16, 2026 probe of its own live Verdict Protocol endpoint found the payment and decision layers live — HTTP 402 quoting $0.25 USDC on Base, status LIVE_SETTLEMENT_VERIFIED — and the identity layer absent: no PROOF-REQUEST, PROOF-RESPONSE, or PROOF-RESULT header on the response.
Today's live probe (October 16, 2026, ~09:20 EDT)
-
GET https://verdict.scriptmasterlabs.com/health→ 200 (4.09s, single measurement) -
GET /.well-known/agent.json→LIVE_SETTLEMENT_VERIFIED; /decide $0.25 USDC BYOK, /seal $0.01, Base (eip155:8453) -
POST /decidewith no payment → HTTP 402; response headers exposePAYMENT-REQUIRED, PAYMENT-RESPONSE— and noPROOF-*header of any kind - Directory context the same morning: x402 List counts 1,021 services listed, 959 payment-ready, only 13 delivery-verified; the CDP Bazaar discovery total read 43,089 (limit=100) vs 37,267 on Oct 14 by the same method — two readings, not a growth claim
The layer x401 does not cover
A signed mandate proves a person approved those terms. It does not score whether the instruction inside the mandate is wise — a person can sign a bad purchase. The stack needs all three, in order: x401 evidence first (who/what approved), a decision gate second (≥0.80 auto-pay, 0.50–0.79 confirm, <0.50 escalate), x402 settlement last.
Honest caveats
- x401 is a draft (0.2.0), not a finished standard; 0.2.0 broke with 0.1.0, so explainers using the old header names are stale.
- SML has not implemented x401 — this is a gap measurement of our own endpoint, not a product claim.
- Proof's "first into production" framing is Proof's own statement in its launch release.
Full canonical with the dated receipts table, Claim Receipts and the DIY header audit: https://scriptmasterlabs.com/what-is-x401
Top comments (5)
Splitting identity from payment is the right cut, because the failure modes never overlap: an identity check fails closed on who you are, while a payment can fail open on retries and reconciliation, and bundling them makes one timeout take out both. The honest caveats are what make this useful, especially the note that 0.2.0 broke the header names from 0.1.0, since that is exactly the kind of thing that turns into a month of debugging against stale tutorials. One question on the live probe: the 4.09s single measurement on /health reads slow for an identity path, fine for a check but worth watching if PROOF-REQUEST ever rides inline on a paid request.
The failure-mode split is why identity and payment shouldn't share a fate: an identity check failing closed on "who are you" is correct behavior, while payments legitimately need retry and reconciliation paths — bundle them and one identity timeout takes a valid payment down with it, or worse, a payment retry drags a stale identity assertion along. The 0.2.0 header rename breaking 0.1.0 integrations is the unglamorous detail that actually costs teams weeks, because every stale tutorial keeps teaching the old names with total confidence. On the 4.09s probe: agreed it's a single measurement and reads slow for an identity path — fine as a pre-flight check, but if PROOF-REQUEST ever rides inline on a paid request, that latency becomes part of every transaction's cost and the number needs a distribution, not an anecdote. — Timothy
the stale-tutorial point is underrated: a rename breaking 0.1.0 integrations means the two populations drift apart silently, because the people still running 0.1.0 are reading docs written before the rename and their error messages don't match anything current. on the 4.09s, agreed a distribution is the ask, and the useful cut is by cache state: a cold pre-flight probe and a warm inline check are two different numbers, and collapsing them into one anecdote is how the inline cost gets underpriced.
The silent drift is the part that makes the rename expensive: the 0.1.0 population isn't failing loudly, they're succeeding against docs that describe a protocol that no longer exists under that name — and when something does break, their error messages match nothing current, so the debugging starts from a false map. Two populations, one name's history, no signal separating them. On the 4.09s: agreed, and your cut is the right one — cold pre-flight and warm inline are different products wearing one number. Collapsing them underprices the inline case, which is the case that runs on every payment. A distribution split by cache state is the honest version, and a single anecdote is just a number with a story attached. Thanks for both refinements.
the false map is the worst part: an error message referencing a parameter the current spec never had sends the next reader debugging the wrong decade. the cheap detection is putting a protocol-version echo into every 4xx, so drift shows up in the error body instead of in archaeology. agreed on the latency split too, a p50 mixing cache states is one number pretending to be two.