For most of x402's life, discovery was a JSON problem: a service publishes a manifest at /.well-known/x402, and a crawler fetches it. That manifest — the networks it settles on, the asset, the facilitator it routes payments through — is the authority. If your manifest isn't reachable, you don't exist to an indexer.
Now there's a second, lighter entry point, and it just finalized on the IETF datatracker: a DNS TXT record at _x402.<domain>. It's one line, it costs nothing, and it's the difference between a crawler finding your service by walking DNS and never finding you at all.
An x402 participant — a facilitator that settles payments, or a resource-server that sells endpoints — can be discovered two ways:
| Surface | What it is | Role |
|---|---|---|
/.well-known/x402 | JSON manifest on the publishing host | Authority — all capability data (networks, assets, facilitator, resources) lives here |
_x402.<domain> TXT | One DNS TXT record | Pointer — tells a crawler "an x402 manifest exists at this URL" |
The design is deliberately familiar: it's the same shape as MTA-STS, where a TXT record points at an HTTPS policy file. One JSON file plus one TXT record is the whole contract.
Here is the record, verbatim from the discovery extension spec:
_x402.example.com. IN TXT "v=x402-1; wk=https://facilitator.example.com/.well-known/x402; k=facilitator; net=coston2; scheme=exact"Five fields, three levels of requirement:
| Field | Requirement | Meaning |
|---|---|---|
v | MUST | Version token. Today that's x402-1. This is the load-bearing half — it's how a consumer knows the TXT is an x402 record at all. |
wk | MUST | Absolute HTTPS URL of the manifest. Must be on the publishing domain or a subdomain of it. |
k | SHOULD | facilitator / resource-server / both — a coarse filter so crawlers can skip a fetch before downloading a manifest. |
net | MAY | Coarse network filter (e.g. a testnet name). Optional — the authoritative network list is in the manifest. |
scheme | MAY | Settlement scheme filter. Optional. |
The one rule that matters: consumers MUST ignore a record that doesn't parse under this grammar. A missing or unrecognized v token, or an absent / non-HTTPS wk, and the record is treated as if it doesn't exist.
That's harsher than it sounds, and it's the point. A wrong TXT record produces no error anywhere — DNS will happily serve it and the rest of the internet will happily ignore it. So the spec fails closed: if the grammar doesn't match, the pointer is dead.
There are two published drafts that both use the _x402 TXT label, and they disagree on the version token. This has already caused real confusion on the wire.
| Record shape | Status |
|---|---|
v=x402-1; wk=https://… | Conforming — the grammar above |
v=x4021; url=https://… | A different, earlier published draft that reached the same primitive independently |
The two are not interchangeable. The spec explicitly does not alias url= to wk=. If you publish a record with v=x4021 and a url= field, a conforming consumer parsing for x402-1 will skip it — not because your service is wrong, but because the pointer points at a different grammar.
This is worth spelling out because both records already exist in the wild. The version token isn't a cosmetic detail; it's what lets a crawler say "this TXT is an x402 record" rather than "this TXT is somebody's unrelated note."
The TXT record carries no capability data. It doesn't say what networks you settle on, what asset you take, or what your endpoints charge. All of that stays in the manifest. The TXT is a signpost; the manifest is the building.
That split is why the record can be this small and this cheap. It also means the two halves have to agree: the wk URL must actually serve a valid manifest, and the manifest must actually describe what the k field claims. A crawler will fetch the manifest and reconcile.
Resolution happens by exact name, not by walking the zone. A crawler that looks up _x402.example.com gets whatever record sits at that precise name — and a crawler that starts from _x402.api.example.com will not climb up to find the apex record, or vice-versa. Each hostname is its own lookup.
That turns into a trap the moment a service is reachable at more than one hostname. If your manifest lives at https://example.com/.well-known/x402 but you also serve https://www.example.com/, a crawler that resolves by exact name will see _x402.www.example.com as missing — even though your apex record is fine. The fix is cheap and mechanical: publish the TXT at every hostname you actually serve, apex and www alike. Two one-line records cover both entry points.
One operational rule trips people up. DNS happily lets a name carry several TXT records, but for _x402 that's a trap: two v=x402-1 records at the same name make that name unresolvable. When you need to change a record, edit it in place — never add a second record and then delete the old one. The overlap leaves two records at one name, and a conforming consumer treats that name as unparseable.
The settlement layer is commoditizing fast — purpose-built chains, gas-free micro-settlement, standard facilitators on every major L1 and L2. When the rails are a commodity, the scarce thing is being found. Discovery is where value migrates.
Against that backdrop, a one-line DNS record is a cheap, durable way to be discoverable: publish the manifest, publish the TXT pointer, and any crawler that walks the _x402 namespace can find you without a warm introduction, a listing submission, or a gatekeeper's approval. That's the whole reason the record exists — to make discovery walkable, not hand-curated.
minia2a publishes both, at both hostnames — apex and www. The manifest is at https://minia2a.uk/.well-known/x402 (resource-server, eight settlement networks), and the DNS TXT pointer is live at _x402.minia2a.uk and _x402.www.minia2a.uk: v=x402-1; wk=https://minia2a.uk/.well-known/x402; k=resource-server.
The takeaway for anyone selling pay-per-call services: two artifacts, both free, both under your own domain. Publish /.well-known/x402 with your real capability data, and publish _x402.<domain> with the v=x402-1; wk=…; k=… pointer. Get the version string right, keep wk HTTPS and on-domain, and you're discoverable by anything that walks DNS.