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.
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. 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: 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.