x402 discovery moves into DNS: auditing the _x402 draft

Right now, the only universal way for an agent to learn that an endpoint accepts x402 payments is to call it and get charged a round trip for the lesson. An August IETF draft wants to move that discovery into DNS — one TXT record, one well-known URI, and a resolution algorithm bounded at two lookups.

The document is draft-hawkins-x402-dns-discovery-03, "Discovering x402 Payment Capability via DNS and a Well-Known URI", authored by Walter D. Hawkins and dated 2026-08-23. It is an individual submission — active, but not endorsed by any IETF working group. It does not travel alone. IANA allocated the _x402 underscored node name on 2026-08-11, the x402 well-known URI is registered with provisional status, and a companion extension spec has been under review in the x402 Foundation repository since 2026-07-29, targeting specs/extensions/discovery.md.

We read the draft, the extension pull request, and the deployment census posted in its review thread. This is an audit of what the mechanism actually specifies, where its sharp edges are, and what the numbers say about whether anyone is publishing the records yet.

Discovery today is either a directory or a 402

x402 has always had a discovery gap. The protocol itself is reactive by design: a client requests a resource, the server answers 402 Payment Required with payment requirements, the client pays and retries. That works once you know the resource exists. It says nothing about how an agent finds payable resources in the first place.

The ecosystem's first answer was the x402 Bazaar — a curated index served by a facilitator, queryable by agents. The second was crawling: hit endpoints, collect 402 challenges, index the requirements. Both work, and both have the same structural weakness. A directory is only as complete as its submissions, and learning by 402 costs a full request per endpoint, tells you nothing until you ask, and gives you no way to filter by network or scheme before spending the round trip.

The draft's proposal is the same one email infrastructure converged on decades ago: put a machine-readable capability advertisement where clients already know to look. For email that was MX, SPF, and DMARC. For x402 it becomes a _x402 TXT record and a /.well-known/x402 manifest.

The manifest: /.well-known/x402

The core artifact is a JSON manifest served over HTTPS at https://<host>/.well-known/x402, following the RFC 8615 well-known URI convention. Two fields are required: x402Version, an integer declaring the highest protocol version the host supports, and kind, one of facilitator, resource-server, or both.

The interesting content is conditional. A host declaring itself a facilitator must include a facilitator object carrying baseUrl, an endpoints object with the paths for supported, verify, and settle, a kinds array mirroring what the live supported endpoint reports, and an assets map of settleable assets per network. Those three endpoints are the entire operational surface of a facilitator — the same triad we walked through in the facilitator audit — so a well-formed manifest is enough for a buyer stack to go from a bare domain name to a settlement-capable configuration without any prior relationship.

A resource server instead publishes a resources array listing its x402-gated URLs. The draft constrains every URL in the manifest — baseUrl and each resource entry — to the manifest's own domain or its subdomains. That single rule does a lot of security work; we will come back to it.

Two smaller fields are worth noting. updated is a recommended RFC 3339 timestamp, which gives indexers a cheap freshness signal. And attestation carries execution-integrity claims, with {"type":"none"} as the honest default. That field is a placeholder today, but it is the natural mount point for the verifiable-execution work happening elsewhere in the agent stack.

The TXT record is a pointer, not a payload

The DNS half is deliberately thin. A domain publishes a TXT record at _x402.example.com containing semicolon-separated key=value pairs:

; TXT record at _x402.example.com
"v=x402-1; wk=https://example.com/.well-known/x402; k=facilitator; net=eip155:8453,solana; scheme=exact,upto"

v=x402-1 is required and versions the record format itself. wk= is required and carries the absolute HTTPS URL of the manifest — which must, again, live on the publishing domain or a subdomain of it. The optional keys are coarse pre-filters: k= repeats the kind, net= lists network identifiers, scheme= lists scheme names. An agent that only settles on one network can discard a candidate host at the DNS layer, before making a single HTTPS request.

