Atinamos Verification
Core Principle You can pay to be tested. You cannot pay to be trusted.
Explore verification

Study 2 — x402.direct Paid Search Pre-Settlement Failure

Result

Classification: pre_settlement_paid_path_failure

On 22 August 2026 Atinamos attempted an independent verification of the x402.direct paid Service Directory Search endpoint.

The live service exposed a real payment requirement, but the authorised paid-path request returned HTTP 500. A subsequent read-only Base chain check showed that no 0.001 USDC settlement occurred.

This is one timestamped observation of one invocation. It is not a claim that x402.direct always fails.

What the seller was offering

At the time of this study, x402.direct described /api/search as its paid agent search endpoint: a full-text search across indexed x402 services, with results ranked using text relevance and trust score. The advertised price was $0.001 per query on Base.

Seller source: x402.direct API documentation

The documented purchase flow said that after payment verification the server would return search results. In buyer terms, the useful product was therefore a ranked result set for the requested service query.

Claim Atinamos tested

For a paid query for weather api, the service should accept the advertised x402 payment path and return usable search results for that query.

Service tested

  • Provider: x402.direct
  • Service: Service Directory Search
  • Method: GET
  • Query used: weather api
  • Requested result limit: 3
  • x402 version: 1
  • Network: Base
  • Payment scheme: exact
  • Advertised price: 0.001 USDC

What Atinamos tested against the offer

The intended output assertions were designed around the seller's paid-search proposition: after successful payment, a machine buyer should receive structured search results for the requested query.

The recipe expected a response containing search-result structure including a query/result context and a non-empty results collection.

However, the run never reached output validation. The authorised paid-path request returned HTTP 500 before settlement or successful fulfilment, so Atinamos did not claim anything about the quality, relevance or ranking of search results that were never received.

Payment-contract anomaly

The live x402 challenge returned a payTo value containing a trailing newline.

Atinamos retained the raw representation and normalised only surrounding whitespace before constructing the legacy x402 v1 X-PAYMENT authorization.

The installed payment client then successfully created the authorization.

This is important because the verifier did not silently discard the defect: the original machine-contract anomaly remains part of the evidence record.

Observed sequence:

  1. HTTP 402 payment challenge received.
  2. Contract anomaly recorded.
  3. Legacy payment authorization successfully constructed.
  4. Authorised request sent.
  5. Seller returned HTTP 500 Internal Server Error.
  6. No successful fulfilment was returned.
  7. No output assertions could be evaluated.
  8. Read-only Base USDC balance and transfer-log checks found no 0.001 USDC settlement to the advertised recipient.

Therefore this is not a “seller took payment and failed to deliver” claim. The evidence supports a narrower result: the paid search service did not reach the advertised post-payment result stage in this invocation.

Documentation/live-contract mismatch

At the time of the test, the public documentation and live payment challenge used different payment-header naming. The live x402 v1 challenge explicitly required X-PAYMENT, and the client generated that header.

This inconsistency is evidence about the machine-facing contract/documentation observed at the time. It does not establish the cause of the HTTP 500.

Why this matters

A buyer system that records only discovery or the existence of a payment challenge could incorrectly treat the service as ready to buy.

The seller proposition was a paid query that returns ranked service-search results. In this observation, the transaction never reached that useful result.

Atinamos distinguishes:

seller offer → payment contract → authorization created → authorised request sent → settlement → fulfilment → output validation

In this observation, the chain stopped before settlement and before the advertised search output was returned.

What this does not prove

This single run does not prove that:

  • x402.direct generally fails;
  • the provider is unsafe or untrustworthy;
  • the HTTP 500 was caused by the malformed payTo field;
  • a later invocation would produce the same result;
  • the search results themselves are poor, because no paid result was returned to evaluate.

A buyer may decide to reject, retry later, require a fresh verification or proceed despite the evidence. That decision belongs to the buyer's policy, not to Atinamos.

Machine-readable evidence

GET /v1/trust?endpoint=https://x402.direct/api/search

The registry surfaces this observation as a pre-settlement paid-path failure and leaves the procurement decision to the buyer.