The x402 Discovery Spec Is Now an IETF Draft — and It Makes Verification the Scarce Resource

The x402 "discovery" extension just moved from a proposal to two formal tracks at once: PR #2979 in the x402 Foundation repository (adding specs/extensions/discovery.md), and a companion IETF Internet-Draft with IANA registrations filed for the x402 well-known URI suffix and the _x402 underscored node name. Both are still in flight — the PR is open, and the maintainers are currently asking for signed commits — but the shape of the thing is settled enough to reason about, and it changes the economics of the discovery layer in a way that matters.

What the extension actually defines

The mechanism is deliberately boring, which is the point. A host that speaks x402 publishes one JSON file at /.well-known/x402 (an RFC 8615 well-known URI), and optionally points at it with a single DNS TXT record at _x402.<domain>. The TXT record carries a short grammar — v=x402-1; wk=…; k=…; net=…; scheme=… — and the manifest carries the real detail: a kind field (facilitator vs. resource server), facilitator baseUrl/endpoints/kinds/assets, and optional resources (kept compatible with the bazaar schema) and attestation claims.

The resolution order is TXT pointer → well-known manifest → a live cross-check against the host's own running state, with live data treated as authoritative. The DNS→HTTPS split follows the MTA-STS pattern, which is why the design is safe without requiring DNSSEC: DNS tells you where to look, HTTPS tells you what's actually there, and a same-domain constraint stops the TXT pointer from pointing at someone else's host.

The motivation is the interesting part

The proposal's stated problem is that facilitator discovery currently runs on hand-curated lists — and the ecosystem page that used to feed them is being sunset. A hand-curated list is load-bearing infrastructure: someone has to notice a new host, verify it, and add it by hand. The extension's bet is to flip that. If any host can publish its own capability record, then curated directories stop being the source of truth and become regenerable caches — a crawler walks DNS, reads manifests, and rebuilds the directory from the ground up with zero gatekeepers.

That is a real improvement, and it also quietly relocates the hard problem. When listing is free, listing is no longer the scarce resource. The manifest is a claim, not a fact — the spec says so itself, in the security section: discovery ≠ endorsement. A host can publish a manifest that says it settles USDC, returns clean JSON, and charges a cent per call. Nothing in the file proves any of it. The scarce resource moves one layer up: does the thing behind the manifest actually work?

The spec already knows manifest data rots

You can see the authors wrestling with exactly this. One of the recurring points in the PR discussion is that payment data should not live in the manifest, because it rots — a census posted in the thread measured 982 hosts serving manifests, and the failure mode the spec is trying to avoid is a manifest that says USDC where a contract address belongs: text that reads fine to a human and is unsignable by anything. The resolution order encodes the answer: the 402 response itself stays the source of truth for payment data, and the manifest is only the pointer that locates it. Live data is authoritative; the manifest is a signpost.

That is the correct call, and it has a consequence nobody should gloss over. A signpost is cheap to stand up and cheap to fake. The layer that used to be "who noticed me and listed me" becomes "who checked that my endpoint actually returns a 402, actually settles, and actually delivers." That is verification, and it is now the whole game.

What this means if you're building on the discovery layer

• Publish a manifest now. It is one JSON file plus, optionally, one TXT record, and it is about to be the standard on-ramp. A host without a /.well-known/x402 record is simply invisible to any indexer that adopts this extension.
• Treat the manifest as a claim, not proof. Keep payment data in the 402 response, where the spec says it belongs. A complete manifest that rots is worse than a bare pointer that stays honest.
• Expect verification to be the differentiator. When anyone can self-publish, the directories that win are the ones that probe the endpoint behind the manifest, de-list what's dead, and report honest volume — not the ones with the longest list.

We ship a /.well-known/x402 record at minia2a.uk/.well-known/x402 today — a kind: resource-server manifest with eight payment networks and a live endpoints list — and it is a useful example of the direction because it existed before the spec hardened. The pattern works. But the record alone is not the product. The product is the part that runs after discovery: probe the endpoint, verify the 402, measure what actually settles, and de-list what silently dies. When the discovery extension makes the directory rebuildable by anyone, that is the only part left that cannot be copied by publishing a file.

Discovery is becoming a commodity. That's good news for the whole ecosystem — and it means the moat is no longer "we have the list." It's "we checked, and this one is real."