An updated proposal for discovering x402 services raises a practical question for builders: how should an agent find a paid endpoint before deciding whether to use it?
Walter D. Hawkins’s 23 August 2026 revision proposes an HTTPS capability document at /.well-known/x402, with an optional _x402 DNS TXT pointer. It would let clients discover advertised capabilities before receiving a payment request. The text includes checks against live facilitator capabilities and limits on fetching destinations. This is an independent Internet-Draft, work in progress—not an IETF standard, an IETF-endorsed proposal or evidence of adoption by the x402 Foundation. Read the pinned revision and its status record.
A discovery result should start a decision
InferenceView’s analysis is that easier discovery would make the quality of the next decision more important. An agent that can assemble a larger candidate list still needs a disciplined way to select one service for one job.
Consider an illustrative workflow, not a measured deployment: a research agent needs fresh company records with source links. Finding an endpoint that advertises data access gets the agent to a candidate. It leaves open whether the endpoint accepts the intended request, supplies sufficiently recent records and returns fields the downstream application can use.
Those questions belong in the buying workflow. A team can define required fields, maximum data age and an acceptable response time before requesting a quote. That makes selection repeatable and gives a failed trial a useful explanation. “Missing source links” is more actionable than a single pass-or-fail label attached to an entire provider.
Proposed discovery paths do not imply provider validation, endorsement, payment success or useful output. Treating findability as a recommendation would collapse several separate decisions into one.
Keep the evidence in four separate records
Builders can make their evaluation easier to audit by retaining four records:
- Offer: the specific endpoint, advertised terms, source and observation time.
- Endpoint response: the request attempted, response received and check time.
- Payment: the authorized amount and settlement evidence, when a purchase occurs.
- Result: the returned output and its performance against the task’s acceptance criteria.
This is an evaluation framework, not a description of the draft’s requirements. Its value is that a change in one record does not silently rewrite the others. An updated offer need not invalidate a historical purchase record. A successful endpoint check cannot substitute for a missing settlement record. A settled payment cannot explain whether the returned data passed the buyer’s test.
Where InferenceView fits today
InferenceView’s provider directory offers a starting point: SwarmBazaar/CDP Bazaar records, advertised prices and dated endpoint checks. Those observations help researchers form a shortlist and see when an offer was checked. They are not completed purchase tests or quality ratings.
InferenceView does not currently implement the proposed DNS and capability-manifest discovery mechanism. Readers can use the existing directory and service-pricing guide to document a comparison today: fix the task, retain the dated offer, confirm current terms and record the result of any separately authorized trial.
For service operators, the practical opportunity is a listing that another builder can evaluate: precise request examples, clear billing units, dated terms and an explicit description of the output. Better discovery becomes more useful when the discovered offer answers those questions.