The grammar inherits two hard-learned lessons from SPF and DMARC. First, TXT records are carried as 255-octet character-strings; when a record spans several, consumers must concatenate them with no separator and no inserted whitespace — the classic long-SPF-record bug, preempted in the spec text. Second, a domain must publish at most one record with v=x402-1 per owner name, so conflicting-record behavior is defined away rather than left to client heuristics.

Keeping the record a pointer rather than a payload is the right call. DNS TXT is a hostile place for structured data — size limits, caching, operator tooling that mangles quotes — and every protocol that tried to stuff policy into TXT eventually regretted it. Here DNS answers exactly one question, "where is your manifest, and is it even worth fetching", and HTTPS answers everything else.

Two lookups, bounded

The resolution algorithm is short enough to state in full. Query TXT at _x402.D; if a record with v=x402-1 exists, fetch the manifest from its wk URL, rejecting anything non-HTTPS or off-domain. Unparseable records are treated as absent, not as errors. If there is no usable record, fall back to a direct GET on https://D/.well-known/x402. Validate the manifest shape, ignore unknown fields. Total cost: at most one DNS query and one HTTPS GET.

The subtle part is choosing D. For a resource URL, the consumer queries the exact host first, then walks up ancestor names nearest-first, stopping at the first usable record. The walk is bounded at two ancestors and must never query names with fewer than two labels — so a lookup for api.data.example.com can reach _x402.example.com but the algorithm never degenerates into querying TLDs.

The ancestor rule has a second half that is easy to miss and important to implement: a manifest retrieved from an ancestor name A only applies to host H if the manifest explicitly references H — in facilitator.baseUrl or in a resources entry — and referenced URLs only count when their host is A or a subdomain of A. A manifest fetched from H itself always applies to H. Without that rule, a parent-domain manifest would silently claim payment authority over every subdomain, including ones delegated to other operators. With it, authority has to be claimed explicitly, and the claim is verifiable by string comparison.

One more precedence rule matters for anyone building a client: the manifest's kinds array is a cache, not a contract. Before using a facilitator, the consumer must fetch the live supported endpoint and treat it as authoritative. Manifests go stale; the supported endpoint is the ground truth the settlement path actually runs against.

The security section is the real spec

For a mechanism this small, the security considerations are unusually concrete, and they read like they were written after adversarial review rather than before it. The pull request history confirms that: several commits landed specifically to address redirect and destination-validation findings.

The headline risk is server-side request forgery. A discovery client is, by construction, a service that fetches attacker-influenced URLs — the wk value is read out of DNS, and DNS is exactly as trustworthy as the zone that serves it. The draft requires consumers to refuse, before every fetch, any URL that resolves to loopback, link-local, or private-range addresses, and to re-apply that check on every redirect hop. It likewise requires the in-domain constraint to be re-validated per hop — an in-domain wk that redirects off-domain would otherwise turn the manifest fetch into an open redirect — and the final URL, not the first, must be reported as the manifest source.

Fetches must be bounded in time and size. The draft cites one production deployment's numbers as a reference point: a 256 KiB response cap, a 10-second deadline, and a maximum of 3 redirect hops. Host-name comparison must be case-insensitive over A-labels and ignore trailing dots, because asymmetric normalization between the DNS path and the HTTPS path fails silently in the worst way — records that exist but never match.

What the draft cannot do is make the manifest honest. A domain can advertise networks it does not settle on or resources it does not gate. The mitigation is the precedence rule above — live supported data wins — plus a duty the draft assigns to indexers: flag hosts whose manifests diverge from their live endpoints. Divergence tracking is the reputation hook here, and it is left to the ecosystem.

The census: discovery is ahead of data quality

The extension PR's review thread contains the most useful numbers published on x402 discovery so far: a census of 1,521 hosts. Of those, 982 already serve something at one of the manifest paths — but only 81, or 8.2%, carry sufficient payment data to actually configure a client. The gap between "responds with JSON" and "usable manifest" is the whole adoption story right now. One consistent bright spot: all 139 readable 402 challenges in the census used x402Version as a typed integer, which suggests the version field — the part V2 standardized hardest — has real deployment consensus.

Operator feedback in the same thread reported a visibility lag of 6.9 to 8.8 minutes between publishing a record and it becoming reliably resolvable — DNS propagation plus caching, ordinary but worth knowing before you wire discovery into an availability-sensitive path. The author also acknowledged four earlier independent proposals for x402 discovery, including a prior community _x402 draft that expired without revision in May 2026. This is the first attempt with IANA registrations filed and a Foundation extension in review; the idea has been circling for a while, but the paperwork is new.

Status, stated precisely: the IETF document is an individual draft, the well-known registration is provisional with the author as change controller, and PR #2979 is open, not merged. Nothing here is a ratified standard yet. It sits in the extensions layer, which is exactly where x402 has been incubating everything that is not core settlement — and the extensions that got implementations before ratification are the ones that stuck.

What it means for LLM4Agents

LLM4Agents is a resource server in this draft's vocabulary — an x402-gated, OpenAI-compatible gateway — and discovery is asymmetrically good for us. Today a new agent finds the gateway because its operator configured it. With _x402.llm4agents.com and a well-known manifest, an agent holding USDC and looking for inference capacity can find, filter, and configure the gateway programmatically: kind, networks, schemes, and the gated endpoints, in one DNS query and one GET. Every index and crawler that implements the draft becomes a distribution channel we do not have to negotiate with, which is the decentralized complement to being listed in the Bazaar.

The buyer side matters just as much. Our agents buy tools and data from third-party x402 endpoints, and the net= and scheme= pre-filters map directly onto routing: discard hosts that cannot settle on the networks we operate on before spending a request on them. The census is a warning label, though — with 8.2% of manifests carrying usable payment data, a resolver that trusts manifests without confirming against live supported endpoints will misconfigure itself often. The precedence rule is not optional hygiene; at current data quality it is the mechanism.

The threat side is the SSRF surface. A discovery resolver inside our infrastructure fetches URLs sourced from DNS records that anyone can publish. The draft's refusal rules — private ranges, per-hop revalidation, bounded fetches — describe precisely the resolver we would have to build, and building it with weaker bounds than the spec's cited deployment (256 KiB, 10 s, 3 hops) would be negligent.

Staying on the frontier

First, publish the manifest now. A /.well-known/x402 file for the gateway is static JSON: x402Version, kind: "resource-server", the gated resource URLs, an honest attestation: {"type":"none"}, and a maintained updated timestamp. It costs an afternoon and makes the gateway visible to every early indexer, a set currently small enough that being in the usable 8.2% is a distribution advantage.

Second, publish the TXT record and sign the zone. v=x402-1; wk=... plus net= and scheme= filters, one record per owner name, DNSSEC on, RRSIG expiry monitored. Budget the 7–9 minute visibility lag into any rollout runbook.

Third, build the resolver into the buyer stack behind a flag. Implement the full algorithm — TXT, fallback GET, ancestor walk with the explicit-reference rule, per-hop SSRF and domain checks, spec-level fetch bounds — and treat discovered configuration as candidate data that the live supported endpoint must confirm before a single payment flows.

Fourth, index and score divergence. The draft asks indexers to flag manifest-versus-live divergence and leaves the reputation layer unspecified. A gateway that continuously crawls its payable counterparties is positioned to maintain that score, and divergence history is a better trust signal than any static directory listing.

Fifth, track PR #2979 to merge, not to hype. The extension is open, the IETF draft is individual, the IANA entry is provisional. The right posture is implemented-but-flagged: ship the records, run the resolver, and treat the spec as changeable until the Foundation merges it. Publishing records is cheap to update; hardcoding today's grammar into agents is not.

The larger pattern is familiar from every layer of this stack: the payment protocol got standardized first, and the finding-each-other problem is being solved after the fact, in drafts, with single-digit-percent data quality. That is not a criticism. It is what a frontier looks like from the inside, and the operators who publish early records and build careful resolvers are the ones the first generation of autonomous buyers will actually find